Imagine somebody doing a drive-by on your repo and dropping a 270k loc PR expecting you to merge it. Bonus points if they can't even put in the 0.001% smidgen of effort to write why they think the PR is useful or necessary in their own words. Oh, but we don't have to imagine it, because there are people who actually do that!

To all the people saying "it's dangerous to add concurrency to javascript", javascript has already workers, shared array buffers and atomics. It's entirely possible today to start two or more workers, pass a shared array buffer via a message and then write concurrently on the same buffer forfeiting message passing and synchronizing only using atomics. You can even do lock less data structures, see for example https://greenvitriol.com/posts/lockless-allocator. That's what you do when you write high performance Web apps. This proposal only adds lightweight threads sharing memory by default, but it's by no means the first and only way to do low level concurrency with javascript.

One of the biggest things preventing software like SQL DB's from being written in TypeScript is the lack of proper threading.

I genuinely think you could write a competitively-performant multi-threaded DB in Bun + TS if you had shared-heap threads and fast atomics/locking primitives.

I am shocked by how good and comprehensive the bun docs & ecosystem is.

Its so well contained I never need to look outside its ecosystem for basic components. It's a true "Batteries Included" runtime.

I'm curious to hear from people if anyone who uses Bun after this changed has noticed any day to day differences with the rust version over the zig version

tbh, that looks like AI psychosis caused by getting access to unlimited tokens

Eh, Firefox/Thunderbird had multi-threaded JS in SpiderMonkey in the late 90s.

Then it was removed it because it made garbage-collection a real mess (the JavaScript gc needs to walk through lots of C++ data, some of it may have specific requirements for destruction/finalization).

I hope it's better this time :)

Great, this will be the savior of software devs - as the last memory safety bugs are being patched, a whole new world of javascript multithreading issues to fix opens up.

This has me thinking of Python's NoGIL movement.

Don't have much to say on the topic but recalled this excerpt from the book Coders at Work in the chapter interviewing Douglas Crockford.

``` In my experience, the worst bugs are the real-time bugs, which have to do with interactions with multiple threads. My approach to those bugs is to avoid making them. So I don't like threads. I think threads are an atrocious programming model. They're an occasionally necessarily evil, but they're not necessary for most of the things we use threads for.

One of the things I like about the browser model is that we only get one thread. Some people complain about that—if you lock up that thread, then the browser's locked up. So you just don't do that. There are constantly calls for putting threads into JavaScript and so far we've resisted that. I'm really glad we have.

The event-based model, which is what we're using in the browser, works really well. The only place where it breaks down is if you have some process that takes too long. I really like the approach that Google has taken in Gears to solving that, where they have a separate process which is completely isolated that you can send a program to and it'll run there. When it's finished, it'll tell you the result and the result comes back as an event. That's a brilliant model. ```