Why Rust ditched pure functions
thread.gmane.org
thread.gmane.org
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).
- 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.
There are certainly ways to have purity without laziness, but it's not straightforward for Rust to adopt the Haskell model, I think.
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.
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.
That aside, Idris looks very promising for verified application development.
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
When you come to think about it, a separation of strict types and lazy types makes perfect sense. For example, I want to foldl on lists (strict) but foldr on streams (lazy). I do not want to accidentally use the wrong operation on the wrong type. it is tiny details like these which make a type system helpful for guaranteeing correctness and improving performance.
So, if strictness and laziness are both useful and distinct from one another, why not provide both as core language constructs? Why do languages always have to be biased towards one of them?
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.
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.
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.
This is why D has enforced purity (via an attribute) rather than inferred purity.
> Pure means your function does not use or change mutable
> global state except what is available from the
> arguments. If in addition the arguments are not
> mutable, a function is called “strongly pure”.
> Nothrow means your function will never throw an
> exception.
> Safe means your function cannot break the type system
> via unsafe casts or inline assembly.
Coming from an OOP background, I am used to bundling functionality into objects that loosely represent real-world people, places or things, but I'm starting to experiment with using these more abstract "pure" methods.
For example, I'm working on a GPS-based JavaScript game that uses a "check-in" system to encourage users to travel spontaneously. Initially, I designed a tightly encapsulated "Check-in" object responsible for fetching & interpreting users' locations.
Inspired by reading about functional programming on HN and elsewhere, I'm trying to break up some of the general geo-processing logic such as looping, array filtering, map/reduce, etc., into general functions with predicable results that can be used throughout my application.
It's definitely a different way of thinking that I'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.