Hacker News Reader

Comment by tptacek | Hacker News Reader

Whoah, hold on, the author isn't comparing writing graph structures in Rust to writing it in memory-unsafe languages --- they're comparing it to writing it in other memory-safe languages. You can't force a false dichotomy between Rust and C to rebut them.

View on HN

The comparison is contrived precisely because he's comparing it to other memory-safe languages. The borrow checker was introduced because the goal of the language was a memory safe language without a runtime. Falling back to indices isn't "ironic", its exactly how you would solve the problem in C/C++.

If your argument is "well Rust should be like Julia and have a GC", well thats not Rust. That language also exists, its possibly called OCaml, but its not Rust.

Rust have few garbage collectors[1] to chose from. For example, rust-cc is simple to use, just put #[derive(Trace, Finalize)] on struct.

[1]: https://crates.io/keywords/garbage-collector

The author is also suggesting that a data structure consisting of a sea of objects referencing each other works perfectly in Python. It doesn’t — Python’s GC can only collect it as a cycle, and this path is not immediate the way the refcount is. And you’re paying for refcounts. Even in a language with full tracing GC (Java, etc), you’re not winning any performance points by making a ton of objects all referencing each other.

Indices or arenas or such will result in better code in all these languages.

I think it's reasonable enough. The author already argued that there are reasons for non GC languages to exist, even if the performance doesn't matter to them.

One interpretation of the article is just the author doesn't personally like the borrow checker, but another interpretation is the author saying the borrow checker is just a bad abstraction.

So under the assumption that we don't have a GC available, what else can we compare the borrow checker against?

Author here. Yeah, I don't like the borrowchecker. But the motivation for me writing the article is the almost religious zeal with which many Rustaceans refuse to even acknowledge that the borrowchecker has a cost in terms of ergonomics, and that this translates to e.g. iteration speed.

You encounter borrowchecker issues? Well, you're just a beginner or not skilled enough. Rust makes you jump through hoops? No it doesn't, it just makes you pay upfront what you otherwise would have. It slows development? No, studies show it doesn't, you must be imagining it.

This is extremely annoying to be on the receiving end of. Even though it comes from a good place (mostly just excitement), it can feel like gaslighting.

You should look up the term "zero cost abstractions".

It's the organizing principle of the second generation of Rust's leadership[1]. Formally, it means "zero runtime cost"[2], but the now-former maintainers operated as though it meant Rust could get rid of all cost. The belief was that they can have a language that's faster than C, safer than Ada, more ergonomic than Java, more memory safe than Go, by either making the compiler do more work, or working more on the compiler. In practice, I think this belief caused massive complexity in the compiler, trade-off dishonesty in the community, and bad evangelism in domains unsuited for memory safety (e.g. games programming)

[1] Graydon, the original author of Rust, was against this idea.

[2] The term originates from C++ as "zero overhead" which was smaller in scope, and not a governing principle of the C++ language.

> but the now-former maintainers operated as though it meant Rust could get rid of all cost.

It always referred to runtime overhead, always. Same as C++. Which does consider it a foundational principle: https://www.stroustrup.com/ETAPS-corrected-draft.pdf

Reply on news.ycombinator.com