<story><title>How much memory do you need to run 1M concurrent tasks?</title><url>https://pkolaczk.github.io/memory-consumption-of-async/</url></story><parent_chain><item><author>za3faran</author><text>One thing I wanted to add is that in golang, you end up passing context.Context to all asynchronous functions to handle cancellations and timeouts, so you “color” them regardless. Java folks with structured concurrency have the right idea here.</text></item><item><author>cyberax</author><text>It&amp;#x27;s not really fair to compare async&amp;#x2F;await systems with Go and Java.&lt;p&gt;Go and Java with lightweight threads provide a full-blown system, without any limitations. You don&amp;#x27;t have to &amp;quot;color&amp;quot; your code into async and blocking functions, everything &amp;quot;just works&amp;quot;. Go can even interrupt tight inner loops with async pre-emption.&lt;p&gt;The downside is that Go needs around 2k of stack minimum for each goroutine. Java is similar, but has a lower per-thread constant.&lt;p&gt;The upside is that Go can be _much_ faster due to these contiguous stacks. With async&amp;#x2F;await each yield point is basically isomorphic to a segmented stack segment. I did a quick benchmark to show this: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.alex.net&amp;#x2F;benchmarking-go-and-c-async-await&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.alex.net&amp;#x2F;benchmarking-go-and-c-async-await&lt;/a&gt;</text></item></parent_chain><comment><author>throwy2342</author><text>The correct interpretation here is that golang chose explicit context passing where java chose implicit.&lt;p&gt;It&amp;#x27;s similar to explicit DI vs implicits.&lt;p&gt;the function coloring metaphor doesn&amp;#x27;t make sense since the calling convention is the same nor are there extra function keywords (`async` vs non-async).</text></comment>
<story><title>How much memory do you need to run 1M concurrent tasks?</title><url>https://pkolaczk.github.io/memory-consumption-of-async/</url></story><parent_chain><item><author>za3faran</author><text>One thing I wanted to add is that in golang, you end up passing context.Context to all asynchronous functions to handle cancellations and timeouts, so you “color” them regardless. Java folks with structured concurrency have the right idea here.</text></item><item><author>cyberax</author><text>It&amp;#x27;s not really fair to compare async&amp;#x2F;await systems with Go and Java.&lt;p&gt;Go and Java with lightweight threads provide a full-blown system, without any limitations. You don&amp;#x27;t have to &amp;quot;color&amp;quot; your code into async and blocking functions, everything &amp;quot;just works&amp;quot;. Go can even interrupt tight inner loops with async pre-emption.&lt;p&gt;The downside is that Go needs around 2k of stack minimum for each goroutine. Java is similar, but has a lower per-thread constant.&lt;p&gt;The upside is that Go can be _much_ faster due to these contiguous stacks. With async&amp;#x2F;await each yield point is basically isomorphic to a segmented stack segment. I did a quick benchmark to show this: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.alex.net&amp;#x2F;benchmarking-go-and-c-async-await&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.alex.net&amp;#x2F;benchmarking-go-and-c-async-await&lt;/a&gt;</text></item></parent_chain><comment><author>cyberax</author><text>This is a convention, and you also don&amp;#x27;t _have_ to do it.&lt;p&gt;A function without a context can still be used just fine from any code, you just won&amp;#x27;t be able to cancel it.</text></comment>