Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

As for the specific issue: it does not exist in Zig, because Zig does not have ownership.

In a nutshell, the LLM created abstractions that allow you to write unsound code in safe rust, which is squarely against the language.

To be specific: the abstraction takes a (shared) reference and uses unsafe to wrap it in an owned object, completely erasing le lifetime. In practice, this means users of the abstraction think they own the underlying memory: they choose when to free it. However, it just wraps a pointer that’s owned by someone else (it was a shared reference, remember?), thus it will be freed when you don’t expect it.

So why does it not exist in Zig: it’s a false contract about what it is. The Zig pointer is a pointer with no added lifetime information. You can hold a Zig pointer wrong, but you will hold a lying abstraction wrong. You will misuse it because it doesn’t do what’s written on the tin. You will write bugs with it.

And, LLMs will too. If they do not have the abstraction definition in their context, they also have no way to know the contract is lying.

Actually I think Rust says UB has occurred if you return a T which isn't properly initialized. For example if you unsafely MaybeUninit::assume_init() then Rust says that's UB even though all possible bit patterns for u32 are valid.

This is because that's not going to emit any machine code at all, and yet it will cause LLVM to do very nasty things, for example code which either prints "Odd" or "Even" by examining the integer may now print neither because that's faster and this uninitialized integer isn't odd, yet it also isn't even so...

I can understand where you are coming from, but I myself am coming from a quite different place. I'm a long-time Deno fan, and to me Bun was less interesting because a.) it seemed like a much-less-ambitious Deno, and b.) I don't want to learn Zig, so I wasn't likely to try to hack on Bun itself, even just recreationally.

But, I warmed up to Bun over the last couple years almost against my own will — trying to maintain a pretty large body of TypeScript code in a runtime-agnostic way (including even Node, since 24.2). I don't want to make any specific TypeScript runtime a requirement for my TypeScript code, unless there are really good reasons to do so.

But Bun (like Deno) kept providing those reasons. Postgres, SQLite, S3, websockets, local secrets (Keychain/wallet), bundling, compilation, killer speed. So I (somewhat grudgingly) started using Bun more, and even made it a requirement for some of my projects (albeit, in ways I could walk back later if needed).

Today, I have a bunch of API servers and frontend app servers which are bun build --compile --bytecode single executables ,that can run and be deployed virtually anywhere.

I've been very happy with it so far. But also, I don’t think that the way I am doing it is super-common, and now that they are doing this, uh... extremely ambitious LLM port, I am perfectly positioned to regret all of my decisions around Bun if this port ends up sucking.

So I'm a little nervous, but... what if it doesn't suck? That would be cool, because a.) they will have shown something interesting about what is possible with LLMs (albeit if you are rounds-to-a-trillion-dollars valuation frontier AI lab, lol, but still). And b.) going forward, Bun will be developed in Rust. We all have our own preferences, obviously, but to me, that's a win.

And if it does suck, though — that's super interesting too! Will be annoying to me to re-architect my Bun-specific shit to Deno, but for the world at large (and me, too) that's still interesting information!

Because Bun is perfectly positioned to do a huge LLM-powered port. They are one of the premier TS/JS runtimes, it's obviously and insane marketing pillar for the AI lab that bought them, they have unfathomable resources and access to the cutting-edge models that all of us don't get to play with yet, and for all intents and purposes, they have unlimited money to do this.

So if they can't do it — which will be really obvious, I think, if true — then it really just isn't possible yet, and all the naysayers were right.

Is there much value in it being written in rust if it's all AI slop?

That's exactly thing I'm trying to call out. AI coding has attracted a flood of people whose only goal is to make a quick buck out of shoddy work. They regard science and engineering as beneath them, and they're not shy about saying it, here and elsewhere.

Any serious professional in this field knows that software development is far from a solved problem. It wasn't before LLMs, and it isn't now. Responsible development takes discipline and respect for the hard-won lessons of past and present efforts.

But no, according to many here, being responsible makes you a "luddite." "Humans make mistakes too," that's what they'll say as they'll inevitably screw over people's lives with their reckless disregard for others. "It's not my issue to solve."

Seriously, haven't techbros already caused enough damage throughout society with "move fast and break things"? A lot of people are losing patience for this nonsense.