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

251–260 of 330 posts

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

#251

Post by kibibu »

egorfine wrote: post #100
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.

Yeah, I have prepared our company software for migration back to node. I would like to read the promised Jarred's blog post (if it ever comes out) before pulling the plug though.

Take a look at Deno. It's pretty great and now has exceptional node compatibility

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

#252

Post by roblh »

Putting on my tinfoil hat. Did Anthropic even buy Bun because they actually use it or was it just an excuse to lob ridiculous PRs at things with at least a little bit of credibility behind them. Their way of trying to set a precedent for accepting AI code into bigger open source projects.

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

#254

Post by 1123581321 »

raincole wrote: post #212
rozularen wrote: post #198

Earlier quoted context omitted.

How the heck do anyone in their sane mind justify 10-12k LoC PRs? And Im not even going to get into OPs monster PR

It makes no sense. If a feature takes 10k loc to implement, it'd be a huge disservice for the reviewer and yourself to split it up into multiple PRs. Your comment is equivalent to saying that no feature ever takes 10 loc to implement. It'd be quite ridiculous to say that aloud.

Ideally, you could find pieces of that 10k that would also work as a standalone improvement to the app. I understand that team cultures can vary, but doing small features or refactors in service of a larger goal is nice, because while the reviewer knows you must be up to something, they can still approve your preparatory PRs as face value beneficial.

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

#255

Post by TiredOfLife »

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.

So you were fine with AI writing zig code, but AI writing rust is a step too far?

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

#256

Post by OuterVale »

llbbdd wrote: post #244
adamddev1 wrote: post #156

Earlier quoted context omitted.

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.

What is vibe coding?

The term was coined by Andrej Karpathy in early 2025 where he wrote:

> There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

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

#257

Post by RealityVoid »

masklinn wrote: post #84
RealityVoid wrote: post #49

Earlier quoted context omitted.

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.

Fair-ish point, if a bit cheeky. But threads can be still threads, i.e. in the same address space, but without actually having shared state between them. And then they're still threads, not processes.

You could also have stuff like message ques going between them, the cost of passing data around is small then, you don't have do leave user space to put stuff in the mq's. But can you still call it "not having shared state"? I'd say yes, even though you do share memory and you do have the mutually accessible que. But I can see why you could argue otherwise.

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

#258

Post by jitl »

fizzynut wrote: post #218
jitl wrote: post #207

Earlier quoted context omitted.

you can read a 10k pr in ~1-2hr. there’s nothing wrong with a 10k pr. i would rather review 1 10k pr than 10 1k prs or 50 200 line prs. attitudes like this make it seem like computers are incomprehensible and we’re lucky to ever land code at all

10k in 2hrs is 1.5 lines of code per second for 2 hours straight without spending any time to make comments, think about what the code is doing, etc. In pre-ai era that is just skimming and trusting the person who wrote it or the code changes are largely auto-generated or there exists an exceedingly simple test suite that is incredibly verbose. Post-ai you are ruining your code base, I probably have to spend 3-5x lon…

> Post-ai you are ruining your code base

if a pr is bad, i will reject it. that's the point of code review.

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

#259

Post by cavoirom »

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.

I agree with you. Human is a forgetful race, they just unlearned the zlib lesson.

Edit: fixed typos.

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

#260

Post by pieter »

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.

I was willing to gloss over the AI usage because I really like the Bun DX. I used Bun in Shell scripts and small prototypes before and decided to use it for something bigger.

But then in a week or so of use, tons of issues appeared. Use-after-free bugs when a client disconnects (both in Zig and the Rust port, funnily enough) which will kill Bun. Unimplemented feature which just return “0” always. Many backpressure bugs which means something like “return new Response(fs.createReadStream(bigFile))” will greedily read and OOM your box.

All of these have been reported, robobun has made fixes of various quality, but none of this has been addressed. Some of them have been reported for months.

I’d prefer Bun to work on stability rather than fancy features like image processing or threads.

Post reply on HN