Hacker News Reader

Comment by santiagobasulto | Hacker News Reader

When python started incorporating asyncio my initial reaction was fairly negative. I was behaving like a grumpy graybeard programmer ("kids these days should learn how to use concurrency instead of working on a new runtime altogether!" [0]).

But after using it for a production project I have to say I'm deeply satisfied and surprised by the maturity, quality of APIs and performance in general.

I was proven wrong and I'm happy about that :)

[0] Old man yell at clouds type of meme

View on HN

asyncio has always looked interesting, but whenever I have run into a problem which could use asyncio I have always gone with multiprocesses instead. I am not sure if async would makes my code easier for others to read and debug, and none of my problems seems to be of the kind where process overhead would make a noticeable difference in performance.

Did you find readability to be improved by going async?

I mean… if you have unlimited resources and unlimited speed, going multiprocess makes complete sense.

But if you don’t, you don’t use Python anyway

Maybe you have finite time to do the implementation and your task is IO bound? (which is where using async makes sense, by the way)

Lets make a specific example. You have an APIs to services with data that you want to synchronize to a cache in a local database. The providers allows a maximum of 1-3 connections for each api.

You can write this in async with a pool of connections to each provider, or you can have a pool of worker processes that each have one connection to each provider.

Which will be easier to debug, and which design is easier for the next developer to read, understand and modify? Performance wise the wast majority for both designs will be on waiting at the initial connections to the apis and time spent fetching objects.

Now let's change the example but bump the limit to 3000 connections.

And if the there were 3000, 30000 or 300000 providers the problem would be different. The example I gave was one where I have considered async but went with multiprocessing, which is also why I asked the parent commenter above if they found any direct benefit to readability or debugging when going async.

It would be interesting to hear what kind of domain are you working in where you have 3000 simulations connections to different service providers.

Yeah I dunno, the first time I tried to use asyncio I ran into a bug that nobody knew how to solve. Can't remember what it was but generally if I use something for the first time and immediately hit a bug... Yeah I'm not using that thing if I can help it.

I mean that's true for Python in general, but sadly these days you can't really avoid it.

For me it is quite bad, but just we are now used to it. In the same way that when you ask Windows users about all the bugs and problems they have with their system, they often say that they don't have any. And ten seconds later, will click "ok" on a random crash popup they didn't even read the content of.

You made a wild claim about ayncio and backed it up with a wild anecdote about windows and its users?

Can you elaborate? Why is Python asyncio bad?

Not the OP but my impression with asyncio was that it's great for the uses case it was built for (hence the "no problems") but if you need to do something a bit different it can become an annoyance (hence the "unexpected bugs").

I see it for a specialized solution for a specific class of problems, which can lead to surprises if your problem evolves. There are always trade-offs to be made (performance, flexibility, hardware cost, etc.), asyncio just has different characteristics than the alternatives. Maybe since a upper bound of concurrent users it is always a great (the best?) solution, someone with more experience along all the design and requirements space could comment.

I am always amused by "it's bad because it's bad at things it wasn't designed to be good at" rationalizations.

There are things that are quite good for other than what they were designed for.

I find it interesting when someone mentions that X is bad for something it was not designed for, as much as I am interested when someone mentions that X is good even if it was not designed for something.

There is a huge difference between "X is good/bad at something it was not designed for" and "X is bad because it's bad at something it was not designed for".

First for the syntax it is quite not good, you have to use await and async keywords plus async everything version of all that you are using.

You can't mix non async code with async. And you can easily do in some way and block your application without you noticing.

And in the end, async is not even really async, just cooperative execution.

I'm a big fan of Python since very low version. And I don't have too much difficulty using async/asyncio now I'm used to it, but in all honesty I don't think that it is really great in the grand scheme of things.

He's probably one of the people who didn't bother to read the documentation.

Reply on news.ycombinator.com