Live data from Hacker News

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

github.com

301–310 of 330 posts

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

#301
post #264

Earlier quoted context omitted.

Why do you feel so threatened that a person is ‘not impressed’ with a thing? Is it a moral fault to have doubts and concerns now? ‘Quick! Get him! We have found a skeptic ’ - sounds like a cult to me.

[flagged]

Claiming that something is someone's "entire personality" is extremely reductive and definitely hostile

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

#302

Earlier quoted context omitted.

Yes, you did. And it's a good design. You even did the GC question justice. My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things. The problem is that most developers are not you. Shared memor…

I don’t understand the thread phobia Comparing it to nukes is a bit extreme, don’t you think?

> Comparing it to nukes is a bit extreme, don’t you think?

Does Herb Sutter strike you as extreme?

https://herbsutter.com/2013/02/11/atomic-weapons-the-c-memor...

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

#303
post #194

Earlier quoted context omitted.

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.

original comment:

>> new codebase doesn’t have any

> No longer accurate. As of last week, Claude Code (an incredibly popular CLI tool) runs on Bun’s Rust rewrite.

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

#304

Earlier quoted context omitted.

For me it’s still up in the air. I won’t bet against them just yet. Also, did they say only one person reviewed it? I really doubt that. Don’t assume that what you can see on GitHub is the sum of all actions taken.

Yea, more likely for the majority of the code nobody reviewed it. It was over a million line diff.

If we are generous and assume a review speed of 1 line per second, that is still over 11 continuous uninterrupted days of review by a single person.

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

#305

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.

This is at odds with the idea that devs should take full accountability for LLM generated code. He also didn't even say the code was generated by Claude, just the description, although a decent amount of the code probably was.

This wouldn’t fly in college and it won’t fly for me. Claiming authorship means that you did the work. If you just prompt claude, then you authored the prompt. Not whatever claude slops out.

Jarred should be putting the prompts in github, since that’s the only original work involved.

And to be clear, I don’t think that being responsible for what is produced and claiming authorship are the same thing. I do agree that Devs are responsible for what they ship.

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

#306
post #157
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 not about the code or the use of AI. It's about the governance of the Bun project.

Nobody knows if the Rust AI rewrite was a good decision from a technical pov. We do know it was a unilateral and drastic decision taken behind closed doors and imposed onto all Bun users.

There was a poll on r/bun where only about 30% of users said they were going to use the Rust port.

https://www.reddit.com/r/bun/comments/1u3j4d7/are_you_going_...

Even worse, users on the Zig version have been pretty much abandoned. Any future bug fixes, security patches, etc will only be released in the Rust version.

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

#307
post #275
post #237

Earlier quoted context omitted.

Time bombs and just 2-3x the amount of code for the same thing. I recently rewrote a Claude generated feature from 3000 lines to 800. I guess AI fans are just predicting that no one will have to read the code in the future or something like that.

Yeah, I suspect the 2-3x amount of code, but I can't prove it yet. This will wait for the next report :)

Last study I read said it was 6x.

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

#308

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.

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

Okay. I gave it another read and I think we agree in general, but maybe disagree on how much memory model strangeness is acceptable, and how wide the gap between, “The behaviour can be understood by a developer,” and, “it should be possible to write a sequential JS program that creates an indistinguishable heap,” is likely to be.

The lower level bits round the object model etc. all look very solid.

Although structs may not be necessary to make JS concurrent their limitations might help in reducing where memory model strangeness could creep in.

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

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

Well, clearly more than just the description. Might as well be upfront about that.

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

#310

Earlier quoted context omitted.

Why sad?

It's a bizarre simulation of what would normally be a social interaction, and the (minor) effort I put in on my end just went into a black hole.

I see. I'm kinda wondering, did something break in the process? Or was it missing a human to do the final check and merge?
Post reply on HN