Async taints code, and async/await fall prey to classic cooperative multitasking issues. "What do you mean that this blocked that?"

The memory and execution model for higher level work needs to not have async. Go is the canonical example of it done well from the user standpoint IMO.

▲

hinkley 2 days ago | parent | next [-]

The function color thing is a real concern. Am I wrong or did a python user originally coin that idea?

▲

throwawayffffas 2 days ago | parent [-]

No it was a js dev complaining about callbacks in node. Mainly because a lot of standard library code back then only came in callback flavour. i.e. no sync file writes, etc.

▲

munificent 2 days ago | parent | next [-]

I wrote it. :)

Actually, I was and am primarily a Dart developer, not a JS developer. But function color is a problem in any language that uses that style of asynchrony: JS, Dart, etc.

▲

LtWorf 2 days ago | parent | prev [-]

Which is really funny because the linux kernel doesn't do async for file writes :D

▲

yxhuvud 2 days ago | parent [-]

Uh, io_uring does that just fine.

	▲	LtWorf 2 days ago \| parent [-]
		That's yet another thing though.

▲

meowface 2 days ago | parent | prev [-]

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.

▲

pdonis 2 days ago | parent [-]

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 make async functions look more like sync functions, instead of having to be written very differently from the ground up. Unfortunately, requiring the "async" keyword for any async function seriously detracted from that goal.

To me, async functions should have worked like generator functions: when generators were introduced into Python, you didn't have to write "gen def" or something like it instead of just "def" to declare one. If the function had the "yield" keyword in it, it was a generator. Similarly, if a function has the "await" keyword in it, it should just automatically be an async function, without having to use "async def" to declare it.

▲

krmboya 2 days ago | parent [-]

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

	▲	pdonis 2 days ago \| parent [-]
		It would work the same as it works now for generators. A function that calls a generator function isn't a generator just because of that; it only is if it also has the yield keyword in it (or yield from, which is a way of chaining generators). Similarly, a function that calls an async function wouldn't itself be async unless it also had the await keyword. But of course the usual way of calling an async function would be to await it. And calling it without awaiting it wouldn't return a value, just as with a generator; calling a generator function without yielding from it returns a generator object, and calling an async function without awaiting it would return a future object. You could then await the future later, or pass it to some other function that awaited it.