Top
Best
New

Posted by zdw 4 days ago

What async promised and what it delivered(causality.blog)
182 points | 207 commentspage 3
shmerl 3 hours ago|
So what is the next step in solving it that's better previous ones?
nrds 3 days ago||
Zig is just doing vtable-based effect programming. This is the way to go for far more than async, but it also needs aggressive compiler optimization to avoid actual runtime dispatch.
F-W-M 1 hour ago||
I know what a vtable is, but what is vtable-based effect programming?
charlieflowers 11 hours ago||
Can you monomorphize the injected effect handlers using comptime, for io and allocators (and potentially more)?
mirekrusin 10 hours ago||
No mention of ruby which is colorless.
x3n0ph3n3 6 hours ago|
It's baffling why concurrency is so complicated in every other language when Ruby does is so effortlessly.
FpUser 3 hours ago||
in real life when request handler call async/colored/whatnot it lets the call proceed and immediately ready to process next request. The backend then would have no problems to create ever growing number of asyncs currently in flight. In real life those asyncs would most likely end up calling database. The end result is that backend would simply overwhelm the database and other resources that have to maintain states of those countless asyncs in flight.

This whole thing is basically snake oil. The best thing backend can do instead is have dedicated thread pool where each real thread has its own queue of limited size. Each element in queue would contain input and output state of request and code to deal with those. Once queue grows over certain size the backend should simply immediately return error code (too busy). Much more sound strategy in my opinion.

There are more complex cases of course (like computationally expensive requests with no io that take long time). Handling those would require some extra logic. Async stuff however will not help here either

pyinstallwoes 5 hours ago||
Erlang is a beautiful example of not having to deal with function coloring/creep. Any other language?
jen20 5 hours ago||
It seems unfair to spend so much time in this article talking about JavaScript and Java without mentioning that async/await first appeared in .NET, and _broadly speaking_ works pretty well there.
bironran 11 hours ago||
It’s a slop alright. But it also missed the next mainstream iteration which is Java virtual threads / Goroutines. Those do away with coloring by attacking the root of the problem: that OS threads are expensive.

Sure, it comes with its own issues like large stacks (10k copy of nearly the same stack?) and I predict a memory coloring in the future (stack variables or even whole frames that can opt out from being copied across virtual threads).

twoodfin 8 hours ago||
How did this article get back on the front page with all its comments time-shifted?

My trite slop bashing was days ago:

https://news.ycombinator.com/item?id=47862726

wesselbindt 3 days ago||
I would really hate to work with a blue/red function system. I would have to label all my functions and get nothing in return. But, labelling my functions with some useful information that I care about, that can tell me interesting things about the function without me having to read the function itself and all the functions that it calls, I'd consider a win. I happen to care about whether my functions do IO or not, so the async label has been nothing short of a blessing.
coolThingsFirst 7 hours ago|
Promised delivered exactly what it it.
More comments...