Posted by willm 9/2/2025
I really tried to make it work, but eventually gave up and went back to deque. Now life is great.
The Trio library felt easy to learn and just worked without much fuss.
* Asyncio is pretty good, and is usually the best choice for non-blocking I/O in python these days.
* Asyncio doesn't add multi-core scaling to python. It's not a replacement for threads and doesn't lift the GIL-imposed scaling limitations. If these things are what you're after from asyncio you'll be disappointed, but they're not what it's trying to add and not adding them doesn't make it a failure.
* "Coloured functions" is a nonsense argument and that article made the whole world slightly more dumb.
* The GIL is part of the reason for python's success. I hope nogil either somehow manages to succeed without compromising the benefits the GIL has brought (I'll be amazed if that happens) or fails entirely. Languages are tools and every tool in your toolbox doesn't have to eventually turn into a drill. If your use case requires in-process parallelisation of interpreted CPU-bound workloads across multiple cores, python is just the wrong thing to use.
* It is indeed extremely annoying that we don't have async file access yet. I hope we get it soon.
greenlet which is sort of minimal stackless .. before 2008
pycoev which is on one hand greenlets without memmove()s, on the other hand sort of io-scheduled m:n threading I wrote myself in 2009.
so, at least idk, 20 years?
It was first needed. Then 10 years passed, people got around to pushing it through the process aaand by the time it was done it was already not needed. so it all stalled. Same with Rust.
Nowadays server-side async is handled very differently. And client-side is dominated by that abomination called JS.
[1] https://www.tomshardware.com/pc-components/cpus/amd-announce...
The more significant problem was that Stackless was a separate distribution. Every time CPython updated, there would be a delay until Stackless updated, and tooling like Python IDEs varied in whether they supported Stackless.
But I can imagine what that code did there...
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 errors instead of deadlocks everywhere.
Async works in JS so well because the entire language is designed for it, instead of async being just bolted on. You can't even run plain `sleep` to block, you need setTimeout.
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.
Some time ago I tried to run just 10k OS threads on a small PC and it just crashed. So clearly OS threads have not improved much.
In order to appease the various flavours they mixed and matched stuff from Tornado, gevent, etc.
They should have stuck with the most seamless of those (gevent) and instead of having it monkey-patch the runtime go the Java VirtualThread route and natively yield in all the I/O APIs.
This would have given a Go-esque ease of use and likely would have been immensely more popular.
Many people in my bubble (around 2013-2017) just never went with python 3, but chose other languages.
The company I was working for started important applications in python 2 as late as 2014 because the libraries we needed weren't ported yet. We never went python 3 later, but went to go instead, so we completely missed any python async thing.
Structured concurrency libraries like anyio or trio are actually pretty nice -- "stacks" and stack traces are good things. Python multi exception concept is weird --- but also I think probably good ish.
It is still a pita to orchestrate around the gil/how terrible python multiprocessing side effects are wherever cpu bound workloads actually exist ...