111–120 of 305 posts
Not popular? I use async all the time. The evidence this post provides is that flask and Django aren’t all in on async. That’s meaningless.
Wow, didn't even see much about how miserable using the sync_to_async and async_to_sync transformers are. In general, the architectures developed because of the GIL, like Celery and gunicorn and stuff like that, handles most of the problems we run into that async/await solves with slightly better horizontal scaling IMO. The problem with a lot of async code is that it tends not to think beyond the single machine that'…
The author gets close to what I think the root problem is, but doesn't call it out. The truth is that in python, async was too little, too late. By the time it was introduced, most people who actually needed to do lots of io concurrently had their own workarounds (forking, etc) and people who didn't actually need it had found out how to get by without it (multiprocessing etc). Meanwhile, go showed us what good green…
The problem is not python, it's a skill issue.
First of all forking is not a workaround, it's the way multiprocessing works at the low level in Unix systems.
Second of all, forking is multiprocessing, not multithreading.
Third of all, there's the standard threading library which just works well. There's no issue here, you don't need async.
I think Python needs a good `fetch`-like async http client in the stdlib.
I personally recommend aiohttp. Setting up a ClientSession and letting it do its thing is quite nice.
The author gets close to what I think the root problem is, but doesn't call it out. The truth is that in python, async was too little, too late. By the time it was introduced, most people who actually needed to do lots of io concurrently had their own workarounds (forking, etc) and people who didn't actually need it had found out how to get by without it (multiprocessing etc). Meanwhile, go showed us what good green…
green thread have pitfalls too, like this: https://news.ycombinator.com/item?id=39008026
async python is awful. to me it is a by default avoid. and when you can't avoid, use only where it provides outsized benefit.
It was supposed to bring massive concurrency to Python. But as with any async implantation in any language it is too easy to deadlock the entire system. Did you forgot to sprinkle enough `await`? Your code is blocked somewhere, good luck hunting for it. In contrast preemptive green threads are too easy. Be it IO or CPU load all threads will get their slice of CPU time. Nothing is blocked so you can debug your logic e…
I still remember the days when all the libs started adopting async and how so many of them (to this day) support both passing callbacks or returning promises. Async just so naturally fixed the callback hell of 2010s JS that it just became standard even though it is not even heavily used in the browser APIs.
Earlier quoted context omitted.
> async, parallelism, concurrency, why not all three? async is a concurrency mechanism.
async enables a concurrency potential, nothing more That is, if you use external stuff and can delegate work to them, then async is concurrent (async io for instance) But if you do not, then async is regular code with extra steps
My understanding is that JS can't do that (besides service workers which are non-shared memory), but it still has multiple concurrent code-blocks being executed at the same time, just in linear fashion. It will just never use multiple CPU cores at the same time (unless calling some non-JS non-shared-memory code)
Earlier quoted context omitted.
It was memmove() on each task switch. So you could forget about d-cache. And that killed performance on anything but benchmarks.
Also caused subtle bugs. I once had to debug a crash in C++ code that turned out to be due to Stackless Python corrupting stack state on Windows. OutputDebugString() would intermittently crash because Stackless had temporarily copied out part of the stack and corrupted the thread's structured exception handling chain. This wasn't obvious because this occurred in a very deep call stack with Stackless much higher up, a…
But I can imagine what that code did there...