Interestingly, D has this and everybody considers it great. The community consensus is that pure should have been the default, but it is not changed for backwards compatibility.

http://qznc.github.io/d-tut/idiomatic.html#purity

You would only use D if you considered it great.

There are other reasons to use D, and indeed, most of the community came from languages without pure functions and did not want the feature before trying it.

However, it's one of those things where once you use it for a while, you begin to really appreciate it. Better optimization, autovectorization and cpu -> gpu code conversion are all unimportant reasons for checked purity in the type system. The important reason is that by constraining what functions do, it makes reasoning about complex systems easier.

Generally, after you've worked in maintenance on one large project that designed everything to be pure unless there's a very compelling reason not to, you start to really miss the feature when you go back to projects in languages without it.

Agreed there. But, on the other hand, D misses out on statically checked resource management, and IMO that is more important than purity in the niche Rust and D are targeted at (systems development). Of course, nothing prevents a language from having both. :-)

Since this author is reasoning through proposed purity in Rust by comparing it with purity in Haskell...

- I personally have never felt constrained by Haskell's purity. During development I use `Debug.Trace` to do any debug printing I need to do in pure functions, and I design a program so that in production code I can do appropriate logging before and/or after any calls to pure functions.

- Managing monad stacks in Haskell isn't that tricky. This is the kind of thing that people get scared away from not because they actually tried to learn it and couldn't, but because people make it out to be so hard.

- The Haskell STM example the author links to is actually really simple, especially in terms of monad stacks. It seems dense at first glance only because of the `forkIO`, `timesDo`, and `milliSleep` calls, but you would need these functions' logical equivalents no matter what language you wanted to implement this example in.

I am a Haskell outsider, but I've heard SPJ say several times that laziness is what enabled/forced Haskell to stay pure. My understanding is that even advanced Haskell programmers struggle with predicting the runtime cost in space and time of the laziness that bought purity. That unpredictability is highly undesirable in a systems language.

There are certainly ways to have purity without laziness, but it's not straightforward for Rust to adopt the Haskell model, I think.

I think catnaroek has this right.

Neither that nor my original comment is meant to suggest that it would be straightforward for Rust to borrow from Haskell. Just that the post's comments on Haskell seemed to reflect misconceptions.

OTOH, I am not really sure I would want STM in a systems language. It is a little bit too magical, taking into account all the possible retries of a transaction. Perhaps something based on the pi calculus would be a better fit.

I think the magic factor is a key point. Haskell is by design a very high-level language. Things like STM and other "magic monads" allow a lot of stuff to happen under the hood, with guarantees of correctness because of other constraints on the language, but not necessarily a great degree of control of what exactly is happening. Rust, on the other hand, is meant for low-level programming and as such tends to be very explicit about what it's doing at every step. I think Rust and Haskell happen to share some similarities but ultimately they're just not designed for the same purpose. Nothing wrong with learning both :)

Side-note, Idris is a Haskell-inspired pure language which is strict by default. It's designed from the outset to be useful for systems programming, and also has some cool theoretical ideas like dependent types. It might be worth looking into for those who wish Rust was more like Haskell, or vice-versa.

I'm a Haskell newbie, and when I test a program and it shows a laziness-related space leak, I just put strictness annotations on the parameters I suspect of generating large unevaluated thunks. This has always made the issue go away so far.

But, would you not agree that it would be really nice to have separate strict vs. lazy types? It would bloat the syntax a little bit (e.g., Coq needs separate Inductive vs. CoInductive, Fixpoint vs. CoFixpoint keywords) but the benefits in terms of not having to find space leaks via debugging and profiling would be enormous.

There are several libraries that do distinguish between strict and lazy types. containers [1], for example, separates strict Maps and IntMaps.

That said, introducing new syntax to annotate strictness is far more troublesome than separating strict types from lazy types at the module level, where switching between the two is a comment away:

       import qualified Data.Map        as M
    -- import qualified Data.Map.Strict as M

Introducing syntax would make switching between the two far more painful.

[1]: https://hackage.haskell.org/package/containers

I am confused as to what this has to do with the author's point. He isn't saying purity is hard to use, he is saying the features of Rust make a truly pure function hard to define.

The author seemed to imply that pure if easily used would be a great feature, he just doesn't think that the language that Rust defines is a good match due to the ease of tainting a function.

I agree that that's his point. I just wanted to put in a plug for Haskell being appropriate for many, many application development use cases, because there's a misconception that it's only useful in mathy or academic scenarios.

Again, this guy didn't argue as much; he basically just said it's reasonable for someone developing systems code, code with I/O on every line or something, to conclude she isn't going to be able to reap the benefits of writing pure code in Haskell.

But I think a lot of folks read anything of the form "Haskell isn't appropriate for use case X" as "Haskell's generally impractical". So I wanted to share a different perspective.

I just want to reiterate something that I say in a child comment in this thread: thanks to its thoughtful design, many of the advantages of purity are less appreciable in Rust than they would be in, say, C++.

In Rust, everything is immutable unless you opt-in to mutability. Looking at a function signature will tell you which of its arguments can possibly be mutated. Global mutable state is highly discouraged, by requiring you to wrap code that accesses global mutable state in a dreaded `unsafe {}` block. As for optimization capabilities, LLVM itself can (AFAIK) infer when functions are "pure" and mark them as `readonly` or `readnone` (not sure what the limitations to this approach are, though).

So don't make the mistake of thinking that Rust is a free-for-all due to the long-ago removal of its `pure` keyword. Many (dare I say a majority?) of the nice features of purity are merely provided by different mechanisms (for those use cases that Rust does not satisfy, Graydon's own explanation should suffice regarding their enormous added complexity in a language that is not Haskell).

nice to see a thread I started months ago on the HN homepage

Has anything changed in your thinking since posting the original mail?