10 ms·

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

148 points by gr4vityWall 3mo ago

bakugo 3mo ago
I like how the page is actually struggling to load due to the sheer amount of bot activity on the PR. On a completely unrelated note, I wonder why Github is always down. Real mystery there.
pizlonator 3mo ago
I knew it was possible :-) https://webkit.org/blog/7846/concurrent-javascript-it-can-work/ https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...
- CharlesW 3mo ago
  That's excellent work and a great read, Filip!
- quotemstr 3mo ago
  Yes, you did. And it's a good design. You even did the GC question justice. My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things. The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store. JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming. Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses.
  - hexasquid 3mo ago
    This is consistent with the endless contempt people have had for JavaScript and those that use it.
    - pizlonator 3mo ago
      Yeah I don’t get that either It’s a super successful language
      - Waterluvian 3mo ago
        I think with ES6 and newer things really cleaned up and now we’re left with avoidable ugly parts, of which every language has. Before when you didn’t even have strict equality checking, for example, you were forced to know about implicit type casting. Getting on the same page with modules also helped a lot. Typescript directly in Node is great. Look mom, no build system!! I’m just hoping one day browsers will accept TS the same way.
        cyberax 3mo ago
        You still need a compiler for TSX, though. There's also a tiny bit of non-erasable Typescript (enums).
        Waterluvian 3mo ago
        There’s a mode to pretend those features don’t exist and not allow them. Meaning it gets far simpler to just type elide rather than any actual compilation effort. I think this idea is getting more popular and it would be kinda nice if TS committed to not adding any more features like that.
        MrJohz 3mo ago
        TS has committed to not adding any more features like that. Features only get added when they reach a certain threshold on the TC39 standardisation track.
- aardvark179 3mo ago
  It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.
  - sroussey 3mo ago
    This won’t work well without a few other things, like structs https://tc39.es/proposal-structs/ https://tc39.es/proposal-structs/
    - pizlonator 3mo ago
      Structs aren’t necessary for my proposal to work well
  - pizlonator 3mo ago
    My blog post explains how to make prototype chain operations work in the presence of threads
    - aardvark179 3mo ago
      Okay. I gave it another read and I think we agree in general, but maybe disagree on how much memory model strangeness is acceptable, and how wide the gap between, “The behaviour can be understood by a developer,” and, “it should be possible to write a sequential JS program that creates an indistinguishable heap,” is likely to be. The lower level bits round the object model etc. all look very solid. Although structs may not be necessary to make JS concurrent their limitations might help in reducing where memory model strangeness could creep in.
- gwbas1c 3mo ago
  Years ago I did "multithreaded Javascript" by calling into Rhino (Javascript engine) from multiple threads. Granted, I converted Rhino from JVM to CLR, so it wasn't exactly a stable environment, but it did "work".
- bakkoting 3mo ago
  In case anyone missed it, this PR is based on that: > This is an implementation of the design Filip Pizlo published in 2017: "Concurrent JavaScript: It Can Work!".
- cpcallen 3mo ago
  I was SO excited when I first read this article, as I was at the time implementing shared-global multithreading in a fork of JS Interpreter [1][2] and it was thrilling to think that we might one day have true parallelism in a real JS engine, not just simulated concurrency in our educational toy. Since then I've often wondered if anyone at Apple was still working on this, or if it was just one of those things (like proper tail call support in V8) that was destined never to see the light of day. A year or so ago I tried tracking it down again (apparently I'd not bookmarked it at the time) but alas several search engines responded only with a sea of articles about web workers. Finally, last week I put Gemini on the case and, despite it claiming that it didn't exist and that I must be conflating memories of some other related articles it did correctly identify you as the author, after which it was easy to find the link to the original article on your blog. Since re-reading it I've been wondering if it might be possible to implement it with help from AI (not having written any C++ since before the turn of the century I don't think I'd be too successful doing it unassisted!), or whether JSC's internals might have drifted too far in the intervening years. It's delightful that someone else has take a stab at it, and I look forward to seeing where this leads. Thanks for all the work you did laying the groundwork that made it feasible to even contemplate, then contemplating all tricky details and writing the answers down in the form of such an inspiring article. [1] https://github.com/NeilFraser/JS-Interpreter https://github.com/NeilFraser/JS-Interpreter [2] https://github.com/google/CodeCity/blob/fa1bd2734b806559ffaf86ed765a7446bfccec3a/server/interpreter.js#L3760 https://github.com/google/CodeCity/blob/fa1bd2734b806559ffaf...
- gr4vityWall 3mo ago
  I remember reading that article some years ago. Boy, wasn't I surprised when I ran into this PR. I'm excited.
Retr0id 3mo ago
Is there a human-authored description of the PR anywhere? How are there not race conditions all over the place?
- pizlonator 3mo ago
  It's substantially based on my design, read the blog post I wrote (linked in another comment here) It's a very complex thing, but not impossible. I'm very impressed that any LLM can do this
  - deleted 3mo ago
    [deleted]
MuffinFlavored 3mo ago
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... :/
- Atotalnoob 3mo ago
  Just stop caring about quality. It makes it 10x easier to produce slop with AI if you never bother to check
  - rustystump 3mo ago
    It is sad. This is a new reality. No one reads code, it is agents all the way down. It has been long enough now that I can safely say AI has not sped up project delivery nor improved quality when it did ship. Is it the AI or the people using it? Idk
    - mannanj 3mo ago
      Humans made the AI, and their goal is profit, so there’s no AI using people: it’s humans using people.
    - fzzzy 3mo ago
      It is sad. This is a new reality. No one reads machine code, it is compilers all the way down. It has been long enough now that I can safely say C has not sped up project delivery nor improved quality when it did ship.
  - Yoric 3mo ago
    I just wrote an internal report in my company. My conclusion from the project I'm working on is that, as of this day, there is no way to have both this so-called 20x performance improvement _and_ any kind of quality. Or security if whoever is running the agent has any token in an .env anywhere on the same file system. We'll see in which direction the CTO takes this. My bet is not on quality.
lgtx 3mo ago
Counting 62 em-dashes in the PR description alone, are people reading those walls of slop anymore?
- slopinthebag 3mo ago
  Course not. They have an LLM summarize it for them.
- bakugo 3mo ago
  No human has ever read or will ever read the PR description. No human has read or will ever read any of the code, nor was any human thought involved in its creation. Everything is performative now. As long as you just keep your eyes closed and believe it all works, that's all that matters.
  - skeledrew 3mo ago
    Does it not work? I'm watching for the explosion and following "told you so"s.
adem 3mo ago
I will never get over the overuse of adjectives like "real" in LLM outputs, it dilutes the meaning of these words.
- Nnnes 3mo ago
  Related, spinning "I did something poorly" into "I am being honest" > Scalability, measured (the honest section) so what about the other sections?!
  - fzzzy 3mo ago
    The dishonest sections
