Earlier quoted context omitted.
I'm not entirely sure how "3rd party library bug" is python's fault.
So you are at least a little sure. A little too much for my taste ;)
I don't know why you got downvoted, i thought it was funny.
Python has had async for 10 years – why isn't it more popular?
291–300 of 305 posts
Re: Python has had async for 10 years – why isn't it more popular?
#292It’s probably related to the fact that when they added “await” to JavaScript, it seemed to become the most popular keyword in the language overnight, just comical amounts of it in the average new JavaScript file in the wild.
Somehow I prefer the explicitness of Promise.then().catch(). When I have to do JS. Am I the only one?
Re: Python has had async for 10 years – why isn't it more popular?
#293You 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.
Sure agree, for bi directional websocket communication it is the way to go.
It's just that you have to really think it thorough when using it. Like using asyncio.sleep instead of sleep for example and there are more little things that could easily hurt the performance and advantages of it.
Re: Python has had async for 10 years – why isn't it more popular?
#294I've had no real issues with async, although I primarily use libraries like aiohttp and aiosqlite and even write my own helpers ( https://github.com/rcarmo/aioazstorage is a good example). The vast majority of the Python code I wrote in the last 5-6 years uses asyncio, and most of the complaints I see about it (hard to debug, getting stuck, etc.) were -- at least in my case -- because there were some other libraries…
I share your experience asyncio is easier than threads or multiprocess: less locking issue, easier to run small chunks of code in // (easier to await something than to create a thread that run some method)
There is no locking issue, if you don't mutate some global state from more than 1 thread at the same time. If you program mostly in pure functions, this is a non issue.
Re: Python has had async for 10 years – why isn't it more popular?
#295The 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…
>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). The problem is not python, it's a skill issue. First of all forking is not a workaround, it's the way multiprocessing works at the low level in Unix systems. Second of all, forking is multiprocessing, not multithrea…
fork is extremely heavy,
threads are way lighter, but still opening thousands of threads can become a problem.
opening a thread just to wait for a socket operation don't make sense. and the low level requirements to use ( select/iopool syscalls ) is hard.
coroutines of async/await solve this problem.
Re: Python has had async for 10 years – why isn't it more popular?
#296Earlier quoted context omitted.
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.
Some are more opaque than others.
If those persist in opaqueness, say "confess, or I fetch Ghidra".
If even this does not help, rm -rf is your friend.
Re: Python has had async for 10 years – why isn't it more popular?
#297I love JS's async. I don't know how anyone ever did anything useful in the language before it was introduced. I think something between a third and half of the functions and members in LisaGUI are probably async functions at this point.
We used callbacks and generators. It was a bit messy at times, but really, it wasn't all that different. I still use generators quite often.
Oh... only a "bit" messy, you say? ;)
Re: Python has had async for 10 years – why isn't it more popular?
#298Earlier quoted context omitted.
I think Python async is pretty cool - much nicer than threading or multiprocessing - yet has a few annoying rough edges like you say. Some specific issues I run into every time: Function colours can get pretty verbose when you want to write functional wrappers. You can end up writing nearly the exact same code twice because one needs to be async to handle an async function argument, even if the real functionality of…
> You can end up writing nearly the exact same code twice because one needs to be async to handle an async function argument, even if the real functionality of the wrapper isn't async. Sorry for the possibly naive question. If I need to call a synchronous function from an async function, why can't I just call await on the async argument? def foo(bar: str, baz: int): # some synchronous work pass async def other(bar: A…
Nothing and that’s the problem because even though you can do it, your event loop will block until foo has finished executing, meaning that in this thread no other coroutine will be executed in the meantime (an event loop runs in its own thread. Most of the time there is only the main thread thus a single event loop). This defeats the purpose of concurrent programming.
Re: Python has had async for 10 years – why isn't it more popular?
#299Earlier quoted context omitted.
Interesting that very few people in that thread seem to understand Go's model, especially the author of this proposal. If you don't allow preemption, you still have a sort of coloring because most non async functions aren't safe to call in a virtual thread - they may block the executor. If you call C code, you need to swap out stacks and deal with blocking by potentially spawning more OS threads - that's what CGo doe…
I can't speak to the more technical aspects you bring up b/c I'm not that well versed in the underlying implementations and tradeoffs. > and also too little too late. I think it very likely that Python will still be around and popular 10 years from now. Probably 20 years from now. And maybe 30 years from now. I think that's plenty of time for a new and good idea that addresses significant pain points to take root and…
Fair enough, I was a little too negative. It is good they're thinking about improvements
Re: Python has had async for 10 years – why isn't it more popular?
#300For comparison, I asked about async in the raku programming language (https://rakulang.org). While I don't know details, raku's design avoids function coloring ( https://www.reddit.com/r/rakulang/comments/1n8hjrr/async_in_...).