Live data from Hacker News

Rewrite Bun in Rust has been merged

github.com

731–740 of 822 posts

Re: Rewrite Bun in Rust has been merged

#731
Remember the top comment to this Hacker News thread? https://news.ycombinator.com/item?id=48016880 "This is an overreaction." "302 comments about code that does not work." "We haven’t committed to rewriting." "There’s a very high chance all this code gets thrown out completely."

Well. That was about a week ago.

Re: Rewrite Bun in Rust has been merged

#732

Earlier quoted context omitted.

Jarred had tweeted that they're using the rust version internally with Claude Code

This era is hilarious. I just wish I didn't have to rely on code written by these idiots.

You don't, pi with a codex subscription is great. Mario Zechner is on the opposite end of that AI hype spectrum.

Until we can daily drive pi + qwen/glm/kimi.

Re: Rewrite Bun in Rust has been merged

#733

Earlier quoted context omitted.

Vibe coding a Rust rewrite of a widely used tool is basically catnip for the HN crowd.

Not if you use that tool, then it's just scary.

I would think the Zig implementation with 500+ issues on Bun's GitHub tracker mentioning "segfault" would be even scarier.

Re: Rewrite Bun in Rust has been merged

#734

Earlier quoted context omitted.

Does it take a phd in psychoanalysis to not see that the company that has been marketing the fuck out of lame publicity stunts, to not take advantage of another publicity stunt? Good lord, no wonder the public hates tech workers.

I refuse to blindly hate something because someone tells me to with no evidence, if you want to hate me for that, so be it, that sounds like a personal problem.

Show me the incentive and I'll show you the outcome.

Re: Rewrite Bun in Rust has been merged

#736

Earlier quoted context omitted.

"Short of..." indeed. You already know the answer, although it doesn't need to be general ; it only needs to work on a single codebase. A recent and highly relevant example is the migration of the TypeScript compiler to Go. They did not use an LLM to translate the code. Instead, they used LLM assistance to write a deterministic TypeScript-to-Go translator and then used that to translate the code. I have far more conf…

I think TypeScript to Go is far easier to translate than something to Rust though.

Is it? I wouldn't assume that. Go is a smaller and less flexible language than Java/Typescript (I say that as a compliment) so it's not clear to me that all Typescript idioms have an obvious Go equivalent.

Leaving aside ownership, Rust is a big, complex, expressive language. I'm not that familiar with Zig, but I think it tries to be a "better, modern C" so it seems like it should be easily possible to mechanically translate Zig into direct Rust equivalences. You probably won't get "good" idiomatic Rust at the end, but you should get working code that does the same thing.

Re: Rewrite Bun in Rust has been merged

#737
post #267

Earlier quoted context omitted.

Rust vs Zig "wars" etc. Also at some point Bun was acquired by Anthropic. And some people feared that this will greatly influence Bun's development.

I don't think Rust vs. Zig has anything to do with why people are talking about this. It is a large piece of "real software" that underwent a full language transition in ~1 week using LLMs. That is a big deal regardless of the language and will be a case study regardless of how it turns out.

>I don't think Rust vs. Zig has anything to do with why people are talking about this.

Maybe, but I've seen quite a few comments from people who felt sort of betrayed(?) by the decision. I feel like Bun was important for people as a project that advertises Zig and keeps it relevant even in it's current "pre 1.0" state.

Re: Rewrite Bun in Rust has been merged

#738
post #512

Earlier quoted context omitted.

Odd take. Bun was not option for me because or Zig. There was no security. Issue tracker has 3000 issues about segfaults. Now I might actually reconsider.

I don't believe you actually think it's odd to not want to run unreviewed code in prod. I accept that you might disagree, but I don't believe this is a take you haven't heard a million times before.

Usually it is about the trust. A lot of code is reviewed, but is the reviewer good enough to spot all the issues? Do you trust the reviewer? Usually the trust comes from the ability to see the code by yourself or for the high trust for the existing reviewer. Code is open, it is there, and Bun is a major project which will attract many eyes, and big issues will be sorted very quickly.

I did not mean that I would use it immediately, right now. But it eventually gets there much sooner than Zig, because "compiler" is one sort of reviewer that mitigates many memory safety issues.

So, my point is, that in very short time, this has much more potential than Zig had, because compiler is very strong reviewer for specific kind of issues which were plaguing the old implementation.

Re: Rewrite Bun in Rust has been merged

#740
post #368

When announcements say that rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573... On top of that, if you look at 'Pointers & ownership' and 'Collections' sections, the Bun codebase is already prepared, using internal smart pointer types that map 1-to-1 to Rust equivalents,…

> using internal smart pointer types that map 1-to-1 to Rust equivalents Smart pointers weren't invented by Rust. If you write code in other languages with pointers you mentally model the same types already. > and `bun_collections` Rust crate already exists. This is wrong. It's part of the PR in the codebase. It did not previously exist.

Agree, after closer look smart pointer types are pretty standard and collections were indeed a part of migration.

But still, in order to prepare those detailed and very project-specific instructions you need to iterate on trying to convert the files from this specific codebase.

Post reply on HN