6 ms·

I totally agree with you, however the alternatives to Async/Await are just way more wierder IMHO. Promises, Futures and what not. I am not very familiar with CS

I totally agree with you, however the alternatives to Async/Await are just way more wierder IMHO. Promises, Futures and what not. I am not very familiar with CSP based concurrency but Async-await strikes a good compromise to me. I just can't deal with this Promise/Future/Callback hell when it comes to managing multiple asyncrhonous or dependent asysnchronous calls. I think Chris Lattner does a way better job at explaining this - https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...

masklinn 7y ago
> I totally agree with you, however the alternatives to Async/Await are just way more wierder IMHO. It’s not, however you do need the entire runtime to be in on it. That’s what Erlang, Go or gevent (for python) do: normal concurrency is in user land and normal IO uses « async ». The code itself looks / is synchronous, it just multiplexes in userland before doing so on OS threads.
divan 7y ago
> I am not very familiar with CSP based concurrency I strongly recommend to check it out. I was absolutely mind-blown when saw this talk (without prior knowledge about Go), and that changed my life quite literally. https://www.youtube.com/watch?v=QDDwwePbDtw https://www.youtube.com/watch?v=QDDwwePbDtw I did a few concurrency related projects (see "Visualizing concurrency in Go" https://divan.dev/posts/go_concurrency_visualize/ https://divan.dev/posts/go_concurrency_visualize/, for example), and it's way more easier to reason about and work with than any other concurrency approaches I've seen so far.