[self_awareness]

Yeah, but argumenting that "Bun codebase is a mess" is anti-Zig in itself.

The whole point of the borrow checker is to make it impossible to write wrong code. If Zig accepts bad code, but assumes people will have self-discipline to maintain it, how is that different from C?

C assumes good discipline, as well as C++. But it will happily accept bad code. So I'm not even sure what Zig is even improving on.

Rust was designed to answer this exact problem (among a few others of course).

So the argument "your code is fscking sheet" is very 1990's. In 2026 we need guarantees that we can't produce invalid code.

[lelanthran]

> The whole point of the borrow checker is to make it impossible to write wrong code.

> In 2026 we need guarantees that we can't produce invalid code.

Rust doesn't provide either of those guarantees.

If I were to rephrase your sentiment for accuracy: Rust disallows certain coding patterns. Certain classes of bugs can only appear in those coding patterns.

IOW, Rust disallows $FOO which is a superset of "specific class of errors". This means that while Rust prevents specific bugs, as a side-effect it will also prevent some correct code.

[self_awareness]

Very true. Rust prevents some good code as well.

Also it doesn't guarantee that the code is always 100% correct.

But I think this is the correct direction of programming language evolution.

[nextaccountic]

The borrow checker is a good tool (and it makes Rust objectively better than Zig to me), but it unfortunately doesn't prevent writing bad code

An issue with Bun is that it interfaces with a C++ JS engine and it needs unsafe. In this case, the best practice is to write a safe binding to encapsulate this external dependency (that's why in Rust we have -sys crates with raw unsafe bindings, and other crates with a safe interface on top), and then write your business logic entirely in safe Rust

However, the Rust port of Bun didn't follow such best practices (perhaps with good SDD practices it could, not sure about that). The resulting code has literally thousands of unsafe blocks. It also contains plenty of UB. The port already costed hundreds of thousands of dollars. It's unclear if Mythos/Fable is able to refactor it further to remove unsafe usage without introducing further UB, and how much it will cost

(here It's important to note something. Rust UB is in some abstract sense harder to deal with than C or Zig UB, because it also needs to uphold the guarantees of safe Rust. If you get to write your business logic in safe Rust that's a good deal, but the price of that is that your unsafe code has extra responsibilities)

[prollings]

Rust requires discipline too. I can go around using Arc, Rc and .clone() everywhere without upsetting the borrow checker, I can use let mut a bunch and pretend if, match, etc. aren't expressions. This results in worse code, and Rust didn't stop me.

The borrow checker prevents a set of errors from being possible, but it doesn't prevent bad code from being written.

[self_awareness]

It would be easier for you to argument that the user is expected to have discipline to NOT use "unsafe" keyword in all functions.

Because a lot of mechanisms actually still have guards in runtime. And using .clone() on Rc/Arc is actually the idiomatic/preferred way of evading the borrow checker if we can't design the data structure in a different way.

It's a big difference between cases when you need to spend brain energy to find ways to "out-smart" the compiler, and spend brain energy to "fit into the proper set of assumptions" of a programming language.

[DanielHB]

Static memory safety is a spectrum and so is code quality.

> how is that different from C?

Zig gives you far more memory and type safety than C and without a borrow checker and a complex generics system.

Zig also allows optional runtime checks (at the cost of runtime performance).

There is no better language between Rust and Zig because they have different tradeoffs that are better or worse in different scenarios. It is more like Rust vs C++ and Zig vs C.

[Jtarii]

Most bugs are logic bugs which rust does nothing to help you with.

[JuniperMesos]

I disagree; Rust's type system, which supports pretty rich algebraic data types, makes it easier to specify the correct data model for your system than it would be in languages with simpler type systems like C or Python. The ability to define enum types with arbitrary shapes for each variant, and then match on them in code, allows programmers to build better, more-accurate abstractions and have less fear of screwing up and causing a logic bug.

[kawogi]

In my experience, it absolutely does (at least if you use it idiomatically). Using the type system (esp. enums, Result and newtypes) makes a good bunch of invalid states irrepresentable.

This also helps to focus on the remaining things that could go wrong.

The integration of unit tests also lowers the barrier to just sprinkle some tests in, if you're unsure that you got an edge case right. Anf clippy (not stricly the language, but still kind of a core component) greaty helps to stay on the idiomatic track.

No silver bullet of course, but I never had so few runtime issues with any other programming language so far.

What logic bugs did you encounter the most?

edit: mobile typos

[chlorion]

Rusts memory safety is enforced via type safety. You can enforce more than just memory safety related invariants with the same type system?

I've seen many people make this claim and it's wrong but also silly. How do you think type systems work?