They might make it easier but they don't make it faster which is currently the limiting factor for performance-intensive servers. Making it easier would certainly help - apparently the latest Battlefield game has a lot of bugs due to hard-to-diagnose threading issues in the client. But it wouldn't be viable to write that game in Haskell due to GC and lazy eval, even if the basic performance was good enough which it probably isn't.
What you can write determines how fast it will run. If you don't have green threads, but must use OS-level threads, that's going to be a problem. If you have to be constantly locking because of mutability and can't use STM, that's going to be a problem. And yes, correctness does matter so that's a problem too.
Fast lock-free thread-safe mutable data structures (eg ConcurentLinkedQueue) have been written in languages like Java (and apparently even C++ but I'm less familiar).
Also, STM isn't necessarily much better than locks in practice eg quick Googled example: http://nbronson.github.io/scala-stm/benchmark.html (Don't know how the Haskell equivalent compares)
(where "medium" granularity locks were just as good perf. wise and STM's GC pressure was higher)
This is the monthly thread for posting media of various types that you've found that you enjoy. Post what you're reading, listening to, watching, and your opinion of it. Post recommendations to blogs. Post whatever media you feel like discussing! To see previous recommendations, check out the older threads.
Rules:
Note for this month's thread: As per comment in last month's 'meta' subthread, the "Television and Movies" subthread has been split into two: "TV and Movies (Animation)" and "TV and Movies (Live Action)"