HN2new | past | comments | ask | show | jobs | submitlogin

There is consensus in some ecosystems. Javascript absolutely maintains that invariant. There are (almost) no blocking functions in the javascript / node standard libraries and we work hard to keep it that way. Go maintains similar discipline at the OS syscall level.

I feel like the "what color is your function" thing is incomplete. There are arguably 3 types of functions:

- Functions which do all their work synchronously and return without blocking

- Async functions which contain an internal state machine

- Functions which block on expensive IO or long computations

Mixing blocking functions and async functions in the same kernel thread leads to various performance disasters. Javascript is so meticulous about not having blocking IO in part because its basically impossible to tell from a function's signature whether it will block the thread. Lua has this problem - callback oriented lua feels like a natural fit for the language, but lots of 3rd party libraries are packed with blocking calls. Writing asyncronous lua feels like fighting a river. You have to constantly guard against calling blocking code, and most API docs won't tell you where they block.



We are talking about Rust. There is no consensus in Rust.


I think the OP was using examples from a different ecosystems to demonstrate how such a consensus could be reached, if people wished for it.


I don't wish it. That sounds terrible to me.


I think your comments have made that clear. Which is fair enough. But I imagine others feel differently.


I have seen fs.*Sync functions being called deep in async-land more than once or twice in Node.


Those methods were added super early (node 0.2 or something) and can’t be removed because of backwards compatibility. Many of the core node team think they should never have been added - for that exact reason.




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

Search: