<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>withoutboats3</author><text>Rust chose to drop the green thread library so that it could have no runtime, supporting valuable use cases for Rust like embedding a Rust library into a C binary, which we cared about. Go is not really usable for this (technically it&amp;#x27;s possible, but it&amp;#x27;s ridiculous for exactly this reason). So those sorts of users are getting a lot of benefit from Rust not having a green threading runtime. As are any users who are not using async for whatever reason.&lt;p&gt;&lt;i&gt;However&lt;/i&gt;, async Rust is not using stackless coroutines for this reason - it&amp;#x27;s using stackless coroutines because they achieve a better performance profile than stackful coroutines. You can read all about it on Aaron Turon&amp;#x27;s blog from 2016, when the futures library was first released:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;aturon.github.io&amp;#x2F;blog&amp;#x2F;2016&amp;#x2F;08&amp;#x2F;11&amp;#x2F;futures&amp;#x2F;&quot; rel=&quot;nofollow noreferrer&quot;&gt;http:&amp;#x2F;&amp;#x2F;aturon.github.io&amp;#x2F;blog&amp;#x2F;2016&amp;#x2F;08&amp;#x2F;11&amp;#x2F;futures&amp;#x2F;&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;aturon.github.io&amp;#x2F;blog&amp;#x2F;2016&amp;#x2F;09&amp;#x2F;07&amp;#x2F;futures-design&amp;#x2F;&quot; rel=&quot;nofollow noreferrer&quot;&gt;http:&amp;#x2F;&amp;#x2F;aturon.github.io&amp;#x2F;blog&amp;#x2F;2016&amp;#x2F;09&amp;#x2F;07&amp;#x2F;futures-design&amp;#x2F;&lt;/a&gt;&lt;p&gt;It is not the case that people using async Rust are getting the &amp;quot;worst of both worlds.&amp;quot; They are getting better performance by default and far greater control over their runtime than they would be using a stackful coroutine feature like Go provides. The trade off is that it&amp;#x27;s a lot more complicated and has a bunch of additional moving parts they have to learn about and understand. There&amp;#x27;s no free lunch.</text><parent_chain><item><author>HippoBaro</author><text>The argument here is that Rust chose to implement coroutines the wrong way. It went the route of stackless coroutines that need async&amp;#x2F;await and colored functions. This creates all the friction the article laments over.&lt;p&gt;But it also praises Go for its implementation, which is also based on a coroutine of a different kind. Stackful coroutines, which do not have any of these problems.&lt;p&gt;Rust considered using those (and, at first, that was the project&amp;#x27;s direction). Ultimately, they went to the stackless operation model because stackfull coroutine requires a runtime that preempts coroutines (to do essentially what the kernel does with threads). This was deemed too expensive.&lt;p&gt;Most people forget, however, that almost no one is using runtime-free async Rust. Most people use Tokio, which is a runtime that does essentially everything the runtime they were trying to avoid building would have done.&lt;p&gt;So we are left in a situation where most people using async Rust have the worst of both worlds.&lt;p&gt;That being said, you can use async Rust without an async runtime (or rather, an extremely rudimentary one with extremely low overhead). People in the embedded world do. But they are few, and even they often are unconvinced by async Rust for their own reasons.</text></item><item><author>grug_htmx_dev</author><text>Yes, async is effectively a much harder version of Rust, and it&amp;#x27;s regrettable how it&amp;#x27;s been shoved down the throats of everyone, while only 1% of projects using it really need it. Hover, async is also amazing in these 1% of cases when it&amp;#x27;s useful.&lt;p&gt;If you have a service that handles massive amounts of network calls at the core (think linkerd, nginx, etc.), or you want to have a massive amount of lightweight tasks in your game, or working on an embedded software where you want cooperative concurrency, async Rust is an amazing super-power.&lt;p&gt;Most system&amp;#x2F;application level things is not going to need async IO. Your REST app is going to be perfectly fine with a threadpool. Even when you do need async, you probably want to use it in a relatively small part of your software (network), while doing most of the things in threads, using channels to pass work around between async&amp;#x2F;blocking IO parts (aka hybrid model).&lt;p&gt;Rust community just mindlessly over-did using async literally everywhere, to the point where the blocking IO Rust (the actually better UX one) became a second class citizen in the ecosystem.&lt;p&gt;Especially visible with web frameworks where there is N well designed async web frameworks (Axum, Wrap, etc.) and if you want a blocking one you get:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  tiny_http, absolute bare bones but very well done
  rouille - more wholesome, on top of tiny_http, but APIs feel very meh comparing to e.g. Axum
  astra - very interesting but immature, and rather barebones&lt;/code&gt;&lt;/pre&gt;</text></item></parent_chain></comment><story><title>Maybe Rust isn’t a good tool for massively concurrent, userspace software</title><url>https://bitbashing.io/async-rust.html</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>brundolf</author><text>For better or worse, when faced with choices like this Rust has consistently decided to make sure it&amp;#x27;s workable for the lowest-level usecases (embedded, drivers, etc). I respect the consistency, and I appreciate that it&amp;#x27;s focused on an under-served market, especially compared to eg. web applications (an over-served market, if anything), even if it&amp;#x27;s sometimes a bummer for me personally</text><parent_chain><item><author>HippoBaro</author><text>The argument here is that Rust chose to implement coroutines the wrong way. It went the route of stackless coroutines that need async&amp;#x2F;await and colored functions. This creates all the friction the article laments over.&lt;p&gt;But it also praises Go for its implementation, which is also based on a coroutine of a different kind. Stackful coroutines, which do not have any of these problems.&lt;p&gt;Rust considered using those (and, at first, that was the project&amp;#x27;s direction). Ultimately, they went to the stackless operation model because stackfull coroutine requires a runtime that preempts coroutines (to do essentially what the kernel does with threads). This was deemed too expensive.&lt;p&gt;Most people forget, however, that almost no one is using runtime-free async Rust. Most people use Tokio, which is a runtime that does essentially everything the runtime they were trying to avoid building would have done.&lt;p&gt;So we are left in a situation where most people using async Rust have the worst of both worlds.&lt;p&gt;That being said, you can use async Rust without an async runtime (or rather, an extremely rudimentary one with extremely low overhead). People in the embedded world do. But they are few, and even they often are unconvinced by async Rust for their own reasons.</text></item><item><author>grug_htmx_dev</author><text>Yes, async is effectively a much harder version of Rust, and it&amp;#x27;s regrettable how it&amp;#x27;s been shoved down the throats of everyone, while only 1% of projects using it really need it. Hover, async is also amazing in these 1% of cases when it&amp;#x27;s useful.&lt;p&gt;If you have a service that handles massive amounts of network calls at the core (think linkerd, nginx, etc.), or you want to have a massive amount of lightweight tasks in your game, or working on an embedded software where you want cooperative concurrency, async Rust is an amazing super-power.&lt;p&gt;Most system&amp;#x2F;application level things is not going to need async IO. Your REST app is going to be perfectly fine with a threadpool. Even when you do need async, you probably want to use it in a relatively small part of your software (network), while doing most of the things in threads, using channels to pass work around between async&amp;#x2F;blocking IO parts (aka hybrid model).&lt;p&gt;Rust community just mindlessly over-did using async literally everywhere, to the point where the blocking IO Rust (the actually better UX one) became a second class citizen in the ecosystem.&lt;p&gt;Especially visible with web frameworks where there is N well designed async web frameworks (Axum, Wrap, etc.) and if you want a blocking one you get:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  tiny_http, absolute bare bones but very well done
  rouille - more wholesome, on top of tiny_http, but APIs feel very meh comparing to e.g. Axum
  astra - very interesting but immature, and rather barebones&lt;/code&gt;&lt;/pre&gt;</text></item></parent_chain></comment><story><title>Maybe Rust isn’t a good tool for massively concurrent, userspace software</title><url>https://bitbashing.io/async-rust.html</url></story>