5 ms·
When python started incorporating asyncio my initial reaction was fairly negative. I was behaving like a grumpy graybeard programmer ("kids these days should le
by santiagobasulto 1mo ago
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
- greatgib 1mo agoFor 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.
- santiagobasulto 1mo agoCan you elaborate? Why is Python asyncio bad?
- vladms 1mo agoNot 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.
- kjs3 1mo agoI am always amused by "it's bad because it's bad at things it wasn't designed to be good at" rationalizations.
- vladms 1mo agoThere 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.
- kjs3 1mo agoThere 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".
- LtWorf 1mo agoHe's probably one of the people who didn't bother to read the documentation.
- greatgib 1mo agoFirst 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.
- hluska 1mo agoYou made a wild claim about ayncio and backed it up with a wild anecdote about windows and its users?
- IshKebab 1mo agoYeah 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.
- belorn 1mo agoasyncio 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?
- LtWorf 1mo agoI mean… if you have unlimited resources and unlimited speed, going multiprocess makes complete sense.
- nlitened 1mo agoBut if you don’t, you don’t use Python anyway
- LtWorf 1mo agoMaybe you have finite time to do the implementation and your task is IO bound? (which is where using async makes sense, by the way)
- belorn 1mo agoLets 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.
- LtWorf 1mo agoNow let's change the example but bump the limit to 3000 connections.