Hacker News Reader

Comment by cyber_kinetist | Hacker News Reader

> 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!)

View on HN

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.

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

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.

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

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.

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