[masklinn]

> as long as the 'mutable' keyword was something shorter :-

That's one thing I really like, actually: use of mutable structures should be avoided, making mutable structures harder to use (because they require a pretty long extra keyword) is a good way to drive developers towards immutable equivalents. See it as shifting incentives.

[marshray]

OK, but the goal isn't to be Haskell here, or even ML. Those languages have all kinds of support for making immutable-everywhere a feasible goal (and the vast majority of developers still don't use them).

If you want the language to be actually liked by people who develop large systems, it must be designed with its users in mind. 'Nanny' languages tend not to be very popular.

In C++ "reinterpret_cast" is a good example of something that is long and ugly for a reason. But it's also be very rare, probably an order of magnitude or two more rare than mutable in Rust (just a guess).

[masklinn]

> OK, but the goal isn't to be Haskell here, or even ML.

So what?

> If you want the language to be actually liked by people who develop large systems, it must be designed with its users in mind.

Which does not prevent the language from driving users towards a goal. One of Rust's goal is emphasizing immutable structures, that's #8 on the front page of its website:

> immutable by default, mutability is the special case

mutability is the special case and a special case Rust tries to make people avoid.

> In C++ "reinterpret_cast" is a good example of something that is long and ugly for a reason. But it's also be very rare

And so ought mutable structures be in Rust.