5 ms·
Async is necessary sometimes... but I'm really hating the trend of designing APIs that make it unavoidable, with the assumption that it's necessary always. It j
by tomxor 9y ago
Async is necessary sometimes... but I'm really hating the trend of designing APIs that make it unavoidable, with the assumption that it's necessary always. It just makes code illegible and thus buggy.
- genzoman 9y agoThe async/await paradigm of C#/Typescript fixes this very nicely IMO.
- Jizzle 9y agoI quite like async/await except that it's annoyingly easy to produce a deadlock, and given a snippet, it's not obvious that such a deadlock should occur.
- rco8786 9y agoDo you have an example? I’ve never seen a deadlock in Js. I’m trying to think of how it’s even possible? Async/await is just super around promises anyway.
- Jizzle 9y agoOops, should've specified C# specifically, in which deadlock has become notorious. I don't think there's anything wrong with async/await per se. It looks to me like the linearity of js engine event loops wouldn't produce the same problem.
- rco8786 9y agoOhh gotcha, shoulda picked up on the context :)
- zzbzq 9y agoIronically it is essentially the event loop which causes the deadlock in C#. Depending on what framework/runtime you're in .NET will schedule the await continuation on something called a "SynchronizationContext" which has ~3 different forms but it's basically an event loop/message loop which queues up each continuation on the original thread. The problem occurs when you use .Wait() or .Result instead of 'await'. This causes the function to spin waiting for the Task to finish, which of course it never will if it has a continuation trying to dispatch into that same event loop. This problem doesn't really happen at all under some circumstances, such as if the async chain starts on a background thread, or in .net core where they've removed the SynchronizationContext, hence no event loop, hence no problems.
- dboreham 9y agoThreads were invented decades ago to resolve this problem. Or actors / goroutines / CSP if you want to call them that..
- xroche 9y agoAnd strangely enough, people still reinvent the wheel, reproducing a scheduler in userland, which is both insane in term of code complexity and debuggability, and in term of performances.
- dboreham 9y agoYes, although to be fair they tend to do that because kernel threading never quite does what it needs to do (e.g. doesn't scale to the # threads applications need these days). Your comment is spot on though: I'm only aware of two modern implementations that really work : Erlang and Go.
- kuschku 9y agoAnd the go implementation is also significantly broken, as evidenced by the namespace issue a while ago. https://news.ycombinator.com/item?id=14470231 https://news.ycombinator.com/item?id=14470231
- pcwalton 9y agoKernel threading does scale to the number of threads applications need these days. What can be slow are context switches, but they aren't slow in absolute terms. The vast majority of applications, including Web servers, are perfectly fine with 1:1 threading.
- dozzie 9y agoIt doesn't really scale. Kernel level threads are quite expensive in the terms of memory. Erlang's processes take up few hundred bytes. It's rare to have dozen thousands of kernel-level threads running on Linux, while it's quite common for Erlang servers to have that many processes.
- dahart 9y agoAsync is always necessary in JavaScript, and always has been. (And yes I know it's possible to write a fully synchronous JS program. No front ends do that, because obviously the site would be unusable, and no backends do it because it's a bad idea- inefficient, wasteful, more code than needed, etc. etc..) Which APIs are you seeing that are async and seem like they shouldn't be? Promises make code more legible than callback chains, and async/await make code more legible than promise chains. Do you have any examples of buggy/illegible code and the more legible less buggy alternative?