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

281–290 of 330 posts

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

#281

Post by re-thc »

kibibu wrote: post #251
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.

Take a look at Deno. It's pretty great and now has exceptional node compatibility

> Take a look at Deno.

It's still heavily AI driven. Maybe less than Bun.

And they've gone in the route of just taking Node native libraries and what not just because they gave up on working out the compatibility. It's a bit of tacked on mess now.

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

#282

Post by gr4vityWall »

Jarred wrote: post #190

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 titl…

Is it possible to merge it, but keep it disabled by default? This could allow users to play with it on Bun while maintaining the expected behavior of JSC.

Maybe a separate build could work too.

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

#284

Post by kikimora »

curtisblaine wrote: post #261
kikimora wrote: post #216

Earlier quoted context omitted.

This is from PR: v1 collects synchronous and stop-the-world Go build performant web app that has stop-the-world all the time.

You bypass GC by allocating pools of array buffers at the cost of low-level memory management.

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.

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

#286

Post by LikesPwsh »

ok_dad wrote: post #273
lacoolj wrote: post #228

Earlier quoted context omitted.

Yeah, but you dont know who is vibe coding and who actually knows the output of what they had LLM make This leads to lack of trust, which the entire open source community is based on. Even if that vibe coded slop is flawless, the stigma will never go away.

That’s why you read the code and see what it looks like

In the infamous words of Spolsky - "It’s harder to read code than to write it."

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

#287

Post by duped »

Jarred wrote: post #190

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 titl…

> the PR description is entirely Claude

You should be embarrassed to admit this, let alone do it. The lack of shame people have these days is gross.

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

#288

Post by port11 »

amazingman wrote: post #233
solid_fuel wrote: post #230

Earlier quoted context omitted.

> I’m the author of this PR. > And yes, the PR description is entirely Claude. If you didn't write it, you're not the author. That's how it works, man. I would also love to read that blog post about the Rust rewrite, when you get it published.

The dogmatism on both ends of this argument grows tiresome.

Indeed. And so is reading “x is the real thing. Real y, real z.” Plus all the other filler crap.

If you can command a model, you can tell it to write without fluff.

The amount of effort to ask an LLM to do work is massively lower than the effort for a human to review it.

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

#289

Post by scared_together »

Eufrat wrote: post #239
TalkingCodeMonk wrote: post #232

Earlier quoted context omitted.

jhack's perspetive is something that is all too common in tech. The implication that if code is open source the owners and maintainers don't owe consumers anything because "you can always fork or build it yourself"... as if that were ever possible for the average user, or in a digital world where anything you do with a computer depends on endless recursive sub-dependencies. It's analogous to saying "it's your fault b…

I still really don’t understand what is so entitled about asking for a level of base empathy and care from maintainers. People now yell at you that their only obligation is whatever is spelled out in the license they attached to the code. I think this is the same place where the logic of Code = Law comes from. People who think that you can encode the legal/judicial system into a set of axioms. This is not how the law…

> I still really don’t understand what is so entitled about asking for a level of base empathy and care from maintainers.

> People now yell at you that their only obligation is whatever is spelled out in the license they attached to the code.

Let’s turn your implied question around: if a person wants to share code without any expectation of care and maintenance, what should they do? Is the entire concept bogus, and the developer should just keep the code to themselves forever? Or put a “DO NOT USE FOR YOUR BILLION DOLLAR COMPANY” in a README? What communication other than the license could reasonably be provided?

I think the person you’re responding to made a pretty good point that open-source is sometimes the passion of an unpaid 1-person “team” and sometimes the product of a VC-funded attempt to buy goodwill. The idea that asking for more from maintainers is entitled is clearly suitable for the former case but not the latter. Now that Bun has been bought out perhaps they are more deserving of scrutiny.

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

#290

Post by rcxdude »

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

Almost no test suite is comprehensive enough to cover even the kinds of bugs that will appear commonly in wide production use, let alone all of them. A big rewrite needs a lot of actual use as well to shake out the issues not covered by the test suite.
Post reply on HN