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

&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?