<story><title>Local async executors and why they should be the default</title><url>https://maciej.codes/2022-06-09-local-async.html</url></story><parent_chain><item><author>cmrdporcupine</author><text>We wrote asynchronous driven network code for decades without syntactic sugar for it, and it was fine. That 5% performance gain can be had without it. Async syntax is a mistake. Not just because of the mess it makes across the program tree, but also because it brings with it a specific notion of &lt;i&gt;how&lt;/i&gt; to do asynchronous I&amp;#x2F;O.&lt;p&gt;io_uring for example gives an entirely different model, one with some lovely performance benefits. I&amp;#x27;m sure there&amp;#x27;s a way to make it play well with Rust async and tokio, etc. but they&amp;#x27;re not really the same model on the surface. And so having bolted async into the language syntax itself, and also adding an explicit requirement on concepts like &amp;#x27;executors&amp;#x27; into the language, we&amp;#x27;ve created a legacy problem.&lt;p&gt;IMHO async in Rust was a mistake. A systems programming language should not have mandated a technique like this, and should have stayed agnostic.</text></item><item><author>jerf</author><text>I really think in the end, in another decade or two, the community consensus is going to be that async as it is conceived of today is simply a mistake, full stop.&lt;p&gt;Think about it. Where did it come from in its current incarnation? Node. Why did Node choose it? Did it have a multiplicity of options and carefully choose the best one based on years of experience with each choice? No. Async was &amp;quot;chosen&amp;quot; because it was the only option for the weak runtime that it had to work with. It was the only choice.&lt;p&gt;But the Node marketing machine rumbled into action and made bold claims about performance and quality and phrased them in universals across all languages rather than merely claiming it was good for Javascript and that propaganda is still running around in people&amp;#x27;s minds to this day.&lt;p&gt;I know Rust chose it for performance reasons but I still think in a decade or two community consensus will be either that the 5% performance overhead is worth it for any non-trivial program because async is just too much worse, or someone will come up with an even lower impact version of some other option that will dominate it.&lt;p&gt;As your message demonstrates, we&amp;#x27;re still in the phase where you have to pay lip service to the supposed community consensus before saying &amp;quot;but I think it isn&amp;#x27;t really working out&amp;quot;, but as I don&amp;#x27;t care about the community consensus I don&amp;#x27;t mind just saying it. Async is a mistake. It&amp;#x27;s just you manually doing what the compiler ought to be doing for you, and while I&amp;#x27;m open to other possibilities in the future, right now threaded code is straight-up a better option on almost every metric, and the metrics where it may have a slight disadvantage, it&amp;#x27;s only slight and worth it. It&amp;#x27;s not like you choose threading and you instantly lose 10x performance or something. The first and second derivative opinions about async are clearly negative and I don&amp;#x27;t mind jumping farther ahead in the process when it comes to my own engineering decisions.</text></item><item><author>pdimitar</author><text>Just a personal take: after not coding with Rust for several months, I find it more and more difficult to return to an async code I was writing.&lt;p&gt;The whole thing just reads... ugly and inconsistent. It needs too much already-accumulated knowledge. As the article correctly points out, you need a bunch of stuff that are seemingly unrelated (and syntactically speaking you would never guess they belong together). And as other commenters pointed out, you need to scan a lot of docs -- many useful Tokio tools are not just not promoted, they are outright difficult to find at all.&lt;p&gt;Now don&amp;#x27;t get me wrong, I worked on projects where a single Rust k8s node was ingesting 150k events per second. I have seen and believed and I want to use Rust more. But the async story needs the team&amp;#x27;s undivided attention for a long time at this point, I feel.&lt;p&gt;Against my own philosophy and values I find myself attracted to Golang. It has a ton of ugly gotchas and many things are opaque... and I still find that more attractive than Rust. :(&lt;p&gt;This article is a sad reminder for me -- I am kind of drifting away from Rust. I might return and laugh at myself for this comment several months down the line... but at the moment it seems that my brain prefers stuff that&amp;#x27;s quicker to grok and experiment with. Not to mention writing demos and prototypes is objectively faster.&lt;p&gt;If I had executive power in the Rust leadership I&amp;#x27;d definitely task them with taking a good hard look at the current state of async and start making backwards-incompatible changes (backed by new major semver versions of course). Much more macros or simply better-reading APIs might be a very good start. Start making and promoting higher-order concurrency and parallelism patterns i.e. the `scoped_pool` thingy for example.</text></item></parent_chain><comment><author>surajrmal</author><text>Having written decades of async code without rust (and still doing so in c++), I don&amp;#x27;t understand your point. It is really hard to write safe highly performant asynchronous code. Rust makes it safe, but without the additional &amp;quot;syntax sugar&amp;quot; it makes it very unergonomic. The developer velocity I can achieve with async rust is unbelievable compared to what I had to do previously.&lt;p&gt;I think your problem may be with tokio, not async. io_uring and async are not incompatible.</text></comment>
<story><title>Local async executors and why they should be the default</title><url>https://maciej.codes/2022-06-09-local-async.html</url></story><parent_chain><item><author>cmrdporcupine</author><text>We wrote asynchronous driven network code for decades without syntactic sugar for it, and it was fine. That 5% performance gain can be had without it. Async syntax is a mistake. Not just because of the mess it makes across the program tree, but also because it brings with it a specific notion of &lt;i&gt;how&lt;/i&gt; to do asynchronous I&amp;#x2F;O.&lt;p&gt;io_uring for example gives an entirely different model, one with some lovely performance benefits. I&amp;#x27;m sure there&amp;#x27;s a way to make it play well with Rust async and tokio, etc. but they&amp;#x27;re not really the same model on the surface. And so having bolted async into the language syntax itself, and also adding an explicit requirement on concepts like &amp;#x27;executors&amp;#x27; into the language, we&amp;#x27;ve created a legacy problem.&lt;p&gt;IMHO async in Rust was a mistake. A systems programming language should not have mandated a technique like this, and should have stayed agnostic.</text></item><item><author>jerf</author><text>I really think in the end, in another decade or two, the community consensus is going to be that async as it is conceived of today is simply a mistake, full stop.&lt;p&gt;Think about it. Where did it come from in its current incarnation? Node. Why did Node choose it? Did it have a multiplicity of options and carefully choose the best one based on years of experience with each choice? No. Async was &amp;quot;chosen&amp;quot; because it was the only option for the weak runtime that it had to work with. It was the only choice.&lt;p&gt;But the Node marketing machine rumbled into action and made bold claims about performance and quality and phrased them in universals across all languages rather than merely claiming it was good for Javascript and that propaganda is still running around in people&amp;#x27;s minds to this day.&lt;p&gt;I know Rust chose it for performance reasons but I still think in a decade or two community consensus will be either that the 5% performance overhead is worth it for any non-trivial program because async is just too much worse, or someone will come up with an even lower impact version of some other option that will dominate it.&lt;p&gt;As your message demonstrates, we&amp;#x27;re still in the phase where you have to pay lip service to the supposed community consensus before saying &amp;quot;but I think it isn&amp;#x27;t really working out&amp;quot;, but as I don&amp;#x27;t care about the community consensus I don&amp;#x27;t mind just saying it. Async is a mistake. It&amp;#x27;s just you manually doing what the compiler ought to be doing for you, and while I&amp;#x27;m open to other possibilities in the future, right now threaded code is straight-up a better option on almost every metric, and the metrics where it may have a slight disadvantage, it&amp;#x27;s only slight and worth it. It&amp;#x27;s not like you choose threading and you instantly lose 10x performance or something. The first and second derivative opinions about async are clearly negative and I don&amp;#x27;t mind jumping farther ahead in the process when it comes to my own engineering decisions.</text></item><item><author>pdimitar</author><text>Just a personal take: after not coding with Rust for several months, I find it more and more difficult to return to an async code I was writing.&lt;p&gt;The whole thing just reads... ugly and inconsistent. It needs too much already-accumulated knowledge. As the article correctly points out, you need a bunch of stuff that are seemingly unrelated (and syntactically speaking you would never guess they belong together). And as other commenters pointed out, you need to scan a lot of docs -- many useful Tokio tools are not just not promoted, they are outright difficult to find at all.&lt;p&gt;Now don&amp;#x27;t get me wrong, I worked on projects where a single Rust k8s node was ingesting 150k events per second. I have seen and believed and I want to use Rust more. But the async story needs the team&amp;#x27;s undivided attention for a long time at this point, I feel.&lt;p&gt;Against my own philosophy and values I find myself attracted to Golang. It has a ton of ugly gotchas and many things are opaque... and I still find that more attractive than Rust. :(&lt;p&gt;This article is a sad reminder for me -- I am kind of drifting away from Rust. I might return and laugh at myself for this comment several months down the line... but at the moment it seems that my brain prefers stuff that&amp;#x27;s quicker to grok and experiment with. Not to mention writing demos and prototypes is objectively faster.&lt;p&gt;If I had executive power in the Rust leadership I&amp;#x27;d definitely task them with taking a good hard look at the current state of async and start making backwards-incompatible changes (backed by new major semver versions of course). Much more macros or simply better-reading APIs might be a very good start. Start making and promoting higher-order concurrency and parallelism patterns i.e. the `scoped_pool` thingy for example.</text></item></parent_chain><comment><author>kibwen</author><text>&lt;i&gt;&amp;gt; A systems programming language should not have mandated a technique like this&lt;/i&gt;&lt;p&gt;Rust doesn&amp;#x27;t mandate anything. It&amp;#x27;s unipinionated when it comes to concurrency; use whatever approach that you think is best. Async&amp;#x2F;await is just one option among many.</text></comment>