One of the big reasons I'd say is that 90% of Python work doesn't actually benefit from async? Basically nothing in the data science / simulation / etc. world benefits at all. Web development it does, and Django has sprinkled it in (but not DRF), Flask has a fork that's async and FastAPI is async. At work people have suggested we should switch our Flask code to async to 'make it faster' but for us, we're largely using Flask to server ML models and so there's no benefit by being async at all since we're largely compute bound within the request cycle.
Python has had async for 10 years – why isn't it more popular?
251–260 of 305 posts
Re: Python has had async for 10 years – why isn't it more popular?
#252Earlier quoted context omitted.
Everything is not async by default in JS.
I think what they mean is that there are no blocking functions in the standard library except alert, prompt, and confirm. ( are there any others?)
Yeah, you can call async functions without specifying it as such and the script will just carry on regardless of how you're handling it. Totally weird, but also pretty cool. When I first started some 20 years ago that was a major foot gun for me, coming from PHP where functions always returned before the next one was called.
Re: Python has had async for 10 years – why isn't it more popular?
#253I love JS's async. I don't know how anyone ever did anything useful in the language before it was introduced. I think something between a third and half of the functions and members in LisaGUI are probably async functions at this point.
We used callbacks and generators. It was a bit messy at times, but really, it wasn't all that different. I still use generators quite often.
Re: Python has had async for 10 years – why isn't it more popular?
#254I suppose my negative experiences with async fall under #3, that it is hard to maintain two APIs. One of the most memorable "real software engineering" bugs of my career involved async Python. I was maintaining a FastAPI server which was consistently leaking file descriptors when making any outgoing HTTP requests due to failing to close the socket. This manifested in a few ways: once the server ran out of available f…
I'm not entirely sure how "3rd party library bug" is python's fault.
So you are at least a little sure. A little too much for my taste ;)
Re: Python has had async for 10 years – why isn't it more popular?
#255Earlier quoted context omitted.
> But all it did was show us that async code just plain sucks compared to green thread code that can just block, instead of having to do the async dances. I take so much flak for this opinion at work, but I agree with you 100%. Code that looks synchronous, but is really async, has funny failure modes and idiosyncracies, and I generally see more bugs in the async parts of our code at work. Maybe I’m just old, but I do…
I can tell you guys work with languages like Go, so this isn't true for yourselves, but I usually find it is developers that only ever work with synchronous code who find async complicated. Which isn't surprising, if you don't understand something it can seem complicated. My views is almost that people should learn how to write async code by default now. Regardless of the language. Writing modern applications basical…
I have no problem with async in JS or Rust, but async in Python is a very different beast, and like many people in this thread I do my best to avoid the fully loaded footgun altogether. Writing maintainable Python basically requires avoiding it, so I strongly disagree with "regardless of language".
Re: Python has had async for 10 years – why isn't it more popular?
#256Earlier quoted context omitted.
Because it hides away the underlying machinery. Everything is in a run loop that does not exist in my codebase. The context switching points are obvious but the execution environment is opaque. At least that's how it looks to me.
The problem isn't that it hides away the machinery. The problem is that it hides some things, but not everything. Certainly a lot of stuff hides behind await/async. But as a naive developer who is used to real threads and green threads, I expected there would be some wait to await on a real thread and all the async stuff would just happen... but instead, if you await, actually you've got to be async too. If you had t…
I don't know who you are, but thanks.. My beam code goes brrrr.. so fast, much async, so reliable, no worries.
Re: Python has had async for 10 years – why isn't it more popular?
#257Earlier quoted context omitted.
bottle.py is a WSGI backed framework, right? So it's agnostic about whether you are running with threads, fork, blocking single thread IO, gevent, or what.
Umm, acktually... (the default server is non-threaded and sequential. It was an example.)
[deleted]
Re: Python has had async for 10 years – why isn't it more popular?
#258Earlier quoted context omitted.
I'm confused, I feel like the two of you are expressing opposite opinions. The comment you are responding to prefers green threads to be managed like goroutines, where the code looks synchronous, but really it's cooperative multitasking managed by the runtime, to explicit async/await. But then you criticize "code that looks synchronous but is really async". So you prefer the explicit "async" keywords? What exactly is…
First, I don’t mean to criticize anything or anyone. People value such things subjectively, but for me the async/sync split does no good. Goroutines feel like old-school, threaded code to me. I spawn a goroutine and interact with other “threads” through well defined IPC. I can’t tell if I’m spawning a green thread or a “real” system thread. C#’s async/await is different IMO and I prefer the other model. I think the a…
> I think the async-concept gets overused (at my workplace at least).
Problem is it that it self reinforces and before you look every little function is suddenly async.
The irony is that it is used where you want to write in a synchronous style...
Re: Python has had async for 10 years – why isn't it more popular?
#259The 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…
I agree with you, I think. It's hard to figure out your own position when it comes to multithreading and multitasking APIs.
To me, Go is really well designed when it comes to multithreading because it is built upon a mutual contract where it will break easily and at compile time when you mess up the contract between the scheduling thread and the sub threads.
But, for the love of Go, I have no idea who the person was that decided that the map data type has to be not threadsafe. Once you start scaling / rewriting your code to use multiple goroutines, it's like you're being thrown in the cold water without having learnt to swim before.
Mutexes are a real pain to use in Go, and they could have been avoided if the language just decided to make read/write access threadsafe for at least maps that are known to be accessed from different threads.
I get the performance aspect of that decision, but man, this is so painful because you always have to rewrite large parts of your data structures everywhere, and abstract the former maps away into a struct type that manages the mutexes, which in return feels so dirty and unclean as a provided solution.
For production systems I just use haxmap from the start, because I know its limitations (of hashes of keys due to atomics), because that is way easier to handle than forgetting about mutexes somewhere down the codebase when you are still before the optimization phase of development.
Re: Python has had async for 10 years – why isn't it more popular?
#260I used to keep plugging Unyielding [1] vs. What Color Is Your Function [2] as the right matrix to view these issues within. But then Notes on structured concurrency [3] was written and I just point to that these days. But, to sum it all up for those who want to talk here, there are several ways to look at concurrency but only one that matters. Is my program correct? How long will it take to make my program correct? S…
In [3], isn't there a pretty trivial exploit to get a "background task reads from closed file" again?
async with mk_nursery() as nursery:
with os.fopen(...) as file:
nursery.start_soon(lambda: file.read())