←back to thread

320 points willm | 1 comments | | HN request time: 0s | source
Show context
atomicnumber3 ◴[] No.45106455[source]
The 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 threads can look like. Then java did it too. Meanwhile, js had better async support the whole time. But all it did was show us that async code just plain sucks compared to green thread code that can just block, instead of having to do the async dances.

So, why engage with it when you already had good solutions?

replies(24): >>45106558 #>>45106616 #>>45106659 #>>45106663 #>>45106684 #>>45106758 #>>45107048 #>>45107148 #>>45107247 #>>45107394 #>>45107701 #>>45107865 #>>45108486 #>>45108978 #>>45109142 #>>45109610 #>>45109958 #>>45110033 #>>45110052 #>>45110805 #>>45111877 #>>45111901 #>>45113010 #>>45113188 #
throw-qqqqq ◴[] No.45106616[source]
> But all it did was show us that async code just plain sucks compared to green thread code that can just block, instead of having to do the async dances.

I take so much flak for this opinion at work, but I agree with you 100%.

Code that looks synchronous, but is really async, has funny failure modes and idiosyncracies, and I generally see more bugs in the async parts of our code at work.

Maybe I’m just old, but I don’t think it’s worth it. Syntactic sugar over continuations/closures basically..

replies(5): >>45106787 #>>45106801 #>>45106917 #>>45109308 #>>45109618 #
lacker ◴[] No.45106801[source]
I'm confused, I feel like the two of you are expressing opposite opinions.

The comment you are responding to prefers green threads to be managed like goroutines, where the code looks synchronous, but really it's cooperative multitasking managed by the runtime, to explicit async/await.

But then you criticize "code that looks synchronous but is really async". So you prefer the explicit "async" keywords? What exactly is your preferred model here?

replies(2): >>45107191 #>>45109392 #
throw-qqqqq ◴[] No.45107191[source]
First, I don’t mean to criticize anything or anyone. People value such things subjectively, but for me the async/sync split does no good.

Goroutines feel like old-school, threaded code to me. I spawn a goroutine and interact with other “threads” through well defined IPC. I can’t tell if I’m spawning a green thread or a “real” system thread.

C#’s async/await is different IMO and I prefer the other model. I think the async-concept gets overused (at my workplace at least).

If you know Haskell, I would compare it to overuse of laziness, when strictness would likely use fewer resources and be much easier to reason about. I see many of the same problems/bugs with async/await..

replies(4): >>45110079 #>>45110379 #>>45112979 #>>45113621 #
1. sfn42 ◴[] No.45113621[source]
I always find it strange how people complain about features when the real problem is that they simply don't like how people use the feature.

Async in C# is awesome, and there's nothing stopping you from writing sync code where appropriate or using threads if you want proper multi threading. Async is primarily used to avoid blocking for non-cpu-bound work, like waiting for API/db/filesystem etc. If you use it everywhere then it's used everywhere, if you don't then it isn't. For a lot of apps it makes sense to use it a lot, like in web apis that do lots of db calls and such. This incurs some overhead but it has the benefit of avoiding blocked threads so that no threads sit idle waiting for I/O.

You can imagine in a web API receiving a large number of requests per second there's a lot of this waiting going on and if threads were idle waiting for responses you wouldn't be able to handle nearly as much throughout.