The research paper linked to by the author of this article also shuns mutable state, but takes a different approach to how you might do it in Pure FP languages (e.g, with monads).
They basically describe a modified C# language, with global state (static variables) eliminated - any global state is immutable only. Naturally, anything marked immutable cannot access anything marked writable, so unless you want to put writable permissions on everything (turning it back into standard OOP), you're going to need to design programs around immutable data by default. Also, anything marked writable in the new language can only be written to by one thread at a time anyway, since the writable references are unique.
The result is a significantly different style to the traditional imperative OOP people are used to, so it's not like you can lift an existing program into this paradigm without problems.
If the author thinks that FP won't become mainstream, what makes him think that this will?
They basically describe a modified C# language, with global state (static variables) eliminated - any global state is immutable only. Naturally, anything marked immutable cannot access anything marked writable, so unless you want to put writable permissions on everything (turning it back into standard OOP), you're going to need to design programs around immutable data by default. Also, anything marked writable in the new language can only be written to by one thread at a time anyway, since the writable references are unique.
The result is a significantly different style to the traditional imperative OOP people are used to, so it's not like you can lift an existing program into this paradigm without problems.
If the author thinks that FP won't become mainstream, what makes him think that this will?