I agree async callbacks are not very pretty. However, neither is dealing with shared state between threads, or doing thread management in general. Personally I will take the ugly callbacks over buggy/unsafe thread management any day.
> The absence of async callbacks not only makes the code cleaner, but also means that when you're debugging and hit a breakpoint, you can follow the call stack all the way back to the request entrypoint.
Look for the "async call stack" in the v8 debugging tools. This lets you follow async callbacks around like a normal call stack.
> I'd rather state this as "Needs Async Libraries" as a con for Node.
Again, having a single-threaded run loop avoids entire classes of problems (like shared state), which is a huge plus in many cases.
That's the beauty of it though; the JVM web server does the thread management so your app code doesn't have to deal with it at all.
> avoids entire classes of problems (like shared state)
Shared state is an orthogonal thing though. You can have shared state in Node or go stateless in Scala. You can have race conditions in either. Node prevents the simple `shared.x = shared.x + 1` problems, but can't ensure anything across callback boundaries. Scala attacks this by making everything immutable by default. Either way, there shouldn't be shared state in a REST app anyway.
> "async call stack"
That is pretty cool. Actually once Javascript gets async/await added to core, then Node could be pretty viable.
Going multi-threaded and dealing with semaphores and mutexes also makes coding and debugging more difficult. It's all about trade-offs.
Also, remember that you can have unexpected re-entrancy at any callback boundary in the fully async model. It is not a panacea.
You might not need it directly, but under the hood it allows each request to run in its own thread, which eliminates the need for asynchronous callbacks that pollute any node.js code. The absence of async callbacks not only makes the code cleaner, but also means that when you're debugging and hit a breakpoint, you can follow the call stack all the way back to the request entrypoint.
"Asynchronous Libraries" is listed as a pro for Node, but unless you're doing something very IO-intensive at 10K req/sec, asynchronicity is not going to matter one bit on the JVM since it's multithreaded. Going from sync to async at 10K req/s will save you a few MB of RAM, that's all. Assuming you've got that few MB to spare, it won't change your throughput or responsiveness at all. It's a premature optimization that makes coding and debugging more difficult. I'd rather state this as "Needs Async Libraries" as a con for Node.