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

It's not really a problem worth caring about. Just if you wanted to gripe about the complexity of async Rust it's the most obvious to me. "But pretty much no one even lets you do that" is a great counter argument.

But, it is kind of an anti feature. It's incredible that Rust allows custom async executors and the surface area for them is tiny! That said, it's kind of black magic, even for Rust. I'm willing to bet there's fewer than 20 people in the world that could make a production executor today (not that it's going to stay that way - don't get me wrong).

If there's one reason to write an async application today in Rust it's because you can write a custom executor and give it a ridiculous amount of information about how the application is running by communicating with it, while wrapping both callback and polling backed APIs from system libraries in C.

But that's really hard to do if writing an executor is harder than just writing callbacks or polling code manually.



Steve Klabnik did a talk about async/await and building your own executor: https://www.infoq.com/presentations/rust-async-await/

Might be worth a listen if you are intent on building your own!


Is it really that incredible? Look at how Kotlin implemented coroutines. The language support is tiny - nearly everything is implemented in libraries that you can compete with. In particular the language rejected the async/await model: you still mark functions as async (suspend) but there's no language level equivalent of await. Just lots of library level APIs to compare coroutines in different ways. It's really nice.




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

Search: