Live data from Hacker News

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

tonybaloney.github.io

161–170 of 305 posts

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

#161
post #37

I haven't read the article yet, but I do have something to contribute: several years ago I was ay PyCon and saw a talk in which someone mentioned async. I was interested and wanted to learn to use it. But I found there was no documentation at all! The syntax was briefly described, but not the semantics. I realized, years later, that the (non-)documentation was directed at people who were already familiar with the fea…

FWIW Python got async/await before JavaScript did. I believe at the time the main inspiration was C#.

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

#162
post #54

Earlier 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…

No, goroutines are preemptive. They avoid async hazards though of course introduce some different ones.

To be fair, it depends on the version of Go.

Used to be well-hidden cooperative, these days it's preemptive.

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

#163

Earlier 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…

Hey, I'm one of the (many, many) people who made async in JavaScript happen and I find async complicated.

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

#164

Earlier quoted context omitted.

Everything is not async by default in JS.

I mean everything is running on the runloop, async/await, promises, and callbacks are different flavors of syntactic sugar for the same underlying thing. In JS you can do: async function foo(){...} function bar(){foo().then(...);} In python though async and sync code runs in a fundamentally different way as far as I understand it.

I'm not too familiar with Python async. The only time I used it was to get stderr and stdout out of a subprocess.run() separately. I think anyone using it for performance reasons is insane and should just switch to a more performant language.

Anyway I think the main difference is that in Python you control the event loop whereas in JS there's one fixed event loop and you have no choice about it.

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

#165

Earlier quoted context omitted.

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?

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.

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.

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

#166
post #64

Earlier quoted context omitted.

Async taints code, and async/await fall prey to classic cooperative multitasking issues. "What do you mean that this blocked that?" The memory and execution model for higher level work needs to not have async. Go is the canonical example of it done well from the user standpoint IMO.

The function color thing is a real concern. Am I wrong or did a python user originally coin that idea?

No it was a js dev complaining about callbacks in node. Mainly because a lot of standard library code back then only came in callback flavour. i.e. no sync file writes, etc.

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

#168
Another thing: the lack of JIT. NodeJS is also single-threaded, but it's _fast_ because of one of the best JITs in the industry. So you can feasibly run hundreds if not thousands requests per second on one core.

If you try to do that with Python, you get performance that is not acceptable. So why even bother?

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

#169
post #46

I 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…

I'll second the plug for structured concurrency (and specifically the Trio [1] library that the author wrote.

[1] https://github.com/python-trio/trio

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

#170

You can’t just plug and play it. As soon as you introduce async you need to have the runtime loop and so on. Basically the whole architecture needs to be redesigned

asyncio has been designed to be as "plug and play" as it gets. I'd discourage it, but one could create async loops wherever one would need them, one separate thread per loop, and adapt the code base in a more granular fashion. Blocking through the GIL will persist, though. For any new app that is mostly IO constraint I'd still encourage the use of asyncio from the beginning.

I remember back when the “Pythonic” philosophy was to make the language accessible.

It’s clear that Dr. Frankenstein has been at large and managed to get his hands on Python’s corpse.

Post reply on HN