So I've been pondering for a while now: is async/await a load of bollocks, or am I just stupid?

I'm gradually coming to the conclusion that it's probably both.

Made a chat application with asyncio yesterday (aiohttp) with my self written sqlite3 database server as backend for performance testing. Challange is to provide three sites life from data synchronized. The C part works good, the python part also , but the fucking resources that it uses. CPU's very high.

Chat stuff is good for async because it's many small tasks. Also, the async stuff is in a loop, and since you're checking full time on messages / notifications anyway, it fits correctly.

if you make me chose: the latter.

very simplified: async/await is a high-level wrapper of the concept of "doing something productive while you wait for XYZ" instead of "twiddling your thumbs while you wait for XYZ".

@tosensei Nah, I reckon it's both.

It's a way of introducing hidden complexity, which is always worthy of suspicion. And the fact that in C# as soon as you have a bit of async in one place you are kind of forced to have it in other places is definitely bollocks.

@donkulator Async/await is probably the least hidden complexity you can have while trying to implement asynchronous code

without a sync/await stuff gets far harder to do

though yeah if in c# the barrier between normal code and async code is like in rust where it's annoying to cross it and you basically have 2 codebases... then it's adding complexity / retardation

in JavaScript it worked extremely well, and there there's no barrier

granted even in JavaScript the stacktraces for errors were a bit sus. it's far worse in rust. like so much worse. the architecture for async/await definitely needs to be improved as a whole in these languages. I do prefer it over having to work with actual threads though, bah

@donkulator "It's a way of introducing hidden complexity, which is always worthy of suspicion." - no. the complexity is already there, or not, depending on your use case. it's only to push that complexity into the library-level, where it's completely designed, engineered, and tested, and you have less opportunities to muck it up yourself.

and after all, "compiling code to assembler" isn't "introducing hidden complexity", either.

"And the fact that in C# as soon as you have a bit of async in one place you are kind of forced to have it in other places is definitely bollocks." - yeah, that's a flaw in the implementation - because sometimes (rarely), you _do_ need to call async code from a sync context. but there are ways to do it - you just don't have to be an idiot about how you do it. as with coding in general.