> I wonder if this is why you tend not to see functional programming languages more broadly used...? The overarching problem is that functional programming tra

> I wonder if this is why you tend not to see functional programming languages more broadly used...? The overarching problem is that functional programming trades extra thought now for extra benefit later. Inexperienced programmers hate functional programming because they like "magic". They are having a tough enough time just getting the task at hand finished and the more stuff done for them without thinking, the better. Inexperienced programmers don't want to think about multiple threads. They don't want to think about the event loop or sockets. They don't want to think about the state of the protocol and why it shouldn't update multiple steps. etc. The only way for that kind of magic to happen is to have a bunch of implicit state that sits invisibly in the background. It's either global or part of a single mega-struct that might as well be global. However, if an inexperienced programmer sticks around long enough they eventually run into a Heisenbug that is difficult to replicate. In order to run down the bug, they start having to isolate everything. Suddenly, the words of the old greybreard start coming back: "Immutable is good" "Time needs to be an explicit part of your state" and "bytes in, bytes out--putting the bytes on the wire is a different function" and ... At that moment, they become an acolyte of functional programming and now qualify as an experienced programmer.