Hacker News Reader

Comment by tptacek | Hacker News Reader

This is a pretty great explanation that links to a rabbit hole of further intuition tuneups around &mut. I come to Rust's way of looking at the world via C/C++, and after following the links here it turned out I had a bunch of fucky intuitions about what Rust is trying to express. They really should have renamed `mut`!

Having said that: I'm proof that you can get a bunch of stuff done in Rust without having a perfect mental model of this stuff. :)

View on HN

It's common to hear people refer to &T and &mut T not as "mutable" or "immutable" but "shared" versus "unique". What probably muddles this is that the `mut` keyword _also_ is used for declaring things mutable or immutable, just at the binding level rather than the type level. These are related due to the fact that you can't take a `&mut` reference to a binding that isn't declared as `mut`, which probably also muddles the water a bit.

&mut is kind of gross syntactically anyways; another thing that would have clarified this would have been to rename & to &shared, which has symmetry.

Nah, I like having immutable syntax be shorter. It makes idiomatic code shorter than code that does a lot of mutating

Agreed! I also like that declaring a mutable binding is extra code beyond a regular binding rather than something the same (or shorter). At least for me, making things immutable by default and then only relaxing it when necessary leads to code that tends to be less buggy, and I suspect this might be true for others as well.

Rust is already an ugly language.

Having &shared plastered all over your code base would be ... suboptimal.

Not everything in a language needs to be 100% self descriptive.

I think the designers arrived at a good tradeoff.

That's kind of point, tho... I feels gross because it should?

There's one other oddity, where `let x: &mut T` allows mutating the target, while `let x: Box<T>` or `T` doesn't.

  fn box_immut(x: Box<i32>) {
      // illegal
      *x += 1;
  }
  
  fn ref_immut(x: &mut i32) {
      // legal
      *x += 1;
  }

IIRC under the current current Rust-to-LLVM compilation rules, &mut T is noalias (because it's exclusive), and &T is noalias or readonly or something (because all other &T are immutable) unless T contains an UnsafeCell. It actually took many years to get &mut T to be noalias without exposing LLVM bugs resulting in miscompiled Rust (which went undiscovered because Rust is the first LLVM language to use noalias so heavily).

And noalias and pointer aliasing is a huge mess, with crates like owning_ref and Tokio's intrusive linked lists and Pin<Box<T>> being unsound under the proposed Stacked Borrows rules. And I just found a LLVM codegen soundness issue: https://github.com/rust-lang/rust/issues/63787.

This was my biggest misconception when learning Rust. I was thinking "&mut" can modify data, so "&" cannot. Wrong.

The "mut" keyword is not the opposite of "const" from C++. It's declaring that you have exclusive (unique) ownership at this moment.

to be pedantic &mut is still a borrow not ownership, as another simplification the difference is that &mut can modify a value but must keep the borrowed value in a valid state, while full ownership can destroy a value

One of the best post-beginner / intermediate learning experiences wrt. Rust is to try to model the Borrow Checker behavior with Rust. Just write small (>10 LoC) programs within safe subset of Rust:

1. Rejected unsafe programs (and the why)

2. Rejected safe programs (and the why)

.. and try to convince yourself that you understand the logic behind the two.

https://whileydave.com/2021/12/06/modelling-borrow-checking-...

https://github.com/rust-lang/unsafe-code-guidelines/blob/mas...

> Having said that: I'm proof that you can get a bunch of stuff done in Rust without having a perfect mental model of this stuff. :)

That's one of the best features, IMO. If you tried approaching C or even C++ with that mentality, you're going to hit brick walls, hidden errors and antipatterns before you know it. If you try it in Rust, you're going to get a couple linting errors and and a non-functional build. Not a perfect catch-all for every error you can cause, but like you suggested, it's plenty to get stuff done with.

> fucky intuitions that's got to be a typo

I'm not so much a typo kind of commenter.

Reply on news.ycombinator.com