Live data from Hacker News

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

github.com

101–110 of 330 posts

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

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

might as well use openclaw at this point. that's the same vibe I'm getting with bun. from engineering excellence and jesus this guy really sweats the details (using zig woah!) to wow this is just openclaw ai permagenerated stuff. not a fan

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

#103
post #36

Earlier quoted context omitted.

Just stop caring about quality. It makes it 10x easier to produce slop with AI if you never bother to check

I just wrote an internal report in my company. My conclusion from the project I'm working on is that, as of this day, there is no way to have both this so-called 20x performance improvement _and_ any kind of quality. Or security if whoever is running the agent has any token in an .env anywhere on the same file system. We'll see in which direction the CTO takes this. My bet is not on quality.

The company I work for, the code Opus 4.8 is able to generate, is higher quality than what was left behind by 10+ years of contractors that have come and gone.

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

#104

>Scalability, measured (the honest section) Ugh.

I can't stand Claude's "honesty". Anthropic should hire some writers and linguists to make the output a bit more bearable. It's mentally taxing to read this type of dull text for hours every day.

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

#105
post #74

The code needs to be not in the state of "no obvious bugs", but "obviously no bugs". Especially the programming language runtime. Otherwise there is no hope you can sustain any development whatsoever

Won’t happen unless the thing is implemented in lean4.

Proving something is correct doesn't automatically make it obvious though. For it to be obvious it needs to either be intuitive or it needs to be (reasonably) simple

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

#106

I knew it was possible :-) https://webkit.org/blog/7846/concurrent-javascript-it-can-wo...

It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.

My blog post explains how to make prototype chain operations work in the presence of threads

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

#107

Earlier quoted context omitted.

It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.

This won’t work well without a few other things, like structs https://tc39.es/proposal-structs/

Structs aren’t necessary for my proposal to work well

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

#108

Earlier quoted context omitted.

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

I think with ES6 and newer things really cleaned up and now we’re left with avoidable ugly parts, of which every language has. Before when you didn’t even have strict equality checking, for example, you were forced to know about implicit type casting. Getting on the same page with modules also helped a lot. Typescript directly in Node is great. Look mom, no build system!! I’m just hoping one day browsers will accept…

When did JS not have strict equality?

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

#109

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

It’s a PR on their private fork, they’re not expecting to have this accepted upstream.

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

#110
post #33

Earlier quoted context omitted.

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

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.

Why sad?
Post reply on HN