Why asynchronous Rust doesn't work
I like to joke that the best way to encounter the ugliest parts of Rust is to implement an HTTP router. Hours and days of boxing and pinning, Futures transformations, no async fn in traits, closures not being real first class citizens, T: Send + Sync + &#x27;static, etc.<p>I call this The Dispatch Tax. Because any time you want more flexibility than the preferred static dispatch via generics can give you - oh, so you just want to store all these async fn(HttpRequest) -&gt; Result&lt;HttpResponse&gt;, right? - you immediately start feeling the inconvenience and bulkiness of dynamic dispatch. It&#x27;s like Rust is punishing you for using it. And with async&#x2F;await taking this to a new level altogether, because you are immediately forced to understand how async funcs are transformed into ones that return Futures, how Futures are transformed into anon state machine structs; how closures are also transformed to anon structs. It&#x27;s like there&#x27;s no type system anymore, only structs.<p>That&#x27;s one of the reasons, I think, why Go has won the Control Plane. Sure, projects like K8s, Docker, the whole HashiCorp suite are old news. But it&#x27;s interesting and telling that even solid Rust shops like PingCAP are using Go for their control plane. It seems to me that there&#x27;s some fundamental connection between flexibility of <i>convenient</i> dynamic dispatch and control plane tasks. And of course having the default runtime and building blocks like net and http in the standard library is a huge win.<p>That said, after almost three months of daily Rust it does get better. To the point when you can actually feel that some intuition and genuine understanding is there, and you can finally work on your problems instead of fighting with the language. I just wish that the initial learning curve wasn&#x27;t so high.