Live data from Hacker News

How is the Bun rewrite in Rust going?

lockwood.dev

211–220 of 412 posts

Re: How is the Bun rewrite in Rust going?

#211

Many repeat the point of “$165k is cheaper than team of multiple engineers working on the rewrite for a year”, which I think is flawed — the team of engineers would have produced idiomatic rust, and it would take probably 100k+ of tokens more to make the bun in rust idiomatic rust.

They also would have produced a team of engineers that knows the Rust codebase.

"Knowing the codebase" seems like an antithetical philosophy to LLM driven engineering orgs.

Re: How is the Bun rewrite in Rust going?

#212

I really do not understand how software developer think anymore. Using a LLM to translate a project in a short time, is by itself incredible. Just like one-shot whatever office clone. But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work. I have used LLMs to create st…

> Not understanding to the core the software you wrote, is going to exploded in your face.

Short-termism at its peak. Code maintainers will learn the hard way how to set the boundaries between ai-generated code, and human maintainable code.

Re: How is the Bun rewrite in Rust going?

#213
post #107

Earlier quoted context omitted.

If you ported UE5 to, idfk, Malbolge and ran Tetris on it and someone would dismiss it as “not impressive”, I would think they lost the plot too!

If you could successfully write Tetris in Malbolge, I would call that impressive indeed. Just writing Hello World was a major effort IIRC. The nature of the malbolge interpreter makes it more of a cryptography exercise than a coding one.

I'm gonna jump in here with some self promo - back in college I TA'd a class that, for a few weeks, taught Malbolge, and the only assignment was for students to write a program that printed their name.

After spending a lot of time thinking about the language, I came up with a relatively simple algorithm based on the language design - there are a few operators that mutate state, so basically just try combinations of those until your next memory cell contains the thing that you want, then lock those instructions in and advance.

Basically RNG yourself to victory.

The original code for that algorithm is here (python, + my own interpreter): https://github.com/wallstop/malbolge-toolkit/tree/dd942fb981...

I've since llmified it as an exercise.

BUT! The whole reason for this comment is to nerd say that printing stuff is relatively easy if you invest the time in learning the language's primitives and think of programming in it more as algorithms to operate on the op codes instead of literally writing code.

Now, to do more interesting things other than printing - I'd have to spend even more time thinking about the language, which I don't want to

Re: How is the Bun rewrite in Rust going?

#214
post #107

Earlier quoted context omitted.

It's the equivalent of porting Unreal Engine 5 to another language and then using it exclusively to run a 2D Tetris clone. Let's wait for the next Bun release when more real-world code is hammering it before declaring victory. (also, fwiw, a manual rewrite would be under the same scrunity and suffer from the same skepticism, at least when obviously rushed).

If you ported UE5 to, idfk, Malbolge and ran Tetris on it and someone would dismiss it as “not impressive”, I would think they lost the plot too!

LLMs are very impressive. Five years ago, the idea that we'd have software that you could ask - in English, mind you! - to rewrite an entire server side JS runtime and you'd get something which even kind of worked was squarely in the realm of science fiction. But the question isn't "is this impressive?", but rather "should the results of such a rewrite be relied upon?" (and specific to this thread, "is the fact that a use case which only touches a small subset of the features of said result appears to no be completely broken good evidence it should be?")

Re: How is the Bun rewrite in Rust going?

#215
post #182
post #175

Earlier quoted context omitted.

Any comment on the costs estimated in the article? especially the buildkite costs?

CI has always been expensive for Bun including before the acquisition. We build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64] and then run tests on multiple Linux distros with multiple shards, multiple macOS versions and Windows for each architecture. We recently started cross-compiling all the builds on Linux arm64 and that made it a little faster (I wrote a CLI tool to download the correct macOS head…

How come Bun uses Buildkite instead of self-hosting the CI infra?

Re: How is the Bun rewrite in Rust going?

#216

I'm not sure Anthropic even cares about "releasing" the next version. The rust one has been in use in Claude Code for more than a month now, used by millions of people, and that's as far as they probably really worry about it. They bought Bun for Claude Code and I doubt the open source project matters to them otherwise.

Why wouldn't they?

Bun is a major part of the web ecosystem, having it developed by them via AI, sounds like a gigantic pr win.

Re: How is the Bun rewrite in Rust going?

#217

Earlier quoted context omitted.

Rust contains the ability to do everything that C can, if you use `unsafe`. And a file-by-file rewrite in Rust from another language usually involves keeping the ABI and API between files very C-like (and unsafe). In practice this means that the result of a first pass this way has all the memory safety of C code, but with worse readability because Rust makes unsafe things less ergonomic. To actually get the safety be…

> one that an unsupervised LLM rewrite is probably not even going to attempt. Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).

An LLM definitely can do that work, but LLMs have a tendency to follow the path of least resistance unless you force them to do things properly and carefully supervise them.

Re: How is the Bun rewrite in Rust going?

#218

Earlier quoted context omitted.

A postmortem is for reflecting on something that went so wrong you had to kill it, and you want to objectively describe what led to that, and what lessons can be learnt from the failure. A retrospective is just the reflecting part, without implying you believe it is going to fail and you're looking for some schadenfreude ;)

I've been reading people use "postmortem" to describe software retrospectives for like... 15+ years. Mostly in the opensource, or marketing-blog spaces. The detailed investigation and fix report was a favorite genre of blogpost. And if someone's bragging about the design of an enhancement, or investigating a bug, then the overall product isn't dead. They're (usually) not talking shit to anyone. It's the bug that's de…

In the specific case of ship retrospectives, I prefer to call them “postpartums”.

Re: How is the Bun rewrite in Rust going?

#219
post #148

Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall. In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likel…

In Dutch there's a saying, "wij van wc eend adviseren wc eend", and it fits perfectly.

Re: How is the Bun rewrite in Rust going?

#220

Earlier quoted context omitted.

> produced idiomatic rust I keep seeing this. What is "un-idiomatic" rust?

Rust contains the ability to do everything that C can, if you use `unsafe`. And a file-by-file rewrite in Rust from another language usually involves keeping the ABI and API between files very C-like (and unsafe). In practice this means that the result of a first pass this way has all the memory safety of C code, but with worse readability because Rust makes unsafe things less ergonomic. To actually get the safety be…

> To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.

You can use deterministic linting for `unsafe` usage, have agents target `unsafe`, etc. It's pretty easy. You can even run `miri` against the code and give that as a tool for LLM feedback. I've done this all before and it works fine.

> The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).

I'm unconvinced that this is true. How could you tell? You only know about the rust bugs because rust makes them grep'able/ trivial to verify, there's no way of knowing which bugs existed in zig that didn't translate. Regardless, the problem is now trivial to understand in Rust and start to target.

Post reply on HN