Why Rust ditched pure functions

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++.<p>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 <i>highly</i> 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 &quot;pure&quot; and mark them as `readonly` or `readnone` (not sure what the limitations to this approach are, though).<p>So don&#x27;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&#x27;s own explanation should suffice regarding their enormous added complexity in a language that is not Haskell).

Since this author is reasoning through proposed purity in Rust by comparing it with purity in Haskell...<p>- I personally have never felt constrained by Haskell&#x27;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&#x2F;or after any calls to pure functions.<p>- Managing monad stacks in Haskell isn&#x27;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&#x27;t, but because people make it out to be so hard.<p>- 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&#x27; logical equivalents no matter what language you wanted to implement this example in.

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.<p><a href="http://qznc.github.io/d-tut/idiomatic.html#purity" rel="nofollow">http:&#x2F;&#x2F;qznc.github.io&#x2F;d-tut&#x2F;idiomatic.html#purity</a>

The corresponding reddit thread at &#x2F;r&#x2F;programming: <a href="http://www.reddit.com/r/programming/comments/1t8y6g/why_rust_ditched_pure_functions/" rel="nofollow">http:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;1t8y6g&#x2F;why_rust...</a>

This discussion is very interesting to me because I am just starting to learn about pure functions and functional programming in general.<p>Coming from an OOP background, I am used to bundling functionality into objects that loosely represent real-world people, places or things, but I&#x27;m starting to experiment with using these more abstract &quot;pure&quot; methods.<p>For example, I&#x27;m working on a GPS-based JavaScript game that uses a &quot;check-in&quot; system to encourage users to travel spontaneously. Initially, I designed a tightly encapsulated &quot;Check-in&quot; object responsible for fetching &amp; interpreting users&#x27; locations.<p>Inspired by reading about functional programming on HN and elsewhere, I&#x27;m trying to break up some of the general geo-processing logic such as looping, array filtering, map&#x2F;reduce, etc., into general functions with predicable results that can be used throughout my application.<p>It&#x27;s definitely a different way of thinking that I&#x27;m not entirely comfortable with yet, but I can see how it allows for faster, more efficient code. I have been able to replace 50-line code blacks with 10-line blocks that are more efficient and - believe it or not - legible.

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