I take that as a request to expand on that.
Well, the whole idea that functional programming is something people in ivory towers and doesn’t have much use in the so-called real world shows an incredible amount of ignorance from someone who tells us how much he knows about programming languages. I gather this knowledge is limited to imperative languages.
Multi-threaded applications is just one of the things that make functional programming a good idea but it’s huge. I’m an embedded SW engineer by day (and won’t tell you what I do by night, na na na na na) and applications have been going more and more this way during my 20 years of writing professional software (I actually started by writing business software for about five years so I know that domain as well). There are some fundamental complexities writing multi-threaded programs that are extremely hard to solve and tend to create bugs that are among the hardest types of bugs a programmer can encounter (race conditions, deadlocks, etc). And many of those bugs are caused by our attempt to fix other bugs (global data being changed at the wrong time). If you look at this from the outside it’s completely backwards. Functional programming allows us to write code that gets rid of the first problem so no need to create the extra code to fix that!
And multi-threading is only getting bigger. There are just too many applications where it fits, and even more if you embrace it rather than try to avoid because it’s too hard. Including business apps.
Another big plus is functional code tends to be much shorter. This is a big bonus especially during application maintenance phase (which is pretty much always way longer than original implementation phase).
The way functional code is written also tends in my experience cause less bugs. How many for() loops have you seen with an off-by-one-error? Or code that uses a temp variable that someone goes and changes a bit at some point during application lifecycle without realising it’s used later in the code?
Furthermore, functional code is being used enough to make the notion it’s not usable sound ridiculous. Imperative languages got popular because they are easier to optimize to hardware as their logic is close to how processors work. This was important back in the 60s and 70s but this gets less and less important as our computers get more powerful. So we can actually start to use the best tools to solve our problems without such constraints as processing power. And funnily enough, functional programming has been gaining a lot more traction as a consequence. It’s still small compared to imperative programming but then again, how quickly do we adopt completely new programming languages overall? And functional programming requires a different way of thinking about programming so it’s doubly hard. But it’s creeping ahead. Clojure has a nice community and there are many companies writing applications with it. Erlang has been used by Ericsson since the 80s successfully and it’s hands down better at what it does than anything else (building fault-tolerant systems). Other companies have adopted it as well. Financial companies for some reason also like functional languages (so there’s your ultimate business applications), especially in-house developers. It won’t take over overnight but if you still have two or three decades of professional life and this is your day job you will be a bit of dinosaur at some point if you don’t know functional programming. Just like those guys who only know COBOL.
I also have to disagree with the notion that “customer is always right”. When Java was being introduced lack of multiple inheritance was seen as a huge thing. I confess of being one so I disliked the language from the off and haven’t used it much even though I actually completely agree with the language developers now. The problem with that kind of logic is that we wouldn’t really ever get anything new in any walk of life if everyone was just doing what they thought the customer wants. Did Apple become such a big company by following that idea?
Kotlin may or may not become successful. Only time will tell. But there are many other factors that decide it beyond that.