Rewriting in Rust

This post advocates rewriting incrementally instead of all at once. Just like Joel said back in 2000, and like everyone continues to always say to this day. Yet in practice, people don't actually do this; complete rewrites in Rust remain far more common than incremental ones, particularly when rewriting from a language other than C. The high-profile exceptions, like Linux, Windows, and Firefox, are codebases so huge and ancient that they obviously cannot be rewritten from scratch. When rewriting from scratch is an option, it tends to be taken.

The reason for this is pretty straightforward: Incrementally porting a codebase from another language to Rust (especially if it's not C) is a deeply unpleasant experience, because the interop tooling isn't good enough and you spend most of your time fighting it. Consider the case of rewriting from C++; in the simplest case, you use bindgen and cbindgen, which only work with extern "C" functions in both languages. So you effectively have to rewrite each API first from idiomatic C++ to C-in-C++, then translate to C-in-Rust, then rewrite again in idiomatic Rust. And then repeat for the next API. And so on. It's not going to take long for most programmers to go "screw it, I don't care what Joel said, at least when I rewrite all my work I'll be doing it in one language where anything can call anything else". cxx and autocxx modestly improve things, but still leave you with an impoverished API vocabulary and similar problems, and you still have to do the three-step rewrite for each API, one at a time.

This is also why TypeScript, Kotlin, and Swift worked so hard to have seamless two-way interop with JavaScript, Java, and Objective-C. Without that, they couldn't have credibly promised to replace the earlier languages (because large existing codebases where a rewrite wasn't economical would still be stuck with them), and so couldn't have gotten off the ground.

Crubit is supposed to fix this for C++-to-Rust, and I'm rooting really hard for it, but it's not there yet. For most other languages, a Crubit-like thing probably isn't even possible in principle, because the differences are too great.

(I'm not talking here about the use case where you started with a garbage-collected language but have hit a performance ceiling with it, so you rewrite just the most performance-sensitive parts in Rust, while continuing to develop the rest of the codebase in the original language. This is often a great way to use Rust, but it's solving an easier problem and so poses fewer difficult tradeoffs.)

The Bun rewrite is a long-term investment; the idea is that you initially compromise on idiomatic Rust for the sake of being able to keep shipping, but then the codebase becomes more idiomatically Rust-like over time. It will probably take another year or so to determine whether this works out.

(Note also that Bun inherently needs to use a lot of unsafe because a large fraction of its internal API surface is interlinked deeply and pervasively with that of JavaScriptCore.)

That's a really great point, and demonstrates a deep understanding of how AI is changing the landscape of writing online!

To me Rust is great where you don’t have to touch unsafe part. All the hard works are done by those skillful maintainers of the language and some core libraries such as tokio. I don’t see much value in it if either I have to work on the low-level stuff quickly (like implementing linked lists myself) or a complete high-level of i/o bound work like writing web servers.

> And then there’s the Stack Overflow Developer Survey.

Honest question, at what point is the Stack Overflow Developer Survey not representative of the average software engineer, many (most?) of who no longer use Stack Overflow?