One thing that trips people up with asyncio is that “single threaded” gets interpreted as “no concurrency hazards”.

But coroutines still interleave execution at every await point, so shared mutable state can become just as fragile as in multithreaded code — the scheduling boundary just moves from OS threads to cooperative yield points.

In practice that tends to push designs toward queues, actors, or message-passing patterns if you want to avoid subtle state corruption.

▲

ori_b 4 hours ago | parent | next [-]

Async and await is manually scheduling threads. So, if you're quite careful about what functions you call, you can arrange things so that you don't get concurrency when you don't want it.

Being careful about what functions you call is quite fragile and tedious, and doesn't compose well: what if a library changes when it adds a yield point?

Overall, async/await is a result of people programming like it's 2003, when threads were still very expensive.

▲

josephg an hour ago | parent | next [-]

This works a lot better in JavaScript, which is exactly this model - a single threaded executor with async await. The problem you talk about is solved with function colouring. Async functions are marked as such. In general, sync functions can’t call async functions. (Well, you can invoke them. You just can’t run them to completion before returning).

For all the complaints about function colouring, I’m glad JavaScript has them. A sync function becoming an async function is a breaking API change. This is much better than the situation in Python, where yield points are invisible.

	▲	pocksuppet an hour ago \| parent [-]
		Until every function is async.

▲

vlovich123 2 hours ago | parent | prev [-]

Threads are still expensive in Python - can’t use them for concurrency really like you can with async io afaik.

▲

bootsmann an hour ago | parent | prev | next [-]

This is why we moved a lot of our concurrent python project to golang. There were a couple of cases where some engineer built the system by implicitly relying on the assumption that some coroutine would run blocking until a certain point was reached (avoiding a potential data race) that was then later broken by another change. At least in go we know we cannot rely on this so the concurrency safety has to be considered at all times, leading to better code.

▲

SkiFire13 5 hours ago | parent | prev | next [-]

I don't fully agree with this. Yes, surely shared mutable state can suffer from similar issues, however the cooperative nature of coroutines makes this much easier to handle. OS threads are preemptive and actually run in parallel, so you have to be aware of CPU concurrency and always be ready for a context switch.

	▲	foltik 4 hours ago \| parent \| next [-]
		It’s just some AI generated pseudo insight, look at the rest of their comments.
	▲	cyberax 4 hours ago \| parent \| prev [-]
		Hard disagree. Co-routines are utter hell. They should have never become popular. With traditional locking, the locked segment is usually very clear. It's possible to use race detectors to verify that objects are accessed with consistent locking. The yield points are also clear. With async stuff, ANY await point can change ANY state. And await points are common, even sometimes for things like logging. There are also no tools to verify the consistent "locking". So I often spend hours staring blankly at logs, trying to reconstruct a possible sequence of callbacks that could have led to a bug. E.g.: https://github.com/expo/expo/issues/39428

▲

ipnon 5 hours ago | parent | prev [-]

And in that case you begin to wonder why use Python at all? The language struggles to give developers the granularity needed to finely manage threads like C++, and it doesn't have the actor model first class like Erlang. I love Python, but I love Fortran and Lisp too. They've all served their purpose and it's time to move on, even though there is already incredible momentum behind it.