Hacker News Reader

Comment by lolinder | Hacker News Reader

No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said:

> We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.

What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic.

Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.

View on HN

> We can gradually refactor it

Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it.

Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.

You're not helping your case.

So if I use Zig, I need to do all of that perfectly from day one and I don't get any help from static analysis to do it. Or else I've poisoned my whole program in scary ways and will require a total refactor where I still won't have any help and once again can't make a single mistake.

You're not helping your case.

> [what you just wrote]

So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.

Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine.

Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?

Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a total bs // SAFETY above it, leaving no sensible usage without invoking UB.

We often ensure a project holds water against miri. This one doesn't even pass for clippy.

You realize that what you're describing is inherent complexity in memory management? This is not something that you can dodge by using Zig, it's just part of the domain.

The difference is that in Rust you get strong guarantees for everything that is not inside of unsafe and clearly demarcated areas where things might go wrong. Even if you never eliminate a single unsafe block, the clear demarcation is valuable as an artifact in its own right.

The art of Unsafe Rust is marking the right demarcation with the right set of invariants that Safe code must adhere to inside the module that uses Unsafe. If you do this incorrectly, then even Safe code outside the unsafe block can cause undefined behavior.

Which is why having unsafe code without exactly specified invariants is practically useless: the Bun rewrite code has too many SAFETY comments that are incorrect and misleading, so most of the unsafe demarcations aren't helpful in achieving UB-free code.

Reply on news.ycombinator.com