4 ms·
Yeah agreed. It is definitely very welcome syntax sugar and I'll take it over JS callback hell or async/await stuff any day. I just wanted to point out that non
by abraxas 5y ago
Yeah agreed. It is definitely very welcome syntax sugar and I'll take it over JS callback hell or async/await stuff any day. I just wanted to point out that non-blocking I/O has been available in Java for a long time so high I/O throughput applications have been possible to build in Java even though it required more mental overhead.
- nhoughto 5y agoMore mental overhead and tough ecosystem, you end up in the coloured functions problem where you choose to write non blocking code so now all your dependencies / libraries must too. Nodejs worked because it was like this from day 1 but java isn’t. This change would make the base primitives non blocking (really cheap Blocking which is better) by default, so now you can use any~ library and it should just work. Waaay better.
- sgift 5y ago> Nodejs worked because it was like this from day 1 but java isn’t. And even there "worked" is a very liberal definition. Callbacks, promises and whatever else you can find will imho never be as intuitive as threads.
- nhoughto 5y agoyeah it worked, as in the ecosystem was consistent with a single non-blocking pattern.. and then almost immediately went in 5 different directions around how to program around it.. callback hell, async/await, generators, promises etc..