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]
Bun has an open PR adding shared-memory threads to JavaScriptCore
301–310 of 330 posts
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#302Earlier 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?
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
#303Earlier 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.
>> 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
#304Earlier 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.
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#305Earlier 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.
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
#306I 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"?
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
#307Earlier 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 :)
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#308Earlier 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
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
#309I’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…
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
#310Earlier 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.