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

I can probably. I guess a few prinicpal/staff engineers can too. But doing cross FFI async function invocations and trying to unify runtimes in that fashion is not a thing that people usually do. And it still wouldn't allow you to call QT socket APIs and Netty socket APIs from the same thread.


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.




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

Search: