I think the context of this post being 6 years old is important. While I don't buy the argument that functional programming languages are more complex, I think

I think the context of this post being 6 years old is important. While I don't buy the argument that functional programming languages are more complex, I think there's certainly been a long-standing problem of good pedagogy in the functional programming community. I'll also add that I don't think the languages themselves have been where pedagogy is lacking per se as much as much as with regard to teaching functional design. Ask yourself how many tutorials you've seen about pattern matching versus the number of monad tutorials you've seen. I think this has gotten somewhat better recently and there are better resources available for understanding some of these functional design patterns (more literature and likewise better guidance about how to write tutorials). I also think lately there's been a couple of languages I'll call "bridge languages" to purely functional programming languages (particularly scala, rust, and swift) that have been particularly good at weening object-oriented programmers into functional programming through a translation of functional concepts into OO or otherwise imperative programming. Arguably these languages are some of the most complex, but surprisingly I've found them to be pretty good for learning functional programming (I'm definitely biased as someone who came from scala to haskell, though). There's still a pedagogy gap though, and I would say there's not a lot of accessible literature on things like lenses, monad transformers, free monads, etc. that ought to exist to make purely functional code understood by a wider audience. In fact I'd argue that design patterns in purely functional programming are still not totally settled. There's still a good amount of discussion about the best way to achieve things like composition of effects, testable code, module design, etc. Haskell in particular is still a test bed for ideas about how to achieve some of these things, though languages with a more lax view on explicit effects tend to be more settled on these things. In any case, none of this should scare you away from functional programming. If you're concerned that the benefits seem unclear, I'd advise you to take a look at Simon Marlow's _excellent_ Parallel and Concurrent Programming in Haskell [1] for a look at what purely functional programming brings to the table WRT concurrency. Yes, you can do IPC in any language, but this only one model of concurrent programming (and one that does not eliminate the potential for deadlocks). Purely functional programming offers many tools in the concurrent programmers toolbox such as data parallelism, software transactional memory, message/channel concurrency, etc. that are all hard to achieve without sharp corners in imperative languages. [1]: http://chimera.labs.oreilly.com/books/1230000000929 http://chimera.labs.oreilly.com/books/1230000000929