4 ms·

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 ext

by RX14 9y ago

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.

anonacct37 9y ago
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.
- dmix 9y ago
  > 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 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?)
  - bmn__ 9y ago
    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_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...
vishbar 9y ago
.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.

4 ms·

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 ext

by RX14 9y ago

anonacct37 9y ago
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.
- dmix 9y ago
  > 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 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?)
  - bmn__ 9y ago
    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_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...
vishbar 9y ago
.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.