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

You missed the point, the languages I mentioned have it as relevant enough to have the async runtime as part of the standard library, instead of leaving it to 3rd parties.


C++ coroutines are not more „part of the standard library“ than rusts async support. One might say it might be less, since they arrived so late in c++ lifetime and more Production libraries have been built without them und mind.

And again, they don’t make GTK and Qt and boost Asia eventloops interoperable. Even if you implement co_await support for each of them individually


Yes it's VERY important to differenciate between async/await support (co-rutine) and doing async-io.

The problems all come from async-io.

"Pure" async/await can be mixed and matched in rust without any problems.

But the moment you touch IO (including timeout) a reactor is needed and things get complicated.


They surely are defined by ISO C++ standard.

Like any ISO standard, certain details are expected to be implementation dependent in any ISO C++20 compliant compiler, not missing like on Rust's case.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: