<story><title>The Rust I wanted had no future</title><url>https://graydon2.dreamwidth.org/307291.html</url></story><parent_chain><item><author>divan</author><text>It&amp;#x27;s crazy that the programming community even accepted the concept of async&amp;#x2F;await as a sane one.&lt;p&gt;Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is &amp;quot;eating a donut&amp;quot; a sync or async action? If I&amp;#x27;m focusing all my attention on it, essentially putting all tasks aside (after) - then it&amp;#x27;s a synchronous action. If I&amp;#x27;m reading a book&amp;#x2F;watching a video&amp;#x2F;walking&amp;#x2F;etc, while eating – it&amp;#x27;s an async action.&lt;p&gt;How does &amp;quot;func EatADonut() async {}&amp;quot; aka &amp;quot;eating a donut is an inherently async action&amp;quot; even make sense to people?</text></item><item><author>sph</author><text>Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It&amp;#x27;s a good language.&lt;p&gt;That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I know how it works behind the scene (thanks to Jon Gjengset  [1]), it feels so complicated and hacky, a mediocre very high level concept that someone managed to implement as a zero-cost abstraction. Impressive, but still a bad idea.&lt;p&gt;I&amp;#x27;m sure the pro of having a BDFL instead of a committee is being able to follow a singular vision, instead of trying to appease members by adding the fad du jour which might stray a little too far from the original vision. Too many chefs in the kitchen and all.&lt;p&gt;1: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=ThjvMReOXYM&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=ThjvMReOXYM&lt;/a&gt;</text></item></parent_chain><comment><author>pmoleri</author><text>&amp;gt; How does &amp;quot;func EatADonut() async {}&amp;quot; aka &amp;quot;eating a donut is an inherently async action&amp;quot; even make sense to people?&lt;p&gt;Of course it does, read it as &amp;quot;beware, something blocking down the road&amp;quot;.&lt;p&gt;If you can EatADonout without blocking, please do, but want it or not that&amp;#x27;s a different implementation, one that doesn&amp;#x27;t block and the signature it&amp;#x27;s telling you so.&lt;p&gt;We&amp;#x27;re so used to sync and having hidden blocking operations. I wonder if in an alternate universe the first languages considered the blocking&amp;#x2F;async nature of operations and then some newer languages considered hiding this information into seemingly sync functions would produce similar but opposite outrage against it.</text></comment>
<story><title>The Rust I wanted had no future</title><url>https://graydon2.dreamwidth.org/307291.html</url></story><parent_chain><item><author>divan</author><text>It&amp;#x27;s crazy that the programming community even accepted the concept of async&amp;#x2F;await as a sane one.&lt;p&gt;Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is &amp;quot;eating a donut&amp;quot; a sync or async action? If I&amp;#x27;m focusing all my attention on it, essentially putting all tasks aside (after) - then it&amp;#x27;s a synchronous action. If I&amp;#x27;m reading a book&amp;#x2F;watching a video&amp;#x2F;walking&amp;#x2F;etc, while eating – it&amp;#x27;s an async action.&lt;p&gt;How does &amp;quot;func EatADonut() async {}&amp;quot; aka &amp;quot;eating a donut is an inherently async action&amp;quot; even make sense to people?</text></item><item><author>sph</author><text>Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It&amp;#x27;s a good language.&lt;p&gt;That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I know how it works behind the scene (thanks to Jon Gjengset  [1]), it feels so complicated and hacky, a mediocre very high level concept that someone managed to implement as a zero-cost abstraction. Impressive, but still a bad idea.&lt;p&gt;I&amp;#x27;m sure the pro of having a BDFL instead of a committee is being able to follow a singular vision, instead of trying to appease members by adding the fad du jour which might stray a little too far from the original vision. Too many chefs in the kitchen and all.&lt;p&gt;1: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=ThjvMReOXYM&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=ThjvMReOXYM&lt;/a&gt;</text></item></parent_chain><comment><author>kmac_</author><text>How about waiting until all or part of donut pack is eaten by multiple eaters? Jokes aside, async&amp;#x2F;await comes from easier handling of a callback code and automatic function splitting. Writing asynchronous donut eating in loops or with yielding of partial results is very easy to swallow with such syntactic sugar. The whole model is very easy to grasp and to work with. I&amp;#x27;m not saying that&amp;#x27;s the best solution but it definitely works well.&lt;p&gt;Regarding stickiness of function colors - it never happens when async&amp;#x2F;await is used correctly (in the same principle as IO monad isn&amp;#x27;t sticky).</text></comment>