Mitchell Hashimoto has been thinking out loud about what it means that Bun just ported itself from Zig to Rust in about two weeks. His take: programming languages used to be lock-in, and they’re increasingly not.

That’s the kind of observation that sounds obvious until you realize what it actually implies. Bun didn’t just add Rust support or refactor a subsystem. They rewrote the runtime. The thing that executes JavaScript. In a different language. In two weeks.

Hashimoto’s point is that this makes Rust expendable too. “It’s useful until it’s not then it can be thrown out,” he wrote. If you can rewrite your core product that quickly, language choice becomes a tactical decision instead of a strategic one.

The conference story

Simon Willison picked up on this and shared a related anecdote. He was at a conference last week talking to someone from a medium-sized tech company with legacy iPhone and Android apps. They’d just finished an agent-driven rewrite of both apps to React Native.

The interesting part isn’t that they rewrote the apps. It’s why. Willison asked the obvious question: if coding agents make it cheaper to maintain separate native codebases, why move to React Native at all?

The answer isn’t in the post, but the question is the point. We’re used to thinking about cross-platform frameworks as a way to avoid duplicate work. But if AI can handle the duplicate work cheaply, maybe the calculus changes. Or maybe it doesn’t, and React Native still wins for other reasons. Either way, companies are running the experiment.

What this actually means

If you’re picking a language for a new project right now, this should matter to you. Not because you’re going to rewrite your codebase every quarter, but because the risk profile of language choice is changing.

Used to be that picking the wrong language meant years of technical debt. You’d be stuck with it until you had the resources for a rewrite, which might be never. Now the risk is more like picking the wrong framework. Still annoying to change, but not a decade-long commitment.

The Rust compiler team is apparently feeling this too. There’s an open pull request adding an LLM policy to rust-forge. The details matter less than the fact that they’re thinking about it. When a language’s core team is setting policy around AI-assisted development, that’s a signal about where things are going.

Who should care

If you’re starting a new project and agonizing over language choice, maybe agonize a little less. Pick something that works for your team right now. The future cost of being wrong is probably lower than you think.

If you’re maintaining a large codebase in a language your team doesn’t love anymore, the math on a rewrite might have changed. Not saying you should do it, but the cost-benefit analysis isn’t what it was two years ago.

If you’re a language designer, you’re competing on different terms now. Developer experience and ecosystem still matter, maybe more than before. But “we’ve already invested too much to switch” is becoming a weaker moat.

Who can ignore this

If you’re writing code that ships every few years and changing languages would require recertification or regulatory approval, you’re still locked in. Same if your codebase is entangled with platform-specific APIs that don’t map cleanly across languages.

And if you’re on a team that’s productive in your current language and not hitting any walls, there’s no reason to rewrite anything. The ability to switch languages easily doesn’t mean you should. It just means the decision is more reversible than it used to be.

The Bun rewrite is interesting because it’s not a proof of concept. It’s a production runtime that people actually use, and they rewrote it in the time it used to take to argue about whether to rewrite it. That’s the part that’s new.