Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by sothatsit
  • >Scalability, measured (the honest section)

    Ugh.

    by torben-friis
  • 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.

    by zarzavat
  • 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
    by nasretdinov
  • 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.
    by moomin
  • 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-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.

    by Jarred
  • I knew it was possible :-)

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

    by pizlonator
  • 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.

    by xlii

Explore Birbla archives