Hacker News Reader

Comment by herrkanin | Hacker News Reader

> How is that better than the Zig codebase you started with?

In contrast with the Zig codebase, you now have clear well-scoped unsafe boundaries you can iteratively fix one by one. This was not the case before.

View on HN

I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.

Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.

This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.

You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.

Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?

> Which is still a step ahead of Zig

First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.

> What's your point, that if we can't do everything perfectly in one step we can't do it at all?

My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.

> You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did

As in, they did not, which I can prove by using Miri and seeing hundreds of errors.

I didn't say they made a good, safe port. I literally said the opposite ("especially if you're flexible about actually upholding rust's rules"). You can get a line by line port to compile by just wrapping the parts that violate rust's ownership rules in `unsafe`. You won't have fixed the problem, and it won't be memory safe, but you can do it.

Well, only if Clone/Copy is compatible with the semantics of the API. I.e., the called function doesn't need to modify anything. No &mut params (or data members) except perhaps `&mut self` (which would refer to definitions the same file).

That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?

To be fair, you can throw an Arc<Mutex<_>> or Rc<RefCell<_>> at it if you're starting from something that has multiple "mutable borrows", but that adds runtime cost and complexity.

It’s fully possible to have scoped areas of borrow checker influence, which could be introduced after the port.

> clear well-scoped unsafe boundaries

This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)

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.

> 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.

There's only one language that's more dangerous than C and that is unsafe Rust. I say that only half-jokingly.

It's true and I write Rust and love it dearly. There is an entire book about working with the unsafe keyword and its aliasing rules: https://doc.rust-lang.org/nomicon/working-with-unsafe.html

What do you mean?

C is unsafe 100% of the time. Rust is only unsafe in unsafe{} blocks.

This is nonsense. There is quite a subset of C which is perfectly safe and an even larger one which can easily be safe with tooling. You could argue that unsafe keyword is easier to spot than the unsafe features of C, so that makes it somewhat easier to screen for issues. But if you screen for memory safety only, this is problematic anyhow.

Good job falling for the Zig propaganda. I say that half-jokingly.

EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.

This isn't propaganda, the Rust compiler's rules when using the unsafe keyword are difficult to uphold, which is why the community wrote Miri.

Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block?

And how does Miri help solve this issue?

> Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block?

By the engineer's wit of course!

> And how does Miri help solve this issue?

By detecting undefined behavior caused by violation these rules

> By the engineer's wit of course!

Seeing how the Rust compiler isn't an LLM, it can't really work on wit.

From the POV of a programmer, how would you implement an unsafe block? What is disabled vs what's enabled?

> By detecting undefined behavior

Say you are tasked with making Miri; how do you detect violations of these rules?

Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.

There is almost zero reason for a public facing, non-embedded project like Bun to use unsafe anywhere.

You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)

Reply on news.ycombinator.com