[jacquesgt]

But see also:

> In particular, I’m still conflicted about whether all those type system extensions were warranted. Certainly immutability helped with things far beyond safe concurrency. And so did the side-effect annotations, as they commonly helped to root out bugs caused by unintended side-effects. The future for our industry is a massively distributed one, however, where you want simple individual components composed into a larger fabric. In this world, individual nodes are less “precious”, and arguably the correctness of the overall orchestration will become far more important. I do think this points to a more Go-like approach, with a focus on the RPC mechanisms connecting disparate pieces.

[kibwen]

I don't think this is incompatible with Rust's goal, which is to bring safety to the sort of low-level domain where C is currently dominant and systems can't afford to be structured as isolated nodes communicating only via RPC. In contrast, Midori was aimed at a higher-level general-purpose domain, like Go (and Erlang, too, which is even better than Go at the "cluster of nodes" approach, yet doesn't have a type system at all).

[k__]

Could it be, that many desicions for Rust have been made to make it more appealing to C devs?

Like, opting out of purity annotations or forced immutability?

I'm not saying these desicions are good or bad, I don't know much about system programming. But I often ask myself what the main motivators for a language are.

[tupshin]

FWIW,after spending a couple of years with rust as my primary programming language, I'm convinced that they made the right decision wrt mutability (immutable by default, but mutability availale when needed), as rust's lifetime system eliminates nearly all the remaining pain points around mutability (data races).

On the other hand, I think it is very important that some notion of purity be incorporated, even if only as an opt-in.

[k__]

> spending a couple of years with rust as my primary programming language

Oh, how did you achieve that? :)

[Groxx]

Probably not with too much difficulty. 1.0's alpha was nearly 2 years ago. The github repo goes back to mid 2010: https://github.com/rust-lang/rust/graphs/contributors

[steveklabnik]

See also https://github.com/graydon/rust-prehistory

[jackmott]

Forced immutability has enormous performance downsides in some cases. Rust can't have that.

[masklinn]

That's really interesting in that the Rust developers ended up falling on the side of "no". Immutability is contextual (depending on the type of reference you hold) and purity annotations ended up being completely removed.

[continuational]

I'm wondering why the `mut` keyword is named the way it is when you can still have "interior" mutability regardless of whether you have a `mut` reference or not.

Shouldn't it be called `unique` instead?

[steveklabnik]

What my sibling said, but also, this almost happened. It's called "the mutapocalpyse". See here: http://smallcultfollowing.com/babysteps/blog/2014/05/13/focu...

In the end, we decided that these are two equivalent perspectives, and decided to stick with the more traditional mutable/immutable distinction.

[FreeFull]

The mut keyword on variable bindings doesn't influence uniqueness at all, though. You're probably thinking about the `&mut` references vs the `&` references.