> It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work.

This could almost be the subtitle for "Functional Languages: Those Things Your Manager Won't Allow You To Use Yet"

I think that a day will come when everyone will realize, and we'll have the tools to do, "functional" all the way to the metal. I like to quote John Carmack from http://www.gamasutra.com/view/news/169296/Indepth_Functional...,

"A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible... No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."

I think this paradigm applies at the OS and filesystem levels as well (ideally). The better control you (and your code) have over the states of everything in your system, the more deterministic your system behaves, the fewer unexpected bugs you have to chase down, the better you can reason about the computing you're doing and the programming you're responsible for making work.

I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution.