Hacker News Reader

Comment by mrfredward | Hacker News Reader

>You still have to fight with borrow checking in Rust as in C++, it’s just not automated.

It's not that easy. The borrow checker gives you memory safety and thread-safety. In C++, you always have to worry about memory safety, so here the ownership model and borrow checker is a pure win. However, in C++ you don't have to worry about thread safety in a single thread...there's no barrier to passing pointers around and mutating things from different places in your code. In rust, the borrowchecker disallows shared mutable state...that's a huge win if you want to parallelize your code later on, but it also means that things that are trivial in C++ take a lot of thought and effort in rust, especially if you're thinking in a C++ paradigm (as opposed to coming from a functional language).

View on HN

My counter argument is nicely summed up by The Problem With Single-threaded Shared Mutability (https://manishearth.github.io/blog/2015/05/17/the-problem-wi...)

I like the blog post, and I mostly agree with you that shared mutability can cause problems in big programs. It's something I try to keep to a minimum in most code I write, and I'm better at avoiding it after learning rust.

The thing is, getting rid of shared mutable state entirely is a huge paradigm shift. It means many libraries (GUI libs especially) can't be cleanly wrapped. It means throwing away common data structures like linked-lists. A C++ programmer can learn the syntax of rust is a week, but it may take years to get comfortable with the borrow checker.

Yes, It's hard to deny the intuitive appeal, but what's notably missing from that blog post, and seemingly any other article about it, is a consideration of the cost/downsides of universal imposition of the "exclusivity of mutable references" restriction. Rust provides the RefCell wrapper to essentially circumvent the restriction on demand, but i) that also essentially circumvents the "invariant protection" benefits of the policy, and ii) you can just as easily use an equivalent wrapper[1] in C++ to impose the same restriction. At which point the difference between Rust and C++ just kind of becomes which policy do you want to be the zero-overhead default.

I mean you could imagine a hypothetical future scenario where it is demonstrated that the optimizers are good enough to essentially eliminate the run-time cost of RefCell wrappers, and a lot of Rust programmers just start wrapping everything with RefCells by default.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#exclusive-w...

> Rust provides the RefCell wrapper

There is also `Cell` (https://doc.rust-lang.org/std/cell/struct.Cell.html), which offers a different set of tradeoffs.

> which policy do you want to be the zero-overhead default

The one where:

- The compiler can make more optimizations

- I'm less likely to shoot myself in the foot my conflicting mutations

is a good default for me, so I'm in favor of Rust.

> a hypothetical future scenario where it is demonstrated that the optimizers are good enough

This sounds like the sufficiently smart compiler (http://wiki.c2.com/?SufficientlySmartCompiler) argument. While I'd love to live in this world, we aren't there yet.

Even in such a world, there would still be reasons to choose Rust over C, such as standardized dependency management or a rich type system.

Oh yeah, there are plenty of reasons to prefer Rust over C++. I think it's also reasonable to favor Rust's "exclusivity of mutable references" default as a matter of personal preference. I'm just not sure the formal or technical argument has yet been made that universally applying that restriction is necessarily the "better" default overall.

> It means throwing away common data structures like linked-lists

It does not require such; the Rust standard library even has a LinkedList (https://doc.rust-lang.org/std/collections/struct.LinkedList....).

> A C++ programmer [...] may take years to get comfortable with the borrow checker.

One of my earliest / biggest revelations when learning Rust went something like:

- Rust is stupid; I've been writing code like this in C for years, but Rust rejects it.

- ...time passes...

- Oh, I understand why Rust rejects this code now.

- OH MY GOD I'VE BEEN WRITING CODE LIKE THIS IN C FOR YEARS

A conceptual borrow checker is something that every C and C++ programmer should be running in their head for every line of code that involves references / pointers that they touch. I'm happy to let the automated algorithm provided by Rust do that for me instead.

Often when people [0] discuss the difficulty of writing linked lists in Rust compared to C++, they mean intrusive linked lists.

These are still very difficult in Rust. I've heard pinning being stabilized makes them possible safely, but I haven't looked further.

[0]: At least, when I was starting Rust, this is what I would mean when I complained about linked lists.

Another issue is that in real world types in fast programs usually can't be expressed and auto checked by a simple type system without mental/runtime overhead. For example, in many GPU kernels each thread visits patterns like (ax+b)%k, how do you ensure no data race in this example? The result depends on the coprimality between a and k. You will still need to check this at runtime and creating affine_mod_view for each access patterns like this would be overkill.

Reply on news.ycombinator.com