I completely agree here. While I think node.js will have a certain amount of success, its biggest limit is and will continue to be the utterly poor composability of code. You can't just take other code and call it anymore. It has to be written to interact not only asynchronously but ALSO track and maintain state the same way other code is handled that might be using it.
Solutions that make this transparent almost always return to heavy constructs that people like Ryan Dahl called out as big scaling problems (like threads). Just shoveling state around is a mess and abstractions around it almost always reinvent the smalltalk-style spaghetti stack.
I'm not sure node.js has a clear option moving forward. Right now the library choice for this is pretty wide, so fragmentation is a problem. While it's hard to choose sometimes, right now the community really needs some direction.
Meanwhile, languages and platforms that have already chosen their concurrency primitives, be it goroutines and channels, erlang processes and messages, or even ugly threads and locks, seem to be moving forward. It's not about defeating some other method of expressing things. It's about providing something that works and right now node.js only solves half of the problem.
Comments
I completely agree here. While I think node.js will have a certain amount of success, its biggest limit is and will continue to be the utterly poor composability of code. You can't just take other code and call it anymore. It has to be written to interact not only asynchronously but ALSO track and maintain state the same way other code is handled that might be using it.
Solutions that make this transparent almost always return to heavy constructs that people like Ryan Dahl called out as big scaling problems (like threads). Just shoveling state around is a mess and abstractions around it almost always reinvent the smalltalk-style spaghetti stack.
I'm not sure node.js has a clear option moving forward. Right now the library choice for this is pretty wide, so fragmentation is a problem. While it's hard to choose sometimes, right now the community really needs some direction.
Meanwhile, languages and platforms that have already chosen their concurrency primitives, be it goroutines and channels, erlang processes and messages, or even ugly threads and locks, seem to be moving forward. It's not about defeating some other method of expressing things. It's about providing something that works and right now node.js only solves half of the problem.