Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

181–190 of 330 posts

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

#181

Post by felooboolooomba »

xlii wrote: post #75

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.

Anthropic stuff runs on Bun, that's why they bought it. Should they be careful with Bun? Could Anthropic be a high value target for someone?

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

#182

Post by tyre »

afavour wrote: post #149
egorfine wrote: post #100

Earlier quoted context omitted.

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.

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.

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.

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

#184

Post by perching_aix »

adamddev1 wrote: post #159
okeuro49 wrote: post #117

Earlier quoted context omitted.

It looks like quite a lot of analysis went into the rewrite https://bun.com/bun-unsafe-audit If the tests pass, then why not accept the rewrite? An interesting article of Prisma using the rewrite: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute

People are forgetting that "if the tests pass" is not a good measure of reliability. CS 101 from Dijkstra: tests cannot prove the absence of bugs.

[dead]

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

#185

Post by dimava »

okeuro49 wrote: post #117
xlii wrote: post #75

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.

It looks like quite a lot of analysis went into the rewrite https://bun.com/bun-unsafe-audit If the tests pass, then why not accept the rewrite? An interesting article of Prisma using the rewrite: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute

The ones who accept rewrites are expected to support it indefinitely.

That's why Jared didn't consider using it for Bun even if it's undeniably better, they don't have human resources to support it

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

#187

Post by root_axis »

okeuro49 wrote: post #117
xlii wrote: post #75

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.

It looks like quite a lot of analysis went into the rewrite https://bun.com/bun-unsafe-audit If the tests pass, then why not accept the rewrite? An interesting article of Prisma using the rewrite: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute

We've repeatedly seen that these test-driven LLM rewrites consistently produce absolute garbage.

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

#188

Post by cozzyd »

tomjakubowski wrote: post #87
fg137 wrote: post #46

Earlier quoted context omitted.

Yet I rarely hear about it being used in production systems and replacing Node.js.

From what I've heard there are two main use cases: - People use bun as an all-in-one frontend web bundler. Personally, I just use esbuild (and webpack, if I'm working on a system using its module federation, like Jupyterlab). My understanding is bun has a machine-translated port of esbuild (ported to Zig, then to Rust) built into it. - Claude Code runs on bun. The second point has to be why Anthropic acquired them.

Somehow claude-cli left open completely nerfs my laptop's battery life. Is this a bun feature?

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

#190

Post by Jarred »

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.

Post reply on HN