Hacker News Reader

Comment by RX14 | Hacker News Reader

Unfortunately, unless the IO in the stdlib uses or is modified to schedule these fibers around evented IO, they're essentially useless as soon as you use an external library. Go and Erlang do this, Crystal does this but with only N:1 multiplexing (but that will change before 1.0), but I don't know about other languages.

View on HN

Very true. Node does this too, in the sense that all node libraries are async/callback aware or have async/callback versions of those.

I much prefer the go/erlang version of this. Playing the "what color is your function" game or "will it block" is no fun.

> Playing the "what color is your function" game or "will it block" is no fun.

This was quite painful with.js Node 1-2yrs back when Promises and coroutines started picking up steam [such as https://github.com/tj/co]. It was always a shot in the dark.

Has this situation changed now? (basically is the stdlib all async friendly now?)

Yes, insofar it's been possible for a few years to mechanically upgrade stdlib functions marked with the Async suffix into promises with a helper library such as Bluebird. Any promise based function complying with the common promise spec is automatically async friendly, that is to say the async/await keywords do what you expect and the programmer does not need to chain then-ables anymore. Node v8.0.0 adds a promisifier into core for convenience: https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...

.NET has both nonblocking evented IO and standard blocking IO in the stdlib. Most modern libraries use asynchronous IO, however lots of legacy applications still use blocking calls, making them unsuitable to run in the thread pool.

Reply on news.ycombinator.com