Live data from Hacker News

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

github.com

81–90 of 330 posts

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

#81
post #38
post #23

Earlier quoted context omitted.

Last time I read the bun docs I spotted an off-by-one bug in sample code, so I opened a github issue. An AI bot responded, confirming the issue, and opened a PR to fix it - A simple "+ 1" added in the right place. Two other AI bots reviewed the PR, which went on for several rounds of "improvements". Last time I checked, neither the issue nor the PR received any human attention (actually I just checked again, and the…

Was the bug actualy soved?

No, it was closed as stale.

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

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

The problem is that you need to twist the cube

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

#83
post #23

Earlier quoted context omitted.

Last time I read the bun docs I spotted an off-by-one bug in sample code, so I opened a github issue. An AI bot responded, confirming the issue, and opened a PR to fix it - A simple "+ 1" added in the right place. Two other AI bots reviewed the PR, which went on for several rounds of "improvements". Last time I checked, neither the issue nor the PR received any human attention (actually I just checked again, and the…

> (actually I just checked again, and the PR has been closed by stalebot). Can you provide the link?

Here's a trivial docs issue I opened, where I had a similar experience:

https://github.com/oven-sh/bun/issues/31233

The difference is that the PRs to fix that problem were already open when I created the issue. I was unaware of them (I only searched for duplicate issues, not PRs addressing the problem). The robobun comment implies there are 5 open PRs addressing it, but I could only find two. They still haven't been merged, a month later.

https://github.com/oven-sh/bun/pull/30677 https://github.com/oven-sh/bun/pull/30747

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

#84

Don't have much to say on the topic but recalled this excerpt from the book Coders at Work in the chapter interviewing Douglas Crockford. ``` In my experience, the worst bugs are the real-time bugs, which have to do with interactions with multiple threads. My approach to those bugs is to avoid making them. So I don't like threads. I think threads are an atrocious programming model. They're an occasionally necessarily…

Soo... Essentially, still threads, but no shared state between threads, and they talk through this message interface?

Threads which can’t share state are called processes.

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

#85

> Shared-memory threads for JavaScriptCore. new Thread(fn) runs fn on another thread, in the same heap, with the same objects. No structured clone, no message passing, no SharedArrayBuffer-only escape hatch. You share an object by sharing the object. If you can't even be bothered to write a non-slop PR description, it doesn't bode particularly well for the content of the PR itself...

I previously gave this author and the bun rewrite the benefit of the doubt. But an obvious slop PR to the WebKit repository?

I'd tap out here too if I was a maintainer. Even if the change was perfect, if you could not be bothered to write the PR description, I am not going to waste my time with it.

Edit: My bad, the PR is to a fork, in that case it's not our business how the PR description is written.

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

#86
post #52
post #33

Earlier quoted context omitted.

I, too, was curious to see it in practice. Here is the ticket opened by @retr0id: https://github.com/oven-sh/bun/issues/28030 And here is the swarm of bots / LLMs / agents that open, review and bikeshed the PR before it's closed by the stalebot: https://github.com/oven-sh/bun/pull/28031 It's hilarious. But also a little sad.

Yup, that's the one.

That's pure comedy

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

#87
post #46
post #17

I am shocked by how good and comprehensive the bun docs & ecosystem is. Its so well contained I never need to look outside its ecosystem for basic components. It's a true "Batteries Included" runtime.

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.

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

#88
post #37
post #6

Counting 62 em-dashes in the PR description alone, are people reading those walls of slop anymore?

No human has ever read or will ever read the PR description. No human has read or will ever read any of the code, nor was any human thought involved in its creation. Everything is performative now. As long as you just keep your eyes closed and believe it all works, that's all that matters.

Does it not work? I'm watching for the explosion and following "told you so"s.

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

#89

Earlier quoted context omitted.

This is consistent with the endless contempt people have had for JavaScript and those that use it.

Yeah I don’t get that either It’s a super successful language

It's successful because it's been kept away from the kind of programmers who think the time spent to endlessly specify everything four times is nothing compared to the sadness of losing a byte or a cycle. These are the descendants of people who hundreds of years ago would have insisted that real work is in Latin. C++26 is available for them, or Node/React with hundreds of dependencies if they want JavaScript, or they can even compile and run whole operating systems into WASM now, or anything else. Just let JavaScript be the domain of people who do other things for fun.

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

#90
post #44
post #7

I will never get over the overuse of adjectives like "real" in LLM outputs, it dilutes the meaning of these words.

Related, spinning "I did something poorly" into "I am being honest" > Scalability, measured (the honest section) so what about the other sections?!

The dishonest sections
Post reply on HN