Bun has an open PR adding shared-memory threads to JavaScriptCore

I knew it was possible :-)

https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...

The code needs to be not in the state of "no obvious bugs", but "obviously no bugs". Especially the programming language runtime. Otherwise there is no hope you can sustain any development whatsoever

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. ```

Is there a human-authored description of the PR anywhere?

How are there not race conditions all over the place?

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.

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.

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 :)

This is terrifying. Evidently based on prior art by Mr. Pizlo – indeed, where's the acknowledgement of that?? (edit: I missed it) – but I'm assuming that was never translated into code.

I love the idea of experimentation and innovation; I abhor the idea of it being dependent on Anthropic and their theft. I've never rooted for the Chinese labs more strongly than after seeing this.

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!

I know a thing or two about VMs. Reading this post, I thought to myself "No way it was this easy. No performance hit in the single threaded case? No way".

I was right. Buried in the middle of the post is this tidbit:

> v1 collects synchronous and stop-the-world

Ah, there it is! I knew it!

Parallel garbage collection is a very hard problem. Years of experience and subtle implementation are required to get something like ZGC. A stop-the-world garbage collector will kill tail latency in many use-cases, especially for large programs. I'd say a good GC is the hardest part of a modern VM, even harder than a good JIT: not that a JIT is easy.

Show me multi-threaded JS with generational mark, sweep, compaction, etc. running in parallel with the mutator and I'll be impressed. (The smart thing would be to base it on the JVM or CLR. Doesn't count though.)

It's all so exhausting, this current programmer culture of doing the easy part of a system thing X and presenting your work, without qualifiers, as a complete and modern X.

Sure, sure, we can have memory safe C (just don't have any data races!). Sure, we can have an AI C compiler (just don't expect type checking). Sure, we can port SQLite to Rust (but don't expect it to be fast). Sure, you can one shot a Slack clone (just don't expect performance or security). Doing the easy part of a thing is not doing the thing! You can't trust a README's feature list these days.

To be fair, given that the README is obviously unedited LLM output, the authors might not have realized that their agents cheated and made threading easy by pessimizing the GC. The LLM certainly did though.

Now, maybe the JSC really is adaptable to a multi-threaded mutator world. If it is, great. But over and over, I've seen AI say "I will defer and charter $HARD_THING" and mean "I have no idea how to do $HARD_THING, so I'm creatively reinterpreting your request to make it easy". You have to be endlessly vigilant for LLMs subtly twisting your tasks into easy versions that might technically meet the requirements but they are less complete than you intend.

I will never get over the overuse of adjectives like "real" in LLM outputs, it dilutes the meaning of these words.

Counting 62 em-dashes in the PR description alone, are people reading those walls of slop anymore?

I know a ton of people absolutely hate this level of "LLM code + LLM PR description + LLM PR review" but my boss would have an orgasm if I was able to use AI half as well in our org... :/

Amazing. This is what the Typescript team should have done instead of rewriting to golang -- innovate the runtime.