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

151–160 of 330 posts

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

#151

Post by murderfs »

moomin wrote: post #136

Look, I’m not an AI hater, but AI is… not great at multi-threading code. And having it analyse multi-threaded code proves nothing because… it’s not good at multi-threaded code. This isn’t entirely shocking because I’m not good at it either and need to write in some very particular ways to have even a hope of being correct. But basically, unless it was written by a genuine expert, I wouldn’t want to even glance at thi…

I don't think AI is particularly worse at multi-threading code than humans are: humans are notoriously bad at it. I've had reasonably good success with telling Claude and Gemini to go into a codebase, insert clang -Wthread-safety annotations, fix any issues it finds, and refactor code that isn't amenable to the annotations to make it possible.

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

#152

Post by quotemstr »

thedelanyo wrote: post #119
Waterluvian wrote: post #73

Earlier quoted context omitted.

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…

> I’m just hoping one day browsers will accept TS the same way. Wouldn't that be a direct kill of JS?

Did C++ kill C?

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

#153

Post by jitl »

curtisblaine wrote: post #142
quotemstr wrote: post #53

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…

Worth noting that javascript has had workers, shared memory and atomics for years and that you can use them today. Look at this guy writing a lockless allocator: https://greenvitriol.com/posts/lockless-allocator The only difference in this PR is that it makes threads light (workers are fat because they carry a whole v8 instance with them) and it makes shared memory default with light threads (now you need to pass a s…

js does not and has never had shared native objects between workers. there is a vast gulf between "here is a shared array buffer, feel free to interpret these bytes on another thread" and "your existing { ... obj } code just works but now is threaded".

shared array buffer is a decent primitive but nothing in the language uses it. if you want to make existing code that uses JS objects multi-threaded on top of shared array buffer, you might as well port it to Go -- it would be less work than rewriting it to use raw byte arrays.

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

#154

Post by teaearlgraycold »

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.

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.

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

#155

Post by jitl »

matsemann wrote: post #135
pizlonator wrote: post #26

Earlier quoted context omitted.

No language runtime is ever in a state of "obviously no bugs". Good luck demanding that of anything of JSC's or LLVM's complexity

My Elm code base was virtually bug free. My current python code base is riddled with small bugs. Some designs makes it easy to trust your code. Some make it die by a thousand paper cuts. Big llm rewrites I fear lead to the latter.

how similar is your elm app to a JIT compiler runtime?

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

#156

Post by adamddev1 »

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.

Everyone's excited about using AI to make their quick end products. But no-one wants to actually build on or rely on vibe-coded frameworks, languages, or tools.

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

#157

Post by jhack »

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

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

#158

Post by jitl »

gwbas1c wrote: post #120

Back when Node was the new kid on the block, the single-threaded async model was justified by pointing out that the major challenge with multithreading was shared memory. It's one of the strong points of the language / environment, because you never have to worry that some callback will run on another thread. Javascript shines when it's handling multiple concurrent IO operations, and concurrent operations can become…

yes, all of node.js is built on such operations. what do you think is happening when you `await fs.promises.readFile(name, 'utf8')`? it dispatches a libuv thread to read the file you want, and resolve the promise when the background thread has completed the operation.

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

#159

Post by adamddev1 »

okeuro49 wrote: post #117
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.

It looks like quite a lot of analysis went into the rewrite https://bun.com/bun-unsafe-audit If the tests pass, then why not accept the rewrite? An interesting article of Prisma using the rewrite: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute

People are forgetting that "if the tests pass" is not a good measure of reliability. CS 101 from Dijkstra: tests cannot prove the absence of bugs.

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

#160

Post by jitl »

anematode wrote: post #130
mirekrusin wrote: post #113

Earlier quoted context omitted.

Did they rewrote WebKit in Rust or not yet?

I'd actually love to see a relatively high-performance (i.e., including a decent JIT) runtime for a dynamic language that's written in Rust. There's a lot of implementations like Rust Python, the Boa JS engine, etc. that are purely interpreted – and fun! – but I haven't seen a proper, high-performance VM yet. I considered writing such a JVM in Rust, following writing one in C ( https://github.com/anematode/b-jvm ) th…

rust seems alergic to the un-safety required of "i dynamically built this executable code segment just now, please jump into it"
Post reply on HN