HN

Need help?
<- Back
Bun has an open PR adding shared-memory threads to JavaScriptCore

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

gr4vityWall

Comments (179)

  • xlii
    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.
  • nozzlegear
    > Scalability, measured (the honest section)Barf
  • pizlonator
  • moomin
    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.
  • nasretdinov
    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
  • torben-friis
    >Scalability, measured (the honest section)Ugh.
  • zarzavat
    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.
  • Retr0id
    Is there a human-authored description of the PR anywhere?How are there not race conditions all over the place?
  • gwbas1c
    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?
  • l11r
    tbh, that looks like AI psychosis caused by getting access to unlimited tokens
  • sothatsit
    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.
  • piterrro
    think of all the poor web devs trying to use multiple threads on top of asynchronous operations. wild.
  • anematode
    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.
  • tomjakubowski
    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.
  • mwkaufma
    Anslopic
  • skeledrew
    This has me thinking of Python's NoGIL movement.
  • gavinray
    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.
  • asxndu
    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.
  • bakugo
    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.
  • Yoric
    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 :)
  • adem
    I will never get over the overuse of adjectives like "real" in LLM outputs, it dilutes the meaning of these words.
  • pavlov
    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.”
  • throwrioawfo
    > 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...
  • curtisblaine
    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.
  • applfanboysbgon
    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!
  • richardbarosky
    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. ```
  • quotemstr
    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-worldAh, 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.
  • the__alchemist
    Bun alert!
  • lgtx
    Counting 62 em-dashes in the PR description alone, are people reading those walls of slop anymore?
  • balgaly
    [dead]
  • MuffinFlavored
    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... :/
  • stephen
    Amazing. This is what the Typescript team should have done instead of rewriting to golang -- innovate the runtime.