<story><title>Rust without the async (hard) part</title><url>https://lunatic.solutions/blog/rust-without-the-async-hard-part/</url></story><parent_chain><item><author>zaphar</author><text>Anything using the green&amp;#x2F;lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff.&lt;p&gt;The perception that async rust is where you should start for concurrent rust because it&amp;#x27;s built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth consideration first and dropping down to low level async code might be warranted when you need the performance it gives and that justifies the increase in development costs.</text></item></parent_chain><comment><author>pornel</author><text>Rust used to have green threads before 1.0 (libgreen). Early Rust was meant to be more like Erlang[1]. The problem with them wasn&amp;#x27;t only the overhead, but also interoperability and how they affect every interaction of the language with the OS and other libraries. It made the whole language dependent on its own custom runtime.&lt;p&gt;Rust isn&amp;#x27;t meant to be a language for CRUD apps (despite making inroads in this space). It&amp;#x27;s meant to be a C&amp;#x2F;C++ alternative that can work every difficult niche where these two can, including processes that already have their own runtimes, kernel space, microcontrollers, and other situations where any overhead or bringing custom threads with magic I&amp;#x2F;O and special stack handling is unacceptable.&lt;p&gt;Rust&amp;#x27;s async is designed to be separate from the core language, and work on top of arbitrary runtimes. Most people use tokio, but it can also work with your custom loop on microcontrollers, or on top of another runtime, e.g. WASM + browser&amp;#x27;s event loop, or gtk-rs that can work on top of GTK&amp;#x27;s event loop.&lt;p&gt;[1]: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;venge.net&amp;#x2F;graydon&amp;#x2F;talks&amp;#x2F;intro-talk-2.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;venge.net&amp;#x2F;graydon&amp;#x2F;talks&amp;#x2F;intro-talk-2.pdf&lt;/a&gt;</text></comment>
<story><title>Rust without the async (hard) part</title><url>https://lunatic.solutions/blog/rust-without-the-async-hard-part/</url></story><parent_chain><item><author>zaphar</author><text>Anything using the green&amp;#x2F;lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff.&lt;p&gt;The perception that async rust is where you should start for concurrent rust because it&amp;#x27;s built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth consideration first and dropping down to low level async code might be warranted when you need the performance it gives and that justifies the increase in development costs.</text></item></parent_chain><comment><author>ianbutler</author><text>I started writing rust ~6mo ago and while I agree with your sentiment, the issue I&amp;#x27;ve run into is that so many packages I need to use, because there isn&amp;#x27;t an alternative and I don&amp;#x27;t want to build it myself, already uses async. I then have to either heavily wall off that part of my code or at a certain threshold realize I may have to adopt async myself because keeping two concurrency models going is really a lot of overhead.&lt;p&gt;It&amp;#x27;s hard to wind down that existing momentum.</text></comment>