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

241–250 of 330 posts

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

#241

Post by pjjpo »

cmeacham98 wrote: post #179
jhack wrote: post #157

Earlier quoted context omitted.

"Even it that'd be the best code and design in the world, I won't use it. I don't trust it." Nothing about this sentence makes sense. What don't you trust about code you can see and audit yourself? What's untrustworthy about "the best code and design in the world"?

I don't have the time to audit all the code in a JavaScript runtime myself, so I am forced to make assumptions about the quality of the code based on my trust of the authors. Additionally, even if the code is good today, I am trusting their process will produce good code tomorrow (as migrating to/from bun has a non-trivial cost). A single person approving the code of an LLM is not such a process with today's technolo…

I think this is precisely why I don't mind it that much. I can't audit a huge codebase like a JavaScript runtime, whether the code is by a human from scratch or not. I just have to trust it as a black box.

I've seen LLMs produce terrible code indeed, but I have also seen humans produce terrible code. I haven't dug in to JS runtimes specifically but have read plenty of code in openjdk and cpython - there are many points that could be done better, but there's also no point since it's working, and keeping working code unchanged tends to be a smart decision in software engineering.

So of course the last point brings up whether it was a good idea to rewrite bun if it was working. Apparently the bun team thought the difficulty in getting changes in zig upstream meant it is. I don't intend to hold LLM code to a higher bar than human code - notably if the runtime continues to work, that is as good as I can expect from what is otherwise a huge black box of extreme programming (not that agile kind).

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

#242

Post by senordevnyc »

JCTheDenthog wrote: post #167
blcknight wrote: post #150

Earlier quoted context omitted.

I hear a lot of complaints about bun but nothing concrete about what broke in the migration. You are also assuming one prompt, and then arguing against your assumptions with zero evidence. It is lazy arm chair criticism.

>I hear a lot of complaints about bun but nothing concrete about what broke in the migration. Because it hasn't been released yet (at least not outside of some unstable branches). You can find some criticism of the actual slop here though: https://old.reddit.com/r/rust/comments/1t4033y/buns_rewrite_...

Hmm, it sounds like the main example of “slop” there is 1000 global variables.

I’m curious if that matters if humans are never going to even read this code?

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

#243

Post by ATMLOTTOBEER »

solid_fuel wrote: post #230
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…

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

Tell your boss I’ll do your job for 20% of your pay

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

#244

Post by llbbdd »

adamddev1 wrote: post #156
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.

Everyone's excited about using AI to make their quick end products. But no-one wants to actually build on or rely on vibe-coded frameworks, languages, or tools.

What is vibe coding?

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

#245

Post by koolba »

llbbdd wrote: post #244
adamddev1 wrote: post #156

Earlier quoted context omitted.

Everyone's excited about using AI to make their quick end products. But no-one wants to actually build on or rely on vibe-coded frameworks, languages, or tools.

What is vibe coding?

[flagged]

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

#246

Post by JCTheDenthog »

root_axis wrote: post #235
JCTheDenthog wrote: post #205

Earlier quoted context omitted.

Got any specific examples? I believe you, I'd just like some concrete examples to show my coworkers.

Sure. https://www.theregister.com/software/2026/02/13/anthropics-a... https://pivot-to-ai.com/2026/01/27/cursor-lies-about-vibe-co...

Thanks!

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

#247

Post by JCTheDenthog »

senordevnyc wrote: post #242
JCTheDenthog wrote: post #167

Earlier quoted context omitted.

>I hear a lot of complaints about bun but nothing concrete about what broke in the migration. Because it hasn't been released yet (at least not outside of some unstable branches). You can find some criticism of the actual slop here though: https://old.reddit.com/r/rust/comments/1t4033y/buns_rewrite_...

Hmm, it sounds like the main example of “slop” there is 1000 global variables. I’m curious if that matters if humans are never going to even read this code?

>I’m curious if that matters if humans are never going to even read this code?

If by never even read you don't include attaching a debugger to solve an issue. 1,000 global mutable variables would make debugging anything an absolute nightmare.

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

#249

Post by weird-eye-issue »

solid_fuel wrote: post #230
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…

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

[flagged]

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

#250

Post by kennywinker »

pjjpo wrote: post #241
cmeacham98 wrote: post #179

Earlier quoted context omitted.

I don't have the time to audit all the code in a JavaScript runtime myself, so I am forced to make assumptions about the quality of the code based on my trust of the authors. Additionally, even if the code is good today, I am trusting their process will produce good code tomorrow (as migrating to/from bun has a non-trivial cost). A single person approving the code of an LLM is not such a process with today's technolo…

I think this is precisely why I don't mind it that much. I can't audit a huge codebase like a JavaScript runtime, whether the code is by a human from scratch or not. I just have to trust it as a black box. I've seen LLMs produce terrible code indeed, but I have also seen humans produce terrible code. I haven't dug in to JS runtimes specifically but have read plenty of code in openjdk and cpython - there are many poin…

The difference is you can evaluate a small bit of the output of a human or a team of humans and expect all their other code to be roughly in the same ballpark of quality.

An LLM can’t be trusted to produce code and make higher level project structure choices of the same quality at all times, because it can’t be trusted at all - trust is for deterministic systems. But still it begs us to trust it. Every prompt that yields good results sets us up to expect good results, so we get lazy - and then the next prompt it spews out garbage.

Post reply on HN