While Erlang itself is pure, in practice it seems like a lot of practical mutation and state issues are tucked in other processes. Nothing wrong with it and it sidesteps the purity issues that the Haskell example in the article presents.
The supposed problems in the Haskell example presented in the article have nothing to do with purity. Logging is by definition an effect. Haskell supports effects just fine. (I'd personally say better than any other language I know.)
I think it was Erik Meijer (or was it the actor systems guy?) or so, who said in one of his videos about FP or programming languages, that as soon as you have another process, that process acts like a store for state, which can be mutated etc.. So it seems natural, that in a language like Erlang some mutable things are outsourced into separate processes. Whether knowingly or not.
Is this no true scottish languaging on what constitutes fp? More to the point with the original article, erlang is assuredly not OOP in the modern sense (no matter how much joe Armstrong tried to rope java shops in by saying that actors are actually the true objects)
Also:
> Erlang itself is pure
Very not true. erlang is extremely impure fp and that's a big part of what makes it what it is.
Right, and that's my point about practical languages that promotes a functional style being a better choice. The requirement for purity in Haskell (due to lazy evaluation) makes anything but purity a problem, it seems sometimes that just because things are possible to do purely it's the only way to do things according to adherents.
In the mainstream sense of what people understand OOP to be, yes, but actually Joe had Alan Kay on his side for the claim, that Erlang might be the most OO language. It is even recorded on video about a dialog they had on stage. What speaks for it is the focus on passing messages to other actors, which act as if they are separate little computers. All very similar to Kay's descriptions of OOP.