←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 #
kibwen ◴[] No.45106787[source]
> Code that looks synchronous, but is really async, has funny failure modes and idiosyncracies

But this appears to be describing languages with green threads, rather than languages that make async explicit.

replies(1): >>45106901 #
pclmulqdq ◴[] No.45106901[source]
Without the "async" keyword, you can still write async code. It looks totally different because you have to control the state machine of task scheduling. Green threads are a step further than the async keyword because they have none of the function coloring stuff.

You may think of use of an async keyword as explicit async code but that is very much not the case.

If you want to see async code without the keyword, most of the code of Linux is asynchronous.

replies(3): >>45107465 #>>45107497 #>>45111699 #
1. vova_hn ◴[] No.45111699{3}[source]
> Green threads are a step further than the async keyword because they have none of the function coloring stuff.

I would say that green threads still have "function coloring stuff", we just decided that every function will be async-colored.

Now, what happens if you try to cross an FFI-border and try to call a function that knows nothing about your green-thread runtime is an entirely different story...