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

191–200 of 330 posts

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

#191

Post by nozzlegear »

jhack wrote: post #157
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.

"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"?

How can you trust that they won't just rug pull all of the code you've hand-audited when they merge some 1800 file PR written by an LLM? Even if you decide to hold off on any security updates or minor bumps until you can hand audit again, what's the point? You could just go back to Node where they aren't engaging in a modern day Ship of Theseus every other week.

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

#192

Post by unknownfuture »

jhack wrote: post #157
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.

"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"?

It's called "mileage". This new codebase doesn't have any. Who knows what gremlins lurk in some of its darker corners.

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

#193

Post by aurareturn »

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…

While you're here, what's the status of the Rust rewrite and that blog post you promised to write?

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

#194

Post by Jarred »

unknownfuture wrote: post #192
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"?

It's called "mileage". This new codebase doesn't have any. Who knows what gremlins lurk in some of its darker corners.

> new codebase doesn’t have any

Claude Code & Prisma use it as of last week.

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

#195

Post by verandaguy »

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've seen the Bun Zig->Rust MR a few weeks ago when it was current. Now I'm seeing this, and I have to ask, since you're here:

Is there no way to make this changeset smaller?

At work, I've usually written large patches. I used to be worse at it. I was mentored out of it, and while I still like my patches to be complete, I balance that with the available bandwidth of the team and what the team can reasonably actually process.

For perspective, my "large patches" were PRs on the order of 10-12kLOC for relatively big features. I consider those to be on the upper end of what is reasonably reviewable by a small, non-dedicated team, and towards the upper limit of the kind of PR where I can speak for nearly every line of code, what it does, and why it's there.

On the other hand, now, LLMs are part of the equation, and they can (and often do) write code in insane volumes. They arguably tend towards extreme verbosity, without even talking about docs/markdown files. While LLMs are part of the workflow, my company, and those my friends work at, have all instituted policies of the developer attaching their name to the code ultimately being responsible for the output (which IMO is a lazy strategy, but I can't think of a much better one under the circumstances).

I cannot, personally, fathom how you can stand behind a single changeset spanning 2000 files and a quarter-million lines of diff. Do you consider this sustainable?

At this point the code bases are very quickly getting away from us in the open source community and even in proprietary code bases, and these are important code bases. Often very complex, often legacy. Who ultimately still owns these? Who's really going to be accountable if things go wrong?

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

#196

Post by JCTheDenthog »

UqWBcuFx6NV4r wrote: post #178
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_...

[flagged]

>Dude, stop with “slop”.

No.

It's a useful term, just like "clickbait" was 10 to 15 years ago (and still is). Trying to police other people calling it slop is reminiscent of Microsoft autobanning anyone using the term "Microslop" on their Discord, it's idiotic language policing and I'm not going to do it, simple as.

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

#198

Post by rozularen »

verandaguy wrote: post #195
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've seen the Bun Zig->Rust MR a few weeks ago when it was current. Now I'm seeing this, and I have to ask, since you're here: Is there no way to make this changeset smaller? At work, I've usually written large patches. I used to be worse at it. I was mentored out of it, and while I still like my patches to be complete, I balance that with the available bandwidth of the team and what the team can reasonably actually…

How the heck do anyone in their sane mind justify 10-12k LoC PRs?

And Im not even going to get into OPs monster PR

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

#199

Post by conartist6 »

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 ran your proposed changes by TC39 and their initial reaction was simply "no".

Is Bun the new IE6, then?

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

#200

Post by conartist6 »

conartist6 wrote: post #199
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 ran your proposed changes by TC39 and their initial reaction was simply "no". Is Bun the new IE6, then?

I have respect for past you, whose accomplishments are incredible. Current you I think of like a circus performer. I trust you to get ooohs and aaahs from the AI-race spectators who don't know any better. I don't want someone who is primarily in showbiz within 10 fucking miles of my infrastructure though
Post reply on HN