The joy of functional concurrent programming

Pleanty of people have said that concurrency and functional programming are becomming essential to developing modern systems. Some have even gone so far as to say that if you don't adapt you will become a maintenance programmer in a few years. With the increasing need for concurrency to provide speed and handeling of huge amounts of data, I beleive it to be true. I do however beleive there will still be pleanty of smaller applications, so I am not predicting doomesday for anyone quite yet.

What I do find interesting is that this evolution is moving so relatively slowly. We have talked about this for at least a decate now. Still every single project I have ever worked on uses platforms and tools where immutability, functional constructs and even types that handle concurrency well are not the default. Why is that? 

Lots of speakers have talked at length about how simple concurrency actually is, if we simply take away the bad habbits that drown us in complexity. Mutable types need locking when used in concurrent scenarios, imperative programming adds complexity and builds on constructs that use mutable types, and I don't see a lot of reasons why we are defaulting to implementations like List<T> in C# that breaks in certain scenarios.

Oddly this is not at all scary as some seem to feel it is. Once you get over the "WHO MOVED MY CHEESE" stage, it really is simpler than what we are doing now, and building faster systems that are easier to understand is deeply satisfying.