Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tonybaloney.github.io

Post reply on HN
Print view View original

231–240 of 305 posts

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

#231

Post by rich_sasha »

What the article and the comments don't seem to mention is also that the documentation is an outlier on the poor side. Most Python documentation is at least decent. asyncio hides a lot of the complexity behind a tutorial style "just do this" prose, only obliquely mentions the foot guns and gives little guidance on how to actually structure async code.

IME writing an asyncio Python application is a bit like fixing a broken Linux boot. You frantically Google things, the documentation doesn't mention it, and eventually you find a rant on a forgotten Finnish embedded electronics forum where someone has the same problem as you, and is kindly sharing a solution. After 30 mins of C&P of random commands from a stranger on the web, it works, for no reason you can decipher. Thank goodness for the Finns and Google Translate.

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

#232

Post by bertil »

rich_sasha wrote: post #231

What the article and the comments don't seem to mention is also that the documentation is an outlier on the poor side. Most Python documentation is at least decent. asyncio hides a lot of the complexity behind a tutorial style "just do this" prose, only obliquely mentions the foot guns and gives little guidance on how to actually structure async code. IME writing an asyncio Python application is a bit like fixing a b…

This rings incredibly true, with one major exception: Google Translate can’t handle Finnish to a point that’s both confusing and hilarious. If the output explains how asyncio works, I’m guessing the original discussion was about opening portal for demons, or waiting in line to board the ferry to Estonia.

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

#233

Post by krmboya »

pdonis wrote: post #198
meowface wrote: post #193

Earlier quoted context omitted.

gevent has been in Python for ages and still works great. It basically adds goroutine-like green thread support to the language. I still generally start new projects with gevent instead of asyncio, and I think I always will.

I've used gevent and I agree it works well. It has prevented me from even trying to experiment with the async/await syntax in Python for anything significant. However, gevent has to do its magic by monkeypatching. Wanting to avoid that, IIRC, was a significant reason why the async/await syntax and the underlying runtime implementation was developed for Python. Another significant reason, of course, was wanting to mak…

Would this result in surprises like if a function is turned to async by adding an await keyword, all of a sudden all functions that have it in their call stack become async

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

#235

Post by KingOfCoders »

I did a lot of Scala Futures and liked the concept, more than 'async' everywhere, because it was easier to reason what happens and functions were just functions. Since some years I use Go where this is even easier.

But it took me some time to realize I can do the same idioms in Go as in Scala:

  // Scala
  f := Future(x)
  // Do something else until you need f
  ...
  for r
can be written as

  c := channel 
  // Do something else until you need the result
  ...
  r
My mind model was channel as a queue, but it can easily be used like channel as a future for one value.

And `select` for more complicated versions.

I miss the easy composition and delaying of futures though (f.map etc.)

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

#236

Post by KingOfCoders »

nromiun wrote: post #78

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…

What I find funny is Java started with green threads, then moved away to system threads, then back again.

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

#237

Post by harpiaharpyja »

I've been working quite heavily with async Python for five and a half years now. I've been the principal developer of a control system framework for laboratory automation, written pretty much entirely in async Python. I say framework because it's a reusable engine that has gone on to become the foundation for three projects so far. Our organization is primarily involved in materials research.

At it's heart it's kind of like an asynchronous task execution engine that sits on top of an I/O layer which allows the high-level code to coordinate the activities of various equipment. Stuff like robot arms, furnace PID controllers, gantry systems, an automatic hydraulic press/spot welder (in one case), various kinds of pneumatic or stepper actuated mechanisms, and of course, measurement instruments. Often there might be a microcontroller intermediary, but the vast majority of the work is handled by Python.

My experience with async Python has been pretty positive, and I'm very happy with our choice to lean heavily into async. Contrary to some of the comments here I don't find the language's async facilities to be rough at all. Having cancellation work smoothly is also pretty important to us and I can't say I've experienced any pain points with exception-based cancellation. Maybe we've been lucky, but injecting an exception into a task to cancel it actually does work pretty reliably. Integrating dependencies that expose blocking APIs has never been a big deal either. Usually you want to have an interface layer for every third party dependency anyways, and it's no big to deal to just write an async wrapper that uses a threads or a thread pool to keep the blocking stuff off of the main thread.

I personally think that a lot of people's negative experiences here might have more to do with asyncio than the language's async features. Prior to stepping into my current role, I also had some rough experiences with asyncio, which is why we chose to build all of our async code on top of curio. There was some uncertainty at first about how well supported it would be compared to a package in the standard library, but honestly curio is a really well put together package that just works really smoothly.

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

#238

Post by codethief »

xg15 wrote: post #70

I learned about the concept of async/await from JS and back then was really amazed by the elegance of it. By now, the downsides are well-known, but I think Python's implementation did a few things that made it particularly unpleasant to use. There is the usual "colored functions" problem. Python has that too, but on steroids: There are sync and async functions, but then some of the sync functions can only be called f…

> but then some of the sync functions can only be called from an async function, because they expect an event loop to be present

I agree that that's annoying but tbh it sounds like any other piece of code to me that relies on global state. (Man, I can't wait for algebraic effects to become mainstream…)

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

#240

Post by pkolaczk »

tptacek wrote: post #204
eddd-ddde wrote: post #181

Earlier quoted context omitted.

Wouldn't the old school style be more like rust async? Simple structs that you poll whenever you need to explicitly. No magic code that looks synchronous but isn't.

No, Rust async is new-school colored-functions concurrency.

The parent comment is right. Rust async is simple state automata structs you can poll explicitly with no magic. Async/await is just some syntactic sugar on top of that, but you don’t have to use it.

An obvious advantage of doing it that way is you don’t need any runtime/OS-level support. Eg your runtime doesn’t need to even have a concept of threads. It works on bare metal embedded.

Another advantage is that it’s fully cooperative model. No magic preemption. You control the points where the switch can happen, there is no magic stuff suddenly running in background and messing up the state.

Post reply on HN