Hacker News Reader

> As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature

I see these comments and it feels so foreign to my experience. The borrow checker was second nature to me because of my C++ experience. These were things I already had to juggle mentally. On rare occasions, it complained about something that I could prove was valid but I understood why it couldn't tell. Usually, when I hit it, it is because I forgot a case and am grateful for it. I know of at least one optimization I've made that I would never have bothered with without the borrow checker. It would have been too much bother for me to reason about everything. Even if I did, it would have been even worse to maintain.

I think it depends on your level of C++ experience. Very experienced and effective C++ developers often will have internalized a lot of the rules of the borrow checker, possibly without consciously realising it. Less experienced developers will not have run into the problems caused by not following these rules because a lot of the time you can get away with it, and/or they haven't associated these habits with the bugs they tend to cause. It's a fairly common theme for people who have learnt rust to report that it has made them a better C++ developer.

Personally, I had the same experience as you did, except the borrow checker also helped me unlearn a few bad habits and gave me a deeper understanding of references. Now it is second nature, and I rarely every fight the borrow checker. I think part of it is planning ahead.

Were you trying to write GUI code?

Because of my experience it was also plain sailing, while doing the tutorials and exercises from the books I bought.

Then I tried to make a GUI application in Gtk-rs and had lots of fun with event handler callbacks, which are the main reason why Relm was created.

No, I have not written a GUI in Rust yet. I've been doing libraries and CLIs so far.

But I find the standard approaches to GUI broken: inheritance and shared mutable state. i think Rust does a service by highlighting the brittleness of this pattern via syntax / libraries.

I've not dealt with elm-like GUIs. Probably my natural inclination would be to use an actor framework. And to be clear, I am speaking from having written non-trivial GUIs with both GTK and Qt (I miss the Maemo days).

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

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.

> Also, Rust is an open source ecosystem, and people using it should feel compelled to consider writing the missing pieces they need for the benifit of the community. It’s also odd to say that Rust doesn’t have what you need, it sounds like there are C libraries that already do what you want, and Rust can wrap C.

This sounds like a great idea, but not everyone has the time and resources to port libraries from one language to another. It should be trivial to wrap C libraries, but errors do show up, and a once one day task now takes a week to iron out. If you have 4 or 5 libraries that are missing, you've now lost a month of development work that could have been spent adding new features.

Additionally, not everyone wants to maintain open source projects. There's a huge amount of responsibility that comes with being a maintainer, and the OSS community isn't always a friendly, fun place. Rachel has some great examples in her blog [1].

[1]: https://rachelbythebay.com/w/2018/10/09/moat/

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

This is so misleading. Sure you still have to think about borrowing in C++ but in C++ you only have to convince yourself that you got it right. You don't have to convince a dumb child that barely understands variable scopes.

The benefit is of course that the dumb child is 100% reliable so if you can convince him then you are 100% sure you got it right...

But please can we stop pretending that it isn't a massive pain in the arse to convince the borrow checker that your code is ok.

Also as someone else pointed out, if you are only writing single threaded code the mutable borrowing rules are needlessly restrictive.

I like Rust but it really irks me when people pretend it is as easy as C++. It isn't. It is much harder - it's just that when you're done you have (probably) a better result.

> I like Rust but it really irks me when people pretend it is as easy as C++. It isn't. It is much harder

No it's not.

"hard" is not single dimensional.

"hard" to write your first hello world? No, both are easy.

"harder" to write your first moderately-sized program that basically works? Yes, for almost everyone. You'll fight the borrow checker. The learning curve is real.

"harder" to write your first large/medium, correct program? Definitely not. The safety will save you, here. It's not just memory. It's no nulls, it's no exceptions, pattern matching exhaustion enforcement, baton-passing session type patterns, race-freedom, and so on. The "it compiles, it works" dynamic is akin to OCaml/SML, if you've used those at all. Except it's even better because you get prompt resource finalization.

"harder" to write your nth program after ~6 months of usage? Not by a long shot. Rust is actually an incredibly expressive language. Once you learn to shape code the way the language expects, you'd be shocked at how productive you are. It's in the same ballpark as go, perhaps a little better if you're doing something nontrivial due to the power of generic libraries.

I spend almost no time "fighting" the borrow checker, as do most ramped-up Rust programmers. It's pretty much all win at this point. It's a different category of language than C(++). It actually gets a little exhausting hearing people talk about how hard the borrow checker when folks have barely used the language.

These days, the only time I'll use a GC is if I'm writing something _very_ fast and short in Python. An experiment, a prototype, or a tool. A short REPL session. I really do not miss GCs otherwise.

But yes, compile times are somewhat slow. If you go template crazy in C++, you'll be in the same ballpark. But the "equivalent" C codebase will smoke it.