That's true but how many tasks legit need multithreading? Not many in my experience. Over the course of my career I've come to the conclusion that multithreading is best left for systems programming and very few specific applications (such as a game engine and not much else).

For pretty much everything else that people use multithreaded applications for in the past (encoding, image editing)- multinode processing is vastly superior to multithreaded. Erlang calling out to C (if even necessary) is going to win there over most. Or you could use Python or whatever you wanted.

The Java/Go way of local multithreaded applications seems archaic to me.