applfanboysbgon 3mo ago
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!
- Retr0id 3mo ago
  The PR is against bun's fork of WebKit, not upstream.
  - applfanboysbgon 3mo ago
    Oh, my mistake, I thought they were doing the zig thing again.
    - bakkoting 3mo ago
      They didn't open a PR against zig either, the compiler concurrency work they did was also only ever in their own fork.
  - fg137 3mo ago
    The title is of this post is definitely confusing if not misleading.
    - talldeck 3mo ago
      Besides, the title should probably have referred to it as "a giant open PR" or something, because I don't think what the submission is trying to focus on is the feature itself.
gavinray 3mo ago
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.
- forrestthewoods 3mo ago
  …but why? JS/TS does not seem like the right tool for the job?
  - nesarkvechnep 3mo ago
    It's probably what they know so not anything new should be learned.
- piterrro 3mo ago
  I honestly should print that comment and hang it on a wall. > …competitively-performant… Care to explain competitively to what?
- n_e 3mo ago
  You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.
  - quotemstr 3mo ago
    Exactly. Nothing stops your writing a high-performance parallel database in TypeScript today. Given that runtimes and tooling are actually pretty good, I think TypeScript is actually a fine choice of language for the task. The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space. There's a high performance database called "PostgreSQL" you may have heard about. It doesn't use threads. It uses separate processes and shared memory: just like standard JavaScript, with its service workers and SharedArrayBuffer. If not sharing an address space is good enough for PostgreSQL, it's good enough for your TypeScript database. The problem with shared-everything, unmarked, preemptive-parallel concurrency is that 90% of the time it gets used by people who don't know they shouldn't.
stephen 3mo ago
Amazing. This is what the Typescript team should have done instead of rewriting to golang -- innovate the runtime.
- bastawhiz 3mo ago
  That doesn't help anyone using Node. I don't want to have to start using a new runtime because my compiler is slow. That's wild.
  - stephen 3mo ago
    You're already using a new runtime with tsgo -- it's golang at build time -- but still running Node in prod, so the same could work here. :-) Agreed I would not want all Typescript users forced to use /this/ runtime, but if the TS team shipped tsc as "oh now it's uses a special fast JS runtime" (just like tsgo is a different runtime) I'd love to at least have the option of using the same special fast runtime in my own still-written-in-TS apps. Seems I've either struck or a nerve, or miscommunicated, given the insta down votes.
    - jitl 3mo ago
      if there was a thingy that compiled JS to a 10mb native executable with shared heap multithreading, im sure we'd use it. however, no one has invented such a thing. until this pr.
      - stephen 3mo ago
        Right! That's why I think this is an exciting development. I assume everyone is downvoting me for "liking LLM slop", but really I just like the competition that "this is possible!" And would love a slop/non-slop/whatever version in Node/v8. Someday!
        jitl 3mo ago
        same. ts with thread + struct would be a killer language. i pray anthropic buys roblox to get pizlo to actually land this
anematode 3mo ago
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.
- bojan 3mo ago
  The acknowledgement is in the PR description, section "The design, and what it's based on".
  - anematode 3mo ago
    Thanks, fixed
asxndu 3mo ago
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.
- Retr0id 3mo ago
  Last time I read the bun docs I spotted an off-by-one bug in sample code, so I opened a github issue. An AI bot responded, confirming the issue, and opened a PR to fix it - A simple "+ 1" added in the right place. Two other AI bots reviewed the PR, which went on for several rounds of "improvements". Last time I checked, neither the issue nor the PR received any human attention (actually I just checked again, and the PR has been closed by stalebot).
  - Aurornis 3mo ago
    > (actually I just checked again, and the PR has been closed by stalebot). Can you provide the link?
    - Delgan 3mo ago
      I, too, was curious to see it in practice. Here is the ticket opened by @retr0id: https://github.com/oven-sh/bun/issues/28030 https://github.com/oven-sh/bun/issues/28030 And here is the swarm of bots / LLMs / agents that open, review and bikeshed the PR before it's closed by the stalebot: https://github.com/oven-sh/bun/pull/28031 https://github.com/oven-sh/bun/pull/28031 It's hilarious. But also a little sad.
      - Retr0id 3mo ago
        Yup, that's the one.
        Phelinofist 3mo ago
        That's pure comedy
nasretdinov 3mo ago
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
- pizlonator 3mo ago
  No language runtime is ever in a state of "obviously no bugs". Good luck demanding that of anything of JSC's or LLVM's complexity
  - TomatoCo 3mo ago
    On one hand, sure, the entire point of a programming language is to make complex ideas able to be expressed in simpler abstractions. On the other hand, we can damn well try.
    - pizlonator 3mo ago
      Damn well trying to enforce an "obviously no bugs" rule in a language runtime would mean zero progress in language runtimes. We certainly wouldn't have gotten to where we are with runtime and compiler quality and performance if we had damn well tried to enforce such a rule
      - nasretdinov 3mo ago
        IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong
        pizlonator 3mo ago
        Adding concurrency to JavaScript definitely falls in the "complex enough" category So does basically any feature or optimization in a JS runtime
Yoric 3mo ago
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 :)
- pjmlp 3mo ago
  The JS / interoperability is why V8 eventually added a C++ GC.
  - Yoric 3mo ago
    But last time I checked (which was admittedly a while ago), JavaScriptCore didn't have one, no?
    - pjmlp 3mo ago
      No idea, I never used it, nor looked into its internals.
quotemstr 3mo ago
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.
- 12_throw_away 3mo ago
  In contrast, I don't know that much about VMs. But if you're making a big fundamental change to a system, I do know that it shouldn't start with a single "+279,276 -4,272" PR. It starts with a small patch with the core of the change so that everyone can understand what it does and how it works. (I mean, ideally, a change like this starts with documentation, discussion, diagrams, surveys of existing implementations, etc, before you start writing code) You don't cram everything into a single 270K line PR, even (especially) with an LLM, unless you specifically don't want anyone else to look too closely at what you did.
