Originally posted by bnolsen
View Post
Your comment is civil but I completely disagree.
I used to do a ton of work on production apps doing high performance concurrent programming in C++: first threads are typically *way* slower than asynchronous programming. On C++/Windows, I used what Microsoft called IOCP (completion ports). On *nix/C++ the TCP select api has async logic. I saw dramatic performance increases going from threads to async. We ultimately did use threads, but just one thread per CPU core. The primary concurrency mechanism was async logic.
A lot of people are using node.js for high performance async development. And, that uses the JavaScript language which is not known for high performance.
Java has the netty library for async development. Scala has much more elegant syntax for async development.
See multi-language high performance server benchmarks here:
I don't think GC is a problem for server or high performance concurrent programming. Google writes much of their services in Java, and they are known for super responsive server apps.
I'm skeptical that GC is a problem in games. Even if it were a problem, you can remove or minimize any memory allocations that happen in your inner render loop. Java games like Wakfu seem to be completely responsive and performant.
I was comfortable with manual memory allocation in C++. GC isn't one of the important features to me in Java/Scala.
Comment