Re:Reflecting on Haskell in 2017
by jerf on Monday December 04, 2017 @11:19AM
(#15844973)
It would be better to rephrase the original point as "Some guarantees need to be embedded in the language itself, or otherwise you can't depend on them." Having the language itself guarantee immutability means that you can depend on it, because you know that no library will ever be written that expects you to pass things to it to be randomly mutated.
Rust has a different set of guarantees about mutability, but again, you want them embedded in the language so that you can depend on them, which you can. Even though you can escape to "unsafe" in either language, the rest of the affordances of the language prevent library authors from going too crazy violating guarantees.
That is, the important point isn't about "immutability", but about the guarantee.
Within the Haskell community, the idea that something like Rust may be closer to what we're seeking is perhaps controversial, but certainly not beyond the pale. And some of that controversy would be that Rust may not go far enough with things like linear types rather than the idea that immutability is the end goal. Personally, I think immutability was a sensible thing to try out in the 1990s, but we have legitimately made progress since then and continue to make progress.
(If you want to see a language where the 1990s beliefs about immutability really hurt it, check out Erlang. What Erlang ought to have had, in my 2017 opinion, is processes that have their own conventional mutable data storage, but with messages between processes incapable of carrying pointers/references. This would have accomplished their goal of total isolation and all communication being forced to go through copying, but without having the barrier to adoption raised by trying to teach people how to program in immutable languages, to what I found to be no great effect. Haskell does at least make some hay out of its immutability, in Erlang it is mostly just getting in the way. But back when it was written, the ideas were not as well teased apart as they are now. I don't mean this as criticism of the Erlang authors, because I think they did quite well, but this still would have improved the language.)
Rust has a different set of guarantees about mutability, but again, you want them embedded in the language so that you can depend on them, which you can. Even though you can escape to "unsafe" in either language, the rest of the affordances of the language prevent library authors from going too crazy violating guarantees.
That is, the important point isn't about "immutability", but about the guarantee.
Within the Haskell community, the idea that something like Rust may be closer to what we're seeking is perhaps controversial, but certainly not beyond the pale. And some of that controversy would be that Rust may not go far enough with things like linear types rather than the idea that immutability is the end goal. Personally, I think immutability was a sensible thing to try out in the 1990s, but we have legitimately made progress since then and continue to make progress.
(If you want to see a language where the 1990s beliefs about immutability really hurt it, check out Erlang. What Erlang ought to have had, in my 2017 opinion, is processes that have their own conventional mutable data storage, but with messages between processes incapable of carrying pointers/references. This would have accomplished their goal of total isolation and all communication being forced to go through copying, but without having the barrier to adoption raised by trying to teach people how to program in immutable languages, to what I found to be no great effect. Haskell does at least make some hay out of its immutability, in Erlang it is mostly just getting in the way. But back when it was written, the ideas were not as well teased apart as they are now. I don't mean this as criticism of the Erlang authors, because I think they did quite well, but this still would have improved the language.)