richardbarosky 3mo ago
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. ```
- RealityVoid 3mo ago
  Soo... Essentially, still threads, but no shared state between threads, and they talk through this message interface?
  - masklinn 3mo ago
    Threads which can’t share state are called processes.
    - RealityVoid 3mo ago
      Fair-ish point, if a bit cheeky. But threads can be still threads, i.e. in the same address space, but without actually having shared state between them. And then they're still threads, not processes. You could also have stuff like message ques going between them, the cost of passing data around is small then, you don't have do leave user space to put stuff in the mq's. But can you still call it "not having shared state"? I'd say yes, even though you do share memory and you do have the mutually accessible que. But I can see why you could argue otherwise.
torben-friis 3mo ago
>Scalability, measured (the honest section) Ugh.
- greenchair 3mo ago
  almost spit out my drink!
- poly2it 3mo ago
  I can't stand Claude's "honesty". Anthropic should hire some writers and linguists to make the output a bit more bearable. It's mentally taxing to read this type of dull text for hours every day.
  - queenkjuul 3mo ago
    I just can't do it. I barely skim Claude PR reviews and have no qualms asking someone to summarize in their own words if they've sent me two pages of Claude slop
- mahogany 3mo ago
  The entire PR description is filled with LLMisms. I find this style so hard to read, it’s almost nauseating these days. My eyes start to glaze over and I stop reading pretty quickly after. I’m having to deal with this a lot at work these days unfortunately. I mean, did anyone even read or verify this output? When I read this type of stuff, I have the nagging suspicion that I am the proofreader and I have to do the verification myself. At that point, what are we even doing? I can generate Claude output myself… I know I’m being overly dramatic but this sort of thing feels so wrong and inhuman(?) to me for some reason.
- rbonvall 3mo ago
  Yes, that's the smoking gun!
  - JamesSwift 3mo ago
    151 commits, 1826 files changed and claude found 0 smoking guns? I call bullshit. It found 3 in one run-of-the-mill query the other day
piterrro 3mo ago
think of all the poor web devs trying to use multiple threads on top of asynchronous operations. wild.
- hexasquid 3mo ago
  Standard contempt for web developers.
  - JCTheDenthog 3mo ago
    [flagged]
    - curtisblaine 3mo ago
      Worth noting it's not web devs pushing for React in the Windows start menu. It's PMs looking at the problem and concluding React is the least painful way to solve it (correctly or incorrectly, but I doubt they optimize for the same measurements you do). Ink (the React renderer) in Claude code, on the other hand, makes a lot of sense for interactive CLIs where you want to componentize your menus and dialogs. Actually not using a component framework normally ends up in state / render chaos. Re: mayflies debating politics: React has been there for 13 years, and while the interface has shifted a couple of times (object factories to classes to functions), the main idea has always been really simple and really stable: isolated declarative components that can optionally have state and side effects. Many other popular frameworks have come and gone in the meantime.
  - deleted 3mo ago
    [deleted]
sothatsit 3mo ago
It’s pretty incredible to me that a mammoth change like this is possible to prototype now using LLMs. It makes me wonder how much of our software stack will become more malleable to big ideas and experiments in the future, like Filip’s idea here. Even if you don’t want to merge the code, it’s still an incredible existence proof that something like this could work.
- rzmmm 3mo ago
  Bingo. Dozen LLM-prototypes and then a manmade final patch which is merged.
mwkaufma 3mo ago
[flagged]
xlii 3mo ago
I wonder if I'm the only one for whom the bun project vanished completely. In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package. Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
- monkaiju 3mo ago
  Im here with ya :)
- sibeliuss 3mo ago
  The problem is that you need to twist the cube
- egorfine 3mo ago
  Yeah, I have prepared our company software for migration back to node. I would like to read the promised Jarred's blog post (if it ever comes out) before pulling the plug though.
  - afavour 3mo ago
    I’m amazed folks ever migrated to it at a workplace level TBH. It’s a VC funded runtime, something was always going to happen to it. Node is boring but its governance and ownership is clear.
    - tyre 3mo ago
      Well, it was (is?) significantly easier to use, faster, the team behind it is fantastic, and generally had enough compatibility to run the projects I needed it to. When it’s enough of a drop-in replacement, that’s more than good enough. As long as we’re not adding a hundred bun-specific things, it’s not terribly difficult to back out of, either. Kind of a no-brainer.
      - afavour 3mo ago
throwrioawfo 3mo ago
> Shared-memory threads for JavaScriptCore. new Thread(fn) runs fn on another thread, in the same heap, with the same objects. No structured clone, no message passing, no SharedArrayBuffer-only escape hatch. You share an object by sharing the object. If you can't even be bothered to write a non-slop PR description, it doesn't bode particularly well for the content of the PR itself...
- user43928 3mo ago
  I previously gave this author and the bun rewrite the benefit of the doubt. But an obvious slop PR to the WebKit repository? I'd tap out here too if I was a maintainer. Even if the change was perfect, if you could not be bothered to write the PR description, I am not going to waste my time with it. Edit: My bad, the PR is to a fork, in that case it's not our business how the PR description is written.
  - Me1000 3mo ago
    It’s a PR on their private fork, they’re not expecting to have this accepted upstream.
the__alchemist 3mo ago
Bun alert!
tomjakubowski 3mo ago
For what it's worth: this isn't a PR on mainline WebKit. The PR is on bun's own fork of WebKit (and JSC), which already has a bunch of their own changes.
- mirekrusin 3mo ago
  Did they rewrote WebKit in Rust or not yet?
  - anematode 3mo ago
    I'd actually love to see a relatively high-performance (i.e., including a decent JIT) runtime for a dynamic language that's written in Rust. There's a lot of implementations like Rust Python, the Boa JS engine, etc. that are purely interpreted – and fun! – but I haven't seen a proper, high-performance VM yet. I considered writing such a JVM in Rust, following writing one in C (https://github.com/anematode/b-jvm https://github.com/anematode/b-jvm) that could JIT WebAssembly code and run in the browser, but decided it would be too time-consuming. Obviously such a VM would involve a lot of unsafe, but I'm wondering if you could establish some proper, compile-time-checked invariants that make things a lot safer, without the complicated sandboxing that modern JS runtimes use to make it harder for JIT bugs to escalate into full blown RCE.
    - jitl 3mo ago
      rust seems alergic to the un-safety required of "i dynamically built this executable code segment just now, please jump into it"
      - anematode 3mo ago
        wasmtime exists
        jitl 3mo ago
        yes i love to use a language runtime within another language runtime for a sweet sweet 30% performance penalty
skeledrew 3mo ago
This has me thinking of Python's NoGIL movement.
gwbas1c 3mo ago
Back when Node was the new kid on the block, the single-threaded async model was justified by pointing out that the major challenge with multithreading was shared memory. It's one of the strong points of the language / environment, because you never have to worry that some callback will run on another thread. Javascript shines when it's handling multiple concurrent IO operations, and concurrent operations can become very thread-like with async/await syntax. Multithreaded code in this context only helps with CPU-bound operations; but if I was doing something CPU-bound, I'd probably choose a different language. One thing I wonder, does Bun (or Node) have a way to call into native code on another thread, but still keep single-threaded once back in JavaScript?
- jitl 3mo ago
  yes, all of node.js is built on such operations. what do you think is happening when you `await fs.promises.readFile(name, 'utf8')`? it dispatches a libuv thread to read the file you want, and resolve the promise when the background thread has completed the operation.
  - kikimora 3mo ago
    Except there is often no background thread but async IO.
  - gwbas1c 3mo ago
    That really varies significantly depending on the underlying OS. On Windows, you can do threaded (IE, your thread blocks) or async (you have a callback) IO. There isn't a requirement to spin up a background thread to perform non-blocking IO.
pavlov 3mo ago
This LLM PR description style is getting very tiresome. The obvious signs are the little lists (“not x, not y, not z”) and pompous declarations like this: “The bring-up log at the bottom is honest about what broke and what it took.”
balgaly 3mo ago
[dead]
curtisblaine 3mo ago
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 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.
- kikimora 3mo ago
  This is from PR: v1 collects synchronous and stop-the-world Go build performant web app that has stop-the-world all the time.
  - curtisblaine 3mo ago
    You bypass GC by allocating pools of array buffers at the cost of low-level memory management.
    - kikimora 3mo ago
      So you add threads to allow a shared objects graph with a side effect of more frequent stop the world. Then you fight stop the world by resorting to low level memory management. But if you go level why not allocate a shared array buffer and share it across workers? Something you can do today without threads.
moomin 3mo ago
Look, I’m not an AI hater, but AI is… not great at multi-threading code. And having it analyse multi-threaded code proves nothing because… it’s not good at multi-threaded code. This isn’t entirely shocking because I’m not good at it either and need to write in some very particular ways to have even a hope of being correct. But basically, unless it was written by a genuine expert, I wouldn’t want to even glance at this PR. And it wasn’t.
- murderfs 3mo ago
  I don't think AI is particularly worse at multi-threading code than humans are: humans are notoriously bad at it. I've had reasonably good success with telling Claude and Gemini to go into a codebase, insert clang -Wthread-safety annotations, fix any issues it finds, and refactor code that isn't amenable to the annotations to make it possible.
  - marshray 3mo ago
    But there are any number of humans who will tell you that humans are bad at multithreading the codes and all but the smallest codebases are headed for heisenbug deadlock city if you do things like they told you to in that Introduction to OOP with JavaTM book. But is Claude going to tell you "No, dear user, this project is going to follow an excessively simple and sub-optimal locking regime because experience shows that it is easier to write code than it is to reason about its exponentially-growing complexity" ?
zarzavat 3mo ago
This em-dash stricken PR is yet more evidence that the bun project has AI psychosis. The most important feature for a language runtime is reliability. It's the foundation, it should be boring. I need to know that the foundation is stable so that I can control the reliability of whatever's built on top. AIs hallucinating a multithreaded JSC is not boring, it's scary.
nozzlegear 3mo ago
> Scalability, measured (the honest section) Barf
- moogly 3mo ago
  Heh, are the other sections dishonest, then? Yuck.
l11r 3mo ago
tbh, that looks like AI psychosis caused by getting access to unlimited tokens
emilfihlman 3mo ago
I would just like to point to a single issue that has major ramifications in using Bun: https://github.com/oven-sh/bun/issues/14144 https://github.com/oven-sh/bun/issues/14144
Jarred 3mo ago
I’m the author of this PR. This PR is an implementation of the design from https://webkit.org/blog/7846/concurrent-javascript-it-can-work/ https://webkit.org/blog/7846/concurrent-javascript-it-can-wo.... I think it would be really cool if JavaScript had true shared object multi-threading without compromises (SharedArrayBuffer, postMessage are not that). If we had both threads and structs, it’s likely the TypeScript compiler would never have needed to be rewritten in Go. The title should be changed to clarify that it’s a PR to Bun’s JavaScriptCore fork and not the upstream WebKit. This PR is scarier to merge than Bun’s Rust rewrite PR. There are a good number of benchmarks/stress tests, unit tests, and also TSAN runs and security scanner runs, but this is a more complex change than the Rust rewrite (yes, really). I’m also worried about syncing with upstream - today the “fork” is mostly a bunch of patches, but with this PR, changes to the JIT need to be reviewed for behavior when multiple threads are in use. Our best bet for this to move forward is figuring out a way for some constrained version to be upstreamed into WebKit proper, if that makes sense and if they’re interested. And yes, the PR description is entirely Claude.
- aurareturn 3mo ago
  While you're here, what's the status of the Rust rewrite and that blog post you promised to write?
  - dsissitka 3mo ago
    It's a strange world. Rust rewrite: 6 days.[0] Blog post: 37 days and counting. [0] https://xcancel.com/jarredsumner/status/2060050578026189172 https://xcancel.com/jarredsumner/status/2060050578026189172
- verandaguy 3mo ago
  I've seen the Bun Zig->Rust MR a few weeks ago when it was current. Now I'm seeing this, and I have to ask, since you're here: Is there no way to make this changeset smaller? At work, I've usually written large patches. I used to be worse at it. I was mentored out of it, and while I still like my patches to be complete, I balance that with the available bandwidth of the team and what the team can reasonably actually process. For perspective, my "large patches" were PRs on the order of 10-12kLOC for relatively big features. I consider those to be on the upper end of what is reasonably reviewable by a small, non-dedicated team, and towards the upper limit of the kind of PR where I can speak for nearly every line of code, what it does, and why it's there. On the other hand, now, LLMs are part of the equation, and they can (and often do) write code in insane volumes. They arguably tend towards extreme verbosity, without even talking about docs/markdown files. While LLMs are part of the workflow, my company, and those my friends work at, have all instituted policies of the developer attaching their name to the code ultimately being responsible for the output (which IMO is a lazy strategy, but I can't think of a much better one under the circumstances). I cannot, personally, fathom how you can stand behind a single changeset spanning 2000 files and a quarter-million lines of diff. Do you consider this sustainable? At this point the code bases are very quickly getting away from us in the open source community and even in proprietary code bases, and these are important code bases. Often very complex, often legacy. Who ultimately still owns these? Who's really going to be accountable if things go wrong?
JamesSwift 3mo ago
Ive said many times in my day-to-day convos around AI that Ive come to realize more and more that AI is a solo endeavor. Its very difficult to scale things to more people if you are trying to use AI for more than just speeding yourself up. AI is the epitome of the saying "if you want to go fast, go alone". This PR and the rust rewrite are incredible in scale and ambition. I still think theres a middle ground though of traditional committee-driven design with AI-driven iteration and POCs.
Decabytes 3mo ago
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
- gkfasdfasdf 3mo ago
  The latest version of Claude Code is the compiled with the Rust version of Bun, I've been using it and haven't noticed any regressions.
roblh 3mo ago
Putting on my tinfoil hat. Did Anthropic even buy Bun because they actually use it or was it just an excuse to lob ridiculous PRs at things with at least a little bit of credibility behind them. Their way of trying to set a precedent for accepting AI code into bigger open source projects.
- rzmmm 3mo ago
  The author has huge online following, and influence over developers. I don't doubt the author is genuinely interested in this, but the employer definitely is supporting this too.
lmc 3mo ago
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.
westurner 3mo ago
Notes on TLA+ in addition to fuzzing on "Ideas and resources for fuzzing shared-everything threads · Issue #84 · WebAssembly/shared-everything-threads" https://github.com/WebAssembly/shared-everything-threads/issues/84#issuecomment-4777697636 https://github.com/WebAssembly/shared-everything-threads/iss...

148 points by gr4vityWall 3mo ago

I like how the page is actually struggling to load due to the sheer amount of bot activity on the PR. On a completely unrelated note, I wonder why Github is always down. Real mystery there.

pizlonator 3mo ago

I knew it was possible :-) https://webkit.org/blog/7846/concurrent-javascript-it-can-work/ https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...

CharlesW 3mo ago
That's excellent work and a great read, Filip!
quotemstr 3mo ago
Yes, you did. And it's a good design. You even did the GC question justice. My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things. The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store. JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming. Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses.
- hexasquid 3mo ago
  This is consistent with the endless contempt people have had for JavaScript and those that use it.
  - pizlonator 3mo ago
    Yeah I don’t get that either It’s a super successful language
    - Waterluvian 3mo ago
      I think with ES6 and newer things really cleaned up and now we’re left with avoidable ugly parts, of which every language has. Before when you didn’t even have strict equality checking, for example, you were forced to know about implicit type casting. Getting on the same page with modules also helped a lot. Typescript directly in Node is great. Look mom, no build system!! I’m just hoping one day browsers will accept TS the same way.
      - cyberax 3mo ago
        You still need a compiler for TSX, though. There's also a tiny bit of non-erasable Typescript (enums).
        Waterluvian 3mo ago
        There’s a mode to pretend those features don’t exist and not allow them. Meaning it gets far simpler to just type elide rather than any actual compilation effort. I think this idea is getting more popular and it would be kinda nice if TS committed to not adding any more features like that.
        MrJohz 3mo ago
        TS has committed to not adding any more features like that. Features only get added when they reach a certain threshold on the TC39 standardisation track.
aardvark179 3mo ago
It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.
- sroussey 3mo ago
  This won’t work well without a few other things, like structs https://tc39.es/proposal-structs/ https://tc39.es/proposal-structs/
  - pizlonator 3mo ago
    Structs aren’t necessary for my proposal to work well
- pizlonator 3mo ago
  My blog post explains how to make prototype chain operations work in the presence of threads
  - aardvark179 3mo ago
    Okay. I gave it another read and I think we agree in general, but maybe disagree on how much memory model strangeness is acceptable, and how wide the gap between, “The behaviour can be understood by a developer,” and, “it should be possible to write a sequential JS program that creates an indistinguishable heap,” is likely to be. The lower level bits round the object model etc. all look very solid. Although structs may not be necessary to make JS concurrent their limitations might help in reducing where memory model strangeness could creep in.
gwbas1c 3mo ago
Years ago I did "multithreaded Javascript" by calling into Rhino (Javascript engine) from multiple threads. Granted, I converted Rhino from JVM to CLR, so it wasn't exactly a stable environment, but it did "work".
bakkoting 3mo ago
In case anyone missed it, this PR is based on that: > This is an implementation of the design Filip Pizlo published in 2017: "Concurrent JavaScript: It Can Work!".
cpcallen 3mo ago
I was SO excited when I first read this article, as I was at the time implementing shared-global multithreading in a fork of JS Interpreter [1][2] and it was thrilling to think that we might one day have true parallelism in a real JS engine, not just simulated concurrency in our educational toy. Since then I've often wondered if anyone at Apple was still working on this, or if it was just one of those things (like proper tail call support in V8) that was destined never to see the light of day. A year or so ago I tried tracking it down again (apparently I'd not bookmarked it at the time) but alas several search engines responded only with a sea of articles about web workers. Finally, last week I put Gemini on the case and, despite it claiming that it didn't exist and that I must be conflating memories of some other related articles it did correctly identify you as the author, after which it was easy to find the link to the original article on your blog. Since re-reading it I've been wondering if it might be possible to implement it with help from AI (not having written any C++ since before the turn of the century I don't think I'd be too successful doing it unassisted!), or whether JSC's internals might have drifted too far in the intervening years. It's delightful that someone else has take a stab at it, and I look forward to seeing where this leads. Thanks for all the work you did laying the groundwork that made it feasible to even contemplate, then contemplating all tricky details and writing the answers down in the form of such an inspiring article. [1] https://github.com/NeilFraser/JS-Interpreter https://github.com/NeilFraser/JS-Interpreter [2] https://github.com/google/CodeCity/blob/fa1bd2734b806559ffaf86ed765a7446bfccec3a/server/interpreter.js#L3760 https://github.com/google/CodeCity/blob/fa1bd2734b806559ffaf...
gr4vityWall 3mo ago
I remember reading that article some years ago. Boy, wasn't I surprised when I ran into this PR. I'm excited.

Retr0id 3mo ago

Is there a human-authored description of the PR anywhere? How are there not race conditions all over the place?

pizlonator 3mo ago
It's substantially based on my design, read the blog post I wrote (linked in another comment here) It's a very complex thing, but not impossible. I'm very impressed that any LLM can do this
- deleted 3mo ago
  [deleted]

MuffinFlavored 3mo ago

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... :/

Atotalnoob 3mo ago
Just stop caring about quality. It makes it 10x easier to produce slop with AI if you never bother to check
- rustystump 3mo ago
  It is sad. This is a new reality. No one reads code, it is agents all the way down. It has been long enough now that I can safely say AI has not sped up project delivery nor improved quality when it did ship. Is it the AI or the people using it? Idk
  - mannanj 3mo ago
    Humans made the AI, and their goal is profit, so there’s no AI using people: it’s humans using people.
  - fzzzy 3mo ago
    It is sad. This is a new reality. No one reads machine code, it is compilers all the way down. It has been long enough now that I can safely say C has not sped up project delivery nor improved quality when it did ship.
- Yoric 3mo ago
  I just wrote an internal report in my company. My conclusion from the project I'm working on is that, as of this day, there is no way to have both this so-called 20x performance improvement _and_ any kind of quality. Or security if whoever is running the agent has any token in an .env anywhere on the same file system. We'll see in which direction the CTO takes this. My bet is not on quality.

lgtx 3mo ago

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

slopinthebag 3mo ago
Course not. They have an LLM summarize it for them.
bakugo 3mo ago
No human has ever read or will ever read the PR description. No human has read or will ever read any of the code, nor was any human thought involved in its creation. Everything is performative now. As long as you just keep your eyes closed and believe it all works, that's all that matters.
- skeledrew 3mo ago
  Does it not work? I'm watching for the explosion and following "told you so"s.

adem 3mo ago

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

Nnnes 3mo ago
Related, spinning "I did something poorly" into "I am being honest" > Scalability, measured (the honest section) so what about the other sections?!
- fzzzy 3mo ago
  The dishonest sections

applfanboysbgon 3mo ago

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!

Retr0id 3mo ago
The PR is against bun's fork of WebKit, not upstream.
- applfanboysbgon 3mo ago
  Oh, my mistake, I thought they were doing the zig thing again.
  - bakkoting 3mo ago
    They didn't open a PR against zig either, the compiler concurrency work they did was also only ever in their own fork.
- fg137 3mo ago
  The title is of this post is definitely confusing if not misleading.
  - talldeck 3mo ago
    Besides, the title should probably have referred to it as "a giant open PR" or something, because I don't think what the submission is trying to focus on is the feature itself.

gavinray 3mo ago

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.

forrestthewoods 3mo ago
…but why? JS/TS does not seem like the right tool for the job?
- nesarkvechnep 3mo ago
  It's probably what they know so not anything new should be learned.
piterrro 3mo ago
I honestly should print that comment and hang it on a wall. > …competitively-performant… Care to explain competitively to what?
n_e 3mo ago
You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.
- quotemstr 3mo ago
  Exactly. Nothing stops your writing a high-performance parallel database in TypeScript today. Given that runtimes and tooling are actually pretty good, I think TypeScript is actually a fine choice of language for the task. The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space. There's a high performance database called "PostgreSQL" you may have heard about. It doesn't use threads. It uses separate processes and shared memory: just like standard JavaScript, with its service workers and SharedArrayBuffer. If not sharing an address space is good enough for PostgreSQL, it's good enough for your TypeScript database. The problem with shared-everything, unmarked, preemptive-parallel concurrency is that 90% of the time it gets used by people who don't know they shouldn't.

stephen 3mo ago

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

bastawhiz 3mo ago
That doesn't help anyone using Node. I don't want to have to start using a new runtime because my compiler is slow. That's wild.
- stephen 3mo ago
  You're already using a new runtime with tsgo -- it's golang at build time -- but still running Node in prod, so the same could work here. :-) Agreed I would not want all Typescript users forced to use /this/ runtime, but if the TS team shipped tsc as "oh now it's uses a special fast JS runtime" (just like tsgo is a different runtime) I'd love to at least have the option of using the same special fast runtime in my own still-written-in-TS apps. Seems I've either struck or a nerve, or miscommunicated, given the insta down votes.
  - jitl 3mo ago
    if there was a thingy that compiled JS to a 10mb native executable with shared heap multithreading, im sure we'd use it. however, no one has invented such a thing. until this pr.
    - stephen 3mo ago
      Right! That's why I think this is an exciting development. I assume everyone is downvoting me for "liking LLM slop", but really I just like the competition that "this is possible!" And would love a slop/non-slop/whatever version in Node/v8. Someday!
      - jitl 3mo ago
        same. ts with thread + struct would be a killer language. i pray anthropic buys roblox to get pizlo to actually land this

anematode 3mo ago

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.

bojan 3mo ago
The acknowledgement is in the PR description, section "The design, and what it's based on".
- anematode 3mo ago
  Thanks, fixed

asxndu 3mo ago

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.

Retr0id 3mo ago
Last time I read the bun docs I spotted an off-by-one bug in sample code, so I opened a github issue. An AI bot responded, confirming the issue, and opened a PR to fix it - A simple "+ 1" added in the right place. Two other AI bots reviewed the PR, which went on for several rounds of "improvements". Last time I checked, neither the issue nor the PR received any human attention (actually I just checked again, and the PR has been closed by stalebot).
- Aurornis 3mo ago
  > (actually I just checked again, and the PR has been closed by stalebot). Can you provide the link?
  - Delgan 3mo ago
    I, too, was curious to see it in practice. Here is the ticket opened by @retr0id: https://github.com/oven-sh/bun/issues/28030 https://github.com/oven-sh/bun/issues/28030 And here is the swarm of bots / LLMs / agents that open, review and bikeshed the PR before it's closed by the stalebot: https://github.com/oven-sh/bun/pull/28031 https://github.com/oven-sh/bun/pull/28031 It's hilarious. But also a little sad.
    - Retr0id 3mo ago
      Yup, that's the one.
      - Phelinofist 3mo ago
        That's pure comedy

nasretdinov 3mo ago

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

pizlonator 3mo ago
No language runtime is ever in a state of "obviously no bugs". Good luck demanding that of anything of JSC's or LLVM's complexity
- TomatoCo 3mo ago
  On one hand, sure, the entire point of a programming language is to make complex ideas able to be expressed in simpler abstractions. On the other hand, we can damn well try.
  - pizlonator 3mo ago
    Damn well trying to enforce an "obviously no bugs" rule in a language runtime would mean zero progress in language runtimes. We certainly wouldn't have gotten to where we are with runtime and compiler quality and performance if we had damn well tried to enforce such a rule
    - nasretdinov 3mo ago
      IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong
      - pizlonator 3mo ago
        Adding concurrency to JavaScript definitely falls in the "complex enough" category So does basically any feature or optimization in a JS runtime

Yoric 3mo ago

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

pjmlp 3mo ago
The JS / interoperability is why V8 eventually added a C++ GC.
- Yoric 3mo ago
  But last time I checked (which was admittedly a while ago), JavaScriptCore didn't have one, no?
  - pjmlp 3mo ago
    No idea, I never used it, nor looked into its internals.

quotemstr 3mo ago

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.

12_throw_away 3mo ago
In contrast, I don't know that much about VMs. But if you're making a big fundamental change to a system, I do know that it shouldn't start with a single "+279,276 -4,272" PR. It starts with a small patch with the core of the change so that everyone can understand what it does and how it works. (I mean, ideally, a change like this starts with documentation, discussion, diagrams, surveys of existing implementations, etc, before you start writing code) You don't cram everything into a single 270K line PR, even (especially) with an LLM, unless you specifically don't want anyone else to look too closely at what you did.

richardbarosky 3mo ago

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

RealityVoid 3mo ago
Soo... Essentially, still threads, but no shared state between threads, and they talk through this message interface?
- masklinn 3mo ago
  Threads which can’t share state are called processes.
  - RealityVoid 3mo ago
    Fair-ish point, if a bit cheeky. But threads can be still threads, i.e. in the same address space, but without actually having shared state between them. And then they're still threads, not processes. You could also have stuff like message ques going between them, the cost of passing data around is small then, you don't have do leave user space to put stuff in the mq's. But can you still call it "not having shared state"? I'd say yes, even though you do share memory and you do have the mutually accessible que. But I can see why you could argue otherwise.

torben-friis 3mo ago

>Scalability, measured (the honest section) Ugh.

greenchair 3mo ago
almost spit out my drink!
poly2it 3mo ago
I can't stand Claude's "honesty". Anthropic should hire some writers and linguists to make the output a bit more bearable. It's mentally taxing to read this type of dull text for hours every day.
- queenkjuul 3mo ago
  I just can't do it. I barely skim Claude PR reviews and have no qualms asking someone to summarize in their own words if they've sent me two pages of Claude slop
mahogany 3mo ago
The entire PR description is filled with LLMisms. I find this style so hard to read, it’s almost nauseating these days. My eyes start to glaze over and I stop reading pretty quickly after. I’m having to deal with this a lot at work these days unfortunately. I mean, did anyone even read or verify this output? When I read this type of stuff, I have the nagging suspicion that I am the proofreader and I have to do the verification myself. At that point, what are we even doing? I can generate Claude output myself… I know I’m being overly dramatic but this sort of thing feels so wrong and inhuman(?) to me for some reason.
rbonvall 3mo ago
Yes, that's the smoking gun!
- JamesSwift 3mo ago
  151 commits, 1826 files changed and claude found 0 smoking guns? I call bullshit. It found 3 in one run-of-the-mill query the other day

piterrro 3mo ago

think of all the poor web devs trying to use multiple threads on top of asynchronous operations. wild.

hexasquid 3mo ago
Standard contempt for web developers.
- JCTheDenthog 3mo ago
  [flagged]
  - curtisblaine 3mo ago
    Worth noting it's not web devs pushing for React in the Windows start menu. It's PMs looking at the problem and concluding React is the least painful way to solve it (correctly or incorrectly, but I doubt they optimize for the same measurements you do). Ink (the React renderer) in Claude code, on the other hand, makes a lot of sense for interactive CLIs where you want to componentize your menus and dialogs. Actually not using a component framework normally ends up in state / render chaos. Re: mayflies debating politics: React has been there for 13 years, and while the interface has shifted a couple of times (object factories to classes to functions), the main idea has always been really simple and really stable: isolated declarative components that can optionally have state and side effects. Many other popular frameworks have come and gone in the meantime.
- deleted 3mo ago
  [deleted]

sothatsit 3mo ago

It’s pretty incredible to me that a mammoth change like this is possible to prototype now using LLMs. It makes me wonder how much of our software stack will become more malleable to big ideas and experiments in the future, like Filip’s idea here. Even if you don’t want to merge the code, it’s still an incredible existence proof that something like this could work.

rzmmm 3mo ago
Bingo. Dozen LLM-prototypes and then a manmade final patch which is merged.

mwkaufma 3mo ago

[flagged]

xlii 3mo ago

I wonder if I'm the only one for whom the bun project vanished completely. In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package. Even it that'd be the best code and design in the world, I won't use it. I don't trust it.

monkaiju 3mo ago
Im here with ya :)
sibeliuss 3mo ago
The problem is that you need to twist the cube
egorfine 3mo ago
Yeah, I have prepared our company software for migration back to node. I would like to read the promised Jarred's blog post (if it ever comes out) before pulling the plug though.
- afavour 3mo ago
  I’m amazed folks ever migrated to it at a workplace level TBH. It’s a VC funded runtime, something was always going to happen to it. Node is boring but its governance and ownership is clear.
  - tyre 3mo ago
    Well, it was (is?) significantly easier to use, faster, the team behind it is fantastic, and generally had enough compatibility to run the projects I needed it to. When it’s enough of a drop-in replacement, that’s more than good enough. As long as we’re not adding a hundred bun-specific things, it’s not terribly difficult to back out of, either. Kind of a no-brainer.
    - afavour 3mo ago

throwrioawfo 3mo ago

> Shared-memory threads for JavaScriptCore. new Thread(fn) runs fn on another thread, in the same heap, with the same objects. No structured clone, no message passing, no SharedArrayBuffer-only escape hatch. You share an object by sharing the object. If you can't even be bothered to write a non-slop PR description, it doesn't bode particularly well for the content of the PR itself...

user43928 3mo ago
I previously gave this author and the bun rewrite the benefit of the doubt. But an obvious slop PR to the WebKit repository? I'd tap out here too if I was a maintainer. Even if the change was perfect, if you could not be bothered to write the PR description, I am not going to waste my time with it. Edit: My bad, the PR is to a fork, in that case it's not our business how the PR description is written.
- Me1000 3mo ago
  It’s a PR on their private fork, they’re not expecting to have this accepted upstream.

the__alchemist 3mo ago

Bun alert!

tomjakubowski 3mo ago

For what it's worth: this isn't a PR on mainline WebKit. The PR is on bun's own fork of WebKit (and JSC), which already has a bunch of their own changes.

mirekrusin 3mo ago
Did they rewrote WebKit in Rust or not yet?
- anematode 3mo ago
  I'd actually love to see a relatively high-performance (i.e., including a decent JIT) runtime for a dynamic language that's written in Rust. There's a lot of implementations like Rust Python, the Boa JS engine, etc. that are purely interpreted – and fun! – but I haven't seen a proper, high-performance VM yet. I considered writing such a JVM in Rust, following writing one in C (https://github.com/anematode/b-jvm https://github.com/anematode/b-jvm) that could JIT WebAssembly code and run in the browser, but decided it would be too time-consuming. Obviously such a VM would involve a lot of unsafe, but I'm wondering if you could establish some proper, compile-time-checked invariants that make things a lot safer, without the complicated sandboxing that modern JS runtimes use to make it harder for JIT bugs to escalate into full blown RCE.
  - jitl 3mo ago
    rust seems alergic to the un-safety required of "i dynamically built this executable code segment just now, please jump into it"
    - anematode 3mo ago
      wasmtime exists
      - jitl 3mo ago
        yes i love to use a language runtime within another language runtime for a sweet sweet 30% performance penalty

skeledrew 3mo ago

This has me thinking of Python's NoGIL movement.

gwbas1c 3mo ago

Back when Node was the new kid on the block, the single-threaded async model was justified by pointing out that the major challenge with multithreading was shared memory. It's one of the strong points of the language / environment, because you never have to worry that some callback will run on another thread. Javascript shines when it's handling multiple concurrent IO operations, and concurrent operations can become very thread-like with async/await syntax. Multithreaded code in this context only helps with CPU-bound operations; but if I was doing something CPU-bound, I'd probably choose a different language. One thing I wonder, does Bun (or Node) have a way to call into native code on another thread, but still keep single-threaded once back in JavaScript?

jitl 3mo ago
yes, all of node.js is built on such operations. what do you think is happening when you `await fs.promises.readFile(name, 'utf8')`? it dispatches a libuv thread to read the file you want, and resolve the promise when the background thread has completed the operation.
- kikimora 3mo ago
  Except there is often no background thread but async IO.
- gwbas1c 3mo ago
  That really varies significantly depending on the underlying OS. On Windows, you can do threaded (IE, your thread blocks) or async (you have a callback) IO. There isn't a requirement to spin up a background thread to perform non-blocking IO.

pavlov 3mo ago

This LLM PR description style is getting very tiresome. The obvious signs are the little lists (“not x, not y, not z”) and pompous declarations like this: “The bring-up log at the bottom is honest about what broke and what it took.”

balgaly 3mo ago

[dead]

curtisblaine 3mo ago

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

kikimora 3mo ago
This is from PR: v1 collects synchronous and stop-the-world Go build performant web app that has stop-the-world all the time.
- curtisblaine 3mo ago
  You bypass GC by allocating pools of array buffers at the cost of low-level memory management.
  - kikimora 3mo ago
    So you add threads to allow a shared objects graph with a side effect of more frequent stop the world. Then you fight stop the world by resorting to low level memory management. But if you go level why not allocate a shared array buffer and share it across workers? Something you can do today without threads.

moomin 3mo ago

Look, I’m not an AI hater, but AI is… not great at multi-threading code. And having it analyse multi-threaded code proves nothing because… it’s not good at multi-threaded code. This isn’t entirely shocking because I’m not good at it either and need to write in some very particular ways to have even a hope of being correct. But basically, unless it was written by a genuine expert, I wouldn’t want to even glance at this PR. And it wasn’t.

murderfs 3mo ago
I don't think AI is particularly worse at multi-threading code than humans are: humans are notoriously bad at it. I've had reasonably good success with telling Claude and Gemini to go into a codebase, insert clang -Wthread-safety annotations, fix any issues it finds, and refactor code that isn't amenable to the annotations to make it possible.
- marshray 3mo ago
  But there are any number of humans who will tell you that humans are bad at multithreading the codes and all but the smallest codebases are headed for heisenbug deadlock city if you do things like they told you to in that Introduction to OOP with JavaTM book. But is Claude going to tell you "No, dear user, this project is going to follow an excessively simple and sub-optimal locking regime because experience shows that it is easier to write code than it is to reason about its exponentially-growing complexity" ?

zarzavat 3mo ago

This em-dash stricken PR is yet more evidence that the bun project has AI psychosis. The most important feature for a language runtime is reliability. It's the foundation, it should be boring. I need to know that the foundation is stable so that I can control the reliability of whatever's built on top. AIs hallucinating a multithreaded JSC is not boring, it's scary.

nozzlegear 3mo ago

> Scalability, measured (the honest section) Barf

moogly 3mo ago
Heh, are the other sections dishonest, then? Yuck.

l11r 3mo ago

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

emilfihlman 3mo ago

I would just like to point to a single issue that has major ramifications in using Bun: https://github.com/oven-sh/bun/issues/14144 https://github.com/oven-sh/bun/issues/14144

Jarred 3mo ago

I’m the author of this PR. This PR is an implementation of the design from https://webkit.org/blog/7846/concurrent-javascript-it-can-work/ https://webkit.org/blog/7846/concurrent-javascript-it-can-wo.... I think it would be really cool if JavaScript had true shared object multi-threading without compromises (SharedArrayBuffer, postMessage are not that). If we had both threads and structs, it’s likely the TypeScript compiler would never have needed to be rewritten in Go. The title should be changed to clarify that it’s a PR to Bun’s JavaScriptCore fork and not the upstream WebKit. This PR is scarier to merge than Bun’s Rust rewrite PR. There are a good number of benchmarks/stress tests, unit tests, and also TSAN runs and security scanner runs, but this is a more complex change than the Rust rewrite (yes, really). I’m also worried about syncing with upstream - today the “fork” is mostly a bunch of patches, but with this PR, changes to the JIT need to be reviewed for behavior when multiple threads are in use. Our best bet for this to move forward is figuring out a way for some constrained version to be upstreamed into WebKit proper, if that makes sense and if they’re interested. And yes, the PR description is entirely Claude.

aurareturn 3mo ago
While you're here, what's the status of the Rust rewrite and that blog post you promised to write?
- dsissitka 3mo ago
  It's a strange world. Rust rewrite: 6 days.[0] Blog post: 37 days and counting. [0] https://xcancel.com/jarredsumner/status/2060050578026189172 https://xcancel.com/jarredsumner/status/2060050578026189172
verandaguy 3mo ago
I've seen the Bun Zig->Rust MR a few weeks ago when it was current. Now I'm seeing this, and I have to ask, since you're here: Is there no way to make this changeset smaller? At work, I've usually written large patches. I used to be worse at it. I was mentored out of it, and while I still like my patches to be complete, I balance that with the available bandwidth of the team and what the team can reasonably actually process. For perspective, my "large patches" were PRs on the order of 10-12kLOC for relatively big features. I consider those to be on the upper end of what is reasonably reviewable by a small, non-dedicated team, and towards the upper limit of the kind of PR where I can speak for nearly every line of code, what it does, and why it's there. On the other hand, now, LLMs are part of the equation, and they can (and often do) write code in insane volumes. They arguably tend towards extreme verbosity, without even talking about docs/markdown files. While LLMs are part of the workflow, my company, and those my friends work at, have all instituted policies of the developer attaching their name to the code ultimately being responsible for the output (which IMO is a lazy strategy, but I can't think of a much better one under the circumstances). I cannot, personally, fathom how you can stand behind a single changeset spanning 2000 files and a quarter-million lines of diff. Do you consider this sustainable? At this point the code bases are very quickly getting away from us in the open source community and even in proprietary code bases, and these are important code bases. Often very complex, often legacy. Who ultimately still owns these? Who's really going to be accountable if things go wrong?

JamesSwift 3mo ago

Ive said many times in my day-to-day convos around AI that Ive come to realize more and more that AI is a solo endeavor. Its very difficult to scale things to more people if you are trying to use AI for more than just speeding yourself up. AI is the epitome of the saying "if you want to go fast, go alone". This PR and the rust rewrite are incredible in scale and ambition. I still think theres a middle ground though of traditional committee-driven design with AI-driven iteration and POCs.

Decabytes 3mo ago

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

gkfasdfasdf 3mo ago
The latest version of Claude Code is the compiled with the Rust version of Bun, I've been using it and haven't noticed any regressions.

roblh 3mo ago

Putting on my tinfoil hat. Did Anthropic even buy Bun because they actually use it or was it just an excuse to lob ridiculous PRs at things with at least a little bit of credibility behind them. Their way of trying to set a precedent for accepting AI code into bigger open source projects.

rzmmm 3mo ago
The author has huge online following, and influence over developers. I don't doubt the author is genuinely interested in this, but the employer definitely is supporting this too.

lmc 3mo ago

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.

westurner 3mo ago

Notes on TLA+ in addition to fuzzing on "Ideas and resources for fuzzing shared-everything threads · Issue #84 · WebAssembly/shared-everything-threads" https://github.com/WebAssembly/shared-everything-threads/issues/84#issuecomment-4777697636 https://github.com/WebAssembly/shared-everything-threads/iss...