I agree. Multi-threading introduces a lot more complexity to your app than needed, so they should be used sparingly and only as the very last resort.
In fact, async I/O is what you need most of the time when you think that you need multi-threading. Consider that JavaScript on server side is so fast compared to traditional interpreters like PHP/Python only because of async I/O and it doesn't even need multi-threading!
Sometimes async I/O is not enough.
What about heavy CPU calculations? It'll block the main thread and make the application unresponsive. That's why Workers were introduced in Node 10.5.
Multi threading processing only introduces more complexity when you have mutable data.
async I/O does not solve problems which require multi threading to be solved, it solves an other problem which is made worse with multi threading. You need both; multi threading and async I/O.
I agree. Multi-threading introduces a lot more complexity to your app than needed, so they should be used sparingly and only as the very last resort.
In fact,
async I/Ois what you need most of the time when you think that you need multi-threading. Consider that JavaScript on server side is so fast compared to traditional interpreters like PHP/Python only because of async I/O and it doesn't even need multi-threading!Sometimes async I/O is not enough.
What about heavy CPU calculations? It'll block the main thread and make the application unresponsive. That's why
Workerswere introduced in Node 10.5.Multi
threadingprocessing only introduces more complexity when you have mutable data.async I/O does not solve problems which require multi threading to be solved, it solves an other problem which is made worse with multi threading. You need both; multi threading and async I/O.
Real multithreading is much better than "clustering". You just need a borrow checker :v