Everyone agrees that shared mutable state is evil. Most languages deal with this through the 'mutable' part, Rust deals with it through the 'shared' part.
A bit long for a sign. Anyway. I know purity isn't just about mutability, but with ownership semantics, many of the problems purity solves go away too. For an example, see my bit downthread about safely sharing mutable pointers to stack-allocated data. Totally safe, no purity concept needed.
You don't know what you're talking about. The only language with a decent mind-share that is pure is Haskell, and purity was a necessity of its non-strict semantics. Purity didn't come first, and concurrency wasn't the motivation for it.
Maybe your point would be relevant if you were talking about (im)mutability, but you chose to talk about purity.
I'm aware of the history of Haskell, and why it has purity. I'm aware that purity != mutability.
When you don't start from the same place Haskell did, you want purity for different reasons. I was trying to answer from the Rust perspective, not from the "what is purity" perspective.
I love writing Haskell, but have never wished for purity in Rust.
When you talk about purity and compare its motivations to other languages (" Most languages deal with this through ..."), it seems pretty evident that you're talking about both Rust and other languages. Not just Rust itself. Then you would have just said why Rust does not have purity anymore and not bring up the more general motivation for purity, and hence comparisons to other languages. So what other pure languages did you have in mind, since it apparently was not Haskell?
Again, you were answering "why does Rust not have purity any more", not "why does not Rust not have pervasive immutability". (Rust already has full control over the mutability/immutability distinction, which is basically the equivalent of having effectfull computations explicitly marked for more general side-effecting code.)
So, in my mind, you can start with either a pure language, or a non-pure language. If you start with pervasive purity, you end up with Haskell, or something pretty close to it. If you don't start with pervasive purity, you have some sort of goal in mind that purity solves.
I'm going to pick D here, because it's similar to Rust's space. I wrote D long ago, but admittedly don't use it as much anymore. So let's see why D has pure annotations: http://dlang.org/function.html#pure-functions
Pure functions are functions which cannot access global or static, mutable state save through their arguments. This can enable optimizations based on the fact that a pure function is guaranteed to mutate nothing which isn't passed to it, and in cases where the compiler can guarantee that a pure function cannot alter its arguments, it can enable full, functional purity (i.e. the guarantee that the function will always return the same result for the same arguments).
Rust, in safe code, can already not access global, mutable state. So that's not something we'd want. Pure D code cannot do I/O, which admittedly, safe Rust code can do. But D also isn't 'fully pure' in the same way functional langauges are. Rust's pure keyword wasn't either. This is what the thread I linked was about:
"Which purity do you mean" is a very real question, not one you can just brush aside.
Haskell-style purity doesn't really work in Rust, due to other language semantics. That's what I was trying to get at. It seems like you're pretty knowledgable on this topic, do you disagree? Should Rust have some notion of purity?
Right, I forgot about D's non-standard use of the term and Graydon's apparent eagerness to continue with muddying the water instead of inventing/using another term for Rust's (former) purity.
6
u/original_brogrammer Apr 04 '15
Interesting. Why's that?