<story><title>Async Views in Django 3.1</title><url>https://testdriven.io/blog/django-async-views/</url></story><parent_chain><item><author>throwaway13337</author><text>I recently moved some code base from py&amp;#x2F;django to c#&amp;#x2F;aspdotnetcore.&lt;p&gt;C# probably has some of the best async primitives of any language. I still managed to be bitten by the very common issue of error logging getting lost in a hidden callback that doesn&amp;#x27;t look like a callback because of the magic of the async keyword (a common issue in node as well).&lt;p&gt;I&amp;#x27;m convinced that the async style of web servers is largely a step in the wrong direction. A leaky abstraction that we don&amp;#x27;t need.&lt;p&gt;A better model already exists - thread per connection - for the majority of what we want as web developers. There are some good things about allowing us to manage our own waits but those things are rare.&lt;p&gt;It reminds me of the choice of when to manage your own memory - usually we don&amp;#x27;t need to, but sometimes we do. Most languages programmers use today decided, rightly, that memory management was an exception and not the norm. We are more productive today for the reduction in cognitive load for most applications as we decide not to manage our own memory.&lt;p&gt;Thread per connection has gotten a bad name for performance which is pretty false. You can create the exact same underlying abstraction with green threads for more concurrency when you absolutely need it (but mostly you don&amp;#x27;t). The code we get from not using async is reduced in complexity substantially.&lt;p&gt;I&amp;#x27;m disappointed that django is on the async bandwagon. It means that I may have to make another framework choice in the future.</text></item></parent_chain><comment><author>simonw</author><text>Django agrees with you. The async design for Django is predicated on the idea that the vast majority of cases are better handled by threads - but very occasionally it is useful to run an async view for something that&amp;#x27;s very IO bound (calling other HTTP APIs most likely).&lt;p&gt;If you watch Andrew&amp;#x27;s talk from PyCon AU last week he explicitly calls out that sync views are still better for most cases, which is why he invested so much effort in making sure they were not negatively affected by the addition of async: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;ibAmA4QQDhs&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;ibAmA4QQDhs&lt;/a&gt;</text></comment>
<story><title>Async Views in Django 3.1</title><url>https://testdriven.io/blog/django-async-views/</url></story><parent_chain><item><author>throwaway13337</author><text>I recently moved some code base from py&amp;#x2F;django to c#&amp;#x2F;aspdotnetcore.&lt;p&gt;C# probably has some of the best async primitives of any language. I still managed to be bitten by the very common issue of error logging getting lost in a hidden callback that doesn&amp;#x27;t look like a callback because of the magic of the async keyword (a common issue in node as well).&lt;p&gt;I&amp;#x27;m convinced that the async style of web servers is largely a step in the wrong direction. A leaky abstraction that we don&amp;#x27;t need.&lt;p&gt;A better model already exists - thread per connection - for the majority of what we want as web developers. There are some good things about allowing us to manage our own waits but those things are rare.&lt;p&gt;It reminds me of the choice of when to manage your own memory - usually we don&amp;#x27;t need to, but sometimes we do. Most languages programmers use today decided, rightly, that memory management was an exception and not the norm. We are more productive today for the reduction in cognitive load for most applications as we decide not to manage our own memory.&lt;p&gt;Thread per connection has gotten a bad name for performance which is pretty false. You can create the exact same underlying abstraction with green threads for more concurrency when you absolutely need it (but mostly you don&amp;#x27;t). The code we get from not using async is reduced in complexity substantially.&lt;p&gt;I&amp;#x27;m disappointed that django is on the async bandwagon. It means that I may have to make another framework choice in the future.</text></item></parent_chain><comment><author>nemothekid</author><text>Anything that spawns an unbounded amount of POSIX threads will be bad for performance, so you need an M:N scheduler to execute threads. I feel like this is pretty hard to retrofit onto an existing language (e.g. I don&amp;#x27;t think you can write a pre-empting scheduler in pure Python as a library either).&lt;p&gt;AFAIK, only Go does this well (with great results) as a result of it being pretty much baked into the language. I don&amp;#x27;t think it&amp;#x27;s an async bandwagon, I think async&amp;#x2F;await is the best way to get concurrency without requiring the whole language to opt-in (as the Rust devs discovered).</text></comment>