4 ms·
You can always write a callback oriented program, but this is much nicer!
by closeparen 5y ago
You can always write a callback oriented program, but this is much nicer!
- abraxas 5y agoYeah 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..
- xxs 5y agoIt will still suck compared to NIO & DirectBuffers - and if you really need NIO, this won't be a replacement. Using non-blocking read/write pretty quickly expands to writing your own scheduler with all the needed quirks/boosts/etc.