<story><title>When rustc explodes</title><url>https://fasterthanli.me/articles/when-rustc-explodes</url></story><parent_chain><item><author>nbittich</author><text>I don&amp;#x27;t see how rust will manage to fix async await, unless making a v2 of the language. While working with sync rust is often a very pleasant experience, everytime I used async await was awful. 
To the point that I avoid using rust for web &amp;#x2F;networking stuff, any other option is better. 
It&amp;#x27;s also very discouraging to read some people telling there&amp;#x27;s no issue with async await. Of course if you use a thousands of libraries (that are more or less hacks), and never use trait and generics, it&amp;#x27;s probably a decent experience half of the time I&amp;#x27;d say.&lt;p&gt;It&amp;#x27;s something I&amp;#x27;ve only encountered with rust community, in Java when a feature sucks, we just say it sucks. Even the architect that approved it will say it sucks.</text></item></parent_chain><comment><author>surrTurr</author><text>I recently built a little Rust project, which I wanted to integrate into a Web App using Web-assembly (wasm-binden). Writing the Rust code was super fun, however, when I execute one of my functions (which takes around 10 seconds to complete), the whole Web App freezes. Well, this should be an easy fix, just make the Rust function async - right? Nope. Making the Rust function async to return a Promise: Web App freezes. Wrapping the call of the Rust code in Promises: Web App freezes. Using Web Workers to run any Rust code in a separate thread: Great, now you can’t share ANY state whatsoever with the UI thread (and no, you can’t pass any Rust objects to another Web Worker thread, because any wasm objects only consist of _binding_ which need an initialised WASM instance in their own thread. To fix this problem, people on GitHub redirected me to a parallel retracer example, which requires nightly Rust and some other tacky tricks to get running. Maybe I will figure out how to integrate this into my project, maybe I won’t. All I wanted to do, is to run one simple async function using WASM. But as it turned out I will have to implement a frikin raytracer first.</text></comment>
<story><title>When rustc explodes</title><url>https://fasterthanli.me/articles/when-rustc-explodes</url></story><parent_chain><item><author>nbittich</author><text>I don&amp;#x27;t see how rust will manage to fix async await, unless making a v2 of the language. While working with sync rust is often a very pleasant experience, everytime I used async await was awful. 
To the point that I avoid using rust for web &amp;#x2F;networking stuff, any other option is better. 
It&amp;#x27;s also very discouraging to read some people telling there&amp;#x27;s no issue with async await. Of course if you use a thousands of libraries (that are more or less hacks), and never use trait and generics, it&amp;#x27;s probably a decent experience half of the time I&amp;#x27;d say.&lt;p&gt;It&amp;#x27;s something I&amp;#x27;ve only encountered with rust community, in Java when a feature sucks, we just say it sucks. Even the architect that approved it will say it sucks.</text></item></parent_chain><comment><author>blacksmithgu</author><text>The core problem I see is Rust tried too hard to avoid allocations&amp;#x2F;copies and a heavy async runtime. The result is confusing and difficult types and very unclear errors due to apis producing ridiculous types like Future&amp;lt;Arc&amp;lt;Box&amp;lt;dyn Thing&amp;gt;&amp;gt;&amp;gt;.&lt;p&gt;The language should have defined a consistent async model (like coroutines with message passing) and kept &amp;quot;raw async&amp;quot; confined to high performance special libraries and embedded use cases.</text></comment>