Pureness has the property that you know for sure that if you call the function the first time, the second time or the nth time, the answer will be the same. This has two advantages:
- Languages can use this to do memoization, (remembering the answer of the first invocation so a function needs never be called more than once) which makes them fast: efficiency.
- Programmers can more easily reason about their code (as there are no ‘hidden’ things when there are no side-effects). This makes it easier to understand why something does (or doesn’t) work: maintainability
I’d say that immutability increases both efficiency and maintainability in its own way. You can have a system with immutability but without pureness, but not the other way around (as changing a property of one of the inputs can be considered a side-effect).
So, to answer 1): Immutability definitely helps to make systems easier to reason about, regardless of purity.
To answer 2): For instance pipelines are constructs that ensure that functions are built very immutably, as you cannot bind to variables in the middle of a pipeline, for instance. So this is something that makes Elixir maybe less side-effect heavy.
I like the impureness of Elixir/Erlang as it makes it a lot easier to write concise code. I have experience in Haskell before, but I would not use it for anything outside of academic projects involving heavy calculations; Doing anything like user-interaction depends too much on a state. Pushing this state to the outside of your application means that whenever this UX-part changes, the application has to be overhauled in a large way. The boilerplate in systems like yesod is very high because of the split between the pure and impure parts of the application.
Of course, message-passing in a pure world is something that can not really happen. The principle of pureness kind of conflicts with the idea of concurrent applications.
One drawback of Erlang’s current pureness-implementation is that only a very small amount of functions (that are ‘known to be pure’) is allowed to be used in guard clauses. This severely limits the amount of pattern-matching that can be done, when compared to pure languages. I would love for this to change; If Erlang would have a proper short-circuiting || and &&, for instance, we could build a whole lot more guard-safe macro functions than are available now.
