Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


More 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.


> 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.


yeah 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..




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: