3 ms·

> The absence of async callbacks not only makes the code cleaner I agree async callbacks are not very pretty. However, neither is dealing with shared state bet

> The absence of async callbacks not only makes the code cleaner 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.

daxfohl 11y ago
> thread management in general 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.