←back to thread

Python has had async for 10 years – why isn't it more popular?

(tonybaloney.github.io)
320 points willm | 6 comments | 02 Sep 25 17:24 UTC | HN request time: 0.914s | source | bottom
Show context
atomicnumber3 ◴[02 Sep 25 17:41 UTC] No.45106455[source]▶
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 threads can look like. Then java did it too. Meanwhile, js had better async support the whole time. 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.

So, why engage with it when you already had good solutions?

replies(24): >>45106558 #>>45106616 #>>45106659 #>>45106663 #>>45106684 #>>45106758 #>>45107048 #>>45107148 #>>45107247 #>>45107394 #>>45107701 #>>45107865 #>>45108486 #>>45108978 #>>45109142 #>>45109610 #>>45109958 #>>45110033 #>>45110052 #>>45110805 #>>45111877 #>>45111901 #>>45113010 #>>45113188 #
throw-qqqqq ◴[02 Sep 25 17:51 UTC] No.45106616[source]▶
> 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 don’t think it’s worth it. Syntactic sugar over continuations/closures basically..

replies(5): >>45106787 #>>45106801 #>>45106917 #>>45109308 #>>45109618 #
kibwen ◴[02 Sep 25 18:03 UTC] No.45106787[source]▶
> Code that looks synchronous, but is really async, has funny failure modes and idiosyncracies

But this appears to be describing languages with green threads, rather than languages that make async explicit.

replies(1): >>45106901 #
pclmulqdq ◴[02 Sep 25 18:11 UTC] No.45106901[source]▶
Without the "async" keyword, you can still write async code. It looks totally different because you have to control the state machine of task scheduling. Green threads are a step further than the async keyword because they have none of the function coloring stuff.

You may think of use of an async keyword as explicit async code but that is very much not the case.

If you want to see async code without the keyword, most of the code of Linux is asynchronous.

replies(3): >>45107465 #>>45107497 #>>45111699 #
Dylan16807 ◴[02 Sep 25 18:55 UTC] No.45107465[source]▶
Having to put "await" everywhere is very explicit. I'd even say it's equally explicit to a bunch of awkward closures. Why do you say it's less?
replies(3): >>45107594 #>>45107736 #>>45109407 #
1. throwawayffffas ◴[02 Sep 25 21:37 UTC] No.45109407[source]▶
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.

replies(2): >>45109726 #>>45110028 #
2. ForHackernews ◴[02 Sep 25 22:04 UTC] No.45109726[source]▶
I don't understand this criticism. The JVM is opaque, App Engine is opaque, Docker is opaque. All execution environments are opaque unless you've attached a debugger and are manually poking at the thing while it runs.
replies(1): >>45111809 #
3. toast0 ◴[02 Sep 25 22:38 UTC] No.45110028[source]▶
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 to write your async code where you gave an eventloop a FD and a callback to run when it was ready, that would be more explicit, IMHO... but it would be so wordy that it would only get used under extreme duress... I've worked on those code bases and they can do amazing things, but if there's any complexity it quickly becomes not worth it.

Green threads are better (IMHO), because they actually do hide all the machinery. As a developer in a language with mature green threads (Erlang), I don't have to know about the machinery[1], I just write code that blocks from my perspective and BEAM makes magic happen. As I understand it, that's the model for Java's Project Loom aka Java Green Threads 2: 2 Green 2 Threads. The first release had some issues with the machinery, but I think I read the second release was much better, and I haven't seen much since... I'm not a Cafe Babe, so I don't follow Java that closely.

[1] It's always nice to know about the machinery, but I don't have to know about it, and I was able to get started pretty quick and figure out the machinery later.

replies(1): >>45112899 #
4. pclmulqdq ◴[03 Sep 25 02:52 UTC] No.45111809[source]▶
Some are more opaque than others.
replies(1): >>45130204 #
5. worthless-trash ◴[03 Sep 25 06:44 UTC] No.45112899[source]▶
I don't know who you are, but thanks.. My beam code goes brrrr.. so fast, much async, so reliable, no worries.
6. lstodd ◴[04 Sep 25 18:00 UTC] No.45130204{3}[source]▶
If those persist in opaqueness, say "confess, or I fetch Ghidra".

If even this does not help, rm -rf is your friend.