Sometimes conversations pop up about async Rust with suggestions such as: "What if we disallowed cancellation in its entirety?" 11 Seeing this always confuses me, because it seems it carries a fundamental misunderstanding of what async Rust provides and why it should be used. If the focus is solely on performance, features such as cancellation or .await annotations may seem like a plain nuisance.
But if the focus is more on the features async Rust enables, things like cancellation and timeouts quickly rise from nuisance to key reasons to adopt async Rust. Async Rust grants us the ability to control execution in a way which just isn't possible in non-async Rust. And frankly, isn't even possible in many other programming languages featuring async/.await either. The fact that an async fn compiles down to a lazy state machine instead of an eager managed task is a crucial distinction. And it means that we can author concurrency primitives entirely in library code, rather than needing to build it into the compiler or runtime.
Je suis tellement d'accord avec ça. C'est une critique directe de ce post de blog par l'un des auteurs de Tokio qui m'avait moi aussi laissé vraiment perplexe.
When crashes do occur an engineer needs to spend time to diagnose how it happened and what caused it. Since Pingora's inception we’ve served a few hundred trillion requests and have yet to crash due to our service code
Cette citation. Meilleur argument marketing pour Rust ever.
"Hi, I'm Matthew Wilcox, co-author of the NVMe spec and the troublemaker who said 'you need to do an NVMe driver and then I'll believe that Rust is ready for use in the kernel.' You have succeeded far beyond my expectations, both of you, all of you, thank you so much, you've done a fantastic job. I was not expecting to see these performance numbers, they are amazing."
Le mec qui a bossé là dessus peut être content de lui :D