6 ms·

It started a bit slow but I ended up watching the whole thing. Not sure I agree with the comparison at the end to asp.net mvc and "waiting for a database to co

It started a bit slow but I ended up watching the whole thing. Not sure I agree with the comparison at the end to asp.net mvc and "waiting for a database to complete the request" - with mvc4 async controllers, .net 4.0 tasks and the new mvc 4.5 await keyword, async processing of web requests is pretty much a solved problem in the ms stack. Not that node doesn't look like fun-as-hell to code-in - for that alone I would be willing to give it a go.

robconery 14y ago
Async controllers don't solve this problem, they actually create 10 more. Same with tasks - you have thread locking issues, race conditions and other fun async stuff at the thread level. Node is single threaded, (basically) single process. I get your point - that it's possible (it's always been) - it just isn't the way 99.99999% of the people use it.
- drub0y 14y ago
  Eh, that's a little bit of a FUDdy statement. You don't instantly have "locking issues" and/or "race conditions" to worry about just because you use an async controller with the TPL (async keyword in .NET 4.5). The only time you have to deal with locking and race conditions is if the work you're doing is trying to cooperate and/or touching a shared resource (e.g. a static field). In the most common/basic case of receive a web request, fire off a call to a database/remote service asynchronously and wait for it to come back before you continue processing the original request you don't have to worry about anything because you're not sharing any local state and I would hope the database/remote service you're talking to has its own locking. That's not to say that there aren't merits to node's single threaded execution model in that, _when you do_ need to access a shared resource, you don't have to worry about locking/coordination, but that's a whole other debate. :)

robconery 14y ago

Async controllers don't solve this problem, they actually create 10 more. Same with tasks - you have thread locking issues, race conditions and other fun async stuff at the thread level. Node is single threaded, (basically) single process. I get your point - that it's possible (it's always been) - it just isn't the way 99.99999% of the people use it.

drub0y 14y ago
Eh, that's a little bit of a FUDdy statement. You don't instantly have "locking issues" and/or "race conditions" to worry about just because you use an async controller with the TPL (async keyword in .NET 4.5). The only time you have to deal with locking and race conditions is if the work you're doing is trying to cooperate and/or touching a shared resource (e.g. a static field). In the most common/basic case of receive a web request, fire off a call to a database/remote service asynchronously and wait for it to come back before you continue processing the original request you don't have to worry about anything because you're not sharing any local state and I would hope the database/remote service you're talking to has its own locking. That's not to say that there aren't merits to node's single threaded execution model in that, _when you do_ need to access a shared resource, you don't have to worry about locking/coordination, but that's a whole other debate. :)