4 ms·

As a fullstack dev, I worked with - Spring MVC (Java Futures) - Spring Webflux (Reactor observables) - Scala (Scala Futures & for comprehensions) - TS async

As a fullstack dev, I worked with - Spring MVC (Java Futures) - Spring Webflux (Reactor observables) - Scala (Scala Futures & for comprehensions) - TS async/await - Angular observables - React hooks (which combined with Redux, React Query etc. is a special approach to async programming.) I think it's very important to understand that ultimately, async (non-blocking) programming is kind of a "hard problem" and there is no trivial solution for it. But we can't get around it because we must not block code execution: Javascript runtime environments are single-threaded (except workers) and the JVM has limited thread count, too. Any senior developer has to understand how each of these approaches work and how they are trying to solve the issue of non-blocking code execution. I dare say that this problem area is one of the hardest ones during becoming a more senior developer. In terms of ergonomy (developer experience) when it comes to simple chained non-blocking calls, in my opinion nothing beats async/await in terms of syntax simplicity. I miss them from Java & Scala! No indentation, lambda functions, flatmaps, monads or special methods/hooks needed. You just have the result of an async method right there. I don't agree with the author that we shouldn't use async/await because it _looks like_ synchronous code. We _should_ use it to keep syntax simple and clean wherever possible! The developer has to properly learn the language fundamentals (and how JS code execution works) and know that async/await is just syntax sugar over Promises and generator functions. If they don't do this, then having a Promise.then() chain instead of async/await won't help that developer write better code. On the other hand, once they understand it, they can freely choose between async/await and Promises depending on what needs to be written.

likeclockwork 5y ago
You can't talk about async await without talking about try, catch, and finally. I don't think async+await+try+catch+finally is simpler than promises in any way. I don't find anything simple or clean about imperative error handling.
tm-guimaraes 5y ago
Try ou kotlin coroutines. The suspend keyword really helps out reasoning.
weinzierl 5y ago
"[..] and the JVM has limited thread count, too" I think I understand you point when it comes to the essentially single threaded Javascript runtime, but the thread limit of the JVM is huge, so how does that matter? Not trying to be pedantic, just wanted to know if I missed something.
- gombosg 5y ago
  Yes, for JVM, it's not that trivial and non-blocking code is definitely not mandatory. Our app backend has been written in a blocking fashion and we are gradually transitioning to non-blocking code. Your question is very valid as the JVM can handle even thousands of threads (given the host OS can). Having less threads does keep memory usage lower (as each thread in the thread pool has its own stack space). Also, it's more scalable because if using blocking code execution, you'll need to have one thread per concurrent request served. Lastly, thread starvation can become a problem with blocking code in case of delayed I/O or other failures. If that happens, the server becomes unable to serve new requests. See this SO answer: https://stackoverflow.com/a/63490797 https://stackoverflow.com/a/63490797
mpweiher 5y ago
> I don't agree with the author that we shouldn't use async/await because it _looks like_ synchronous code. Not having code that is actively deceptive sounds like a good idea to me, so agree with the author. > We _should_ use it to keep syntax simple and clean wherever possible! Having clean and simple syntax for async operations is a laudable goal. Having code that is actively deceptive about its semantics seems less than ideal for accomplishing this goal. Maybe we need to figure out new and different syntactic constructs that are clean and simple, but do not pretend to be something they are not?
- wonnage 5y ago
  How are they deceptive? I don't know where the idea that these keywords somehow mimic synchronous code comes from.
  - mpweiher 5y ago
    It's not the keywords that are deceptive. It's keeping the rest of the code in a structure that is extremely different from what actually happens. https://dl.acm.org/doi/10.1145/3297280.3297528 https://dl.acm.org/doi/10.1145/3297280.3297528 "To solve JavaScript's callback hell problem, several language mechanisms like Promise and async/await have already been introduced to JavaScript. Using async/await, which is the most promising one, callback hell code can be rewritten to another simple and shallow nested code with (almost) the same behavior. Unfortunately, however, it is still difficult to precisely understand the execution order of the rewritten async/await code, because the semantics of async/await is difficult. This paper first clarifies that this problem is caused by the difficulty of the async/await semantics. Then, we propose and implement a novel async/await visualizer called AwaitViz, to support for programmers to understand the execution order of async/await. Our contribution is twofold. First, we show the feasibility of implementing the visualizer AwaitViz based on source-code instrumentation, which provides precise information on the JavaScript's asynchronous behavior. Second, we show the difficulties and limitations of implementing AwaitViz."

likeclockwork 5y ago

You can't talk about async await without talking about try, catch, and finally. I don't think async+await+try+catch+finally is simpler than promises in any way. I don't find anything simple or clean about imperative error handling.

tm-guimaraes 5y ago

Try ou kotlin coroutines. The suspend keyword really helps out reasoning.

weinzierl 5y ago

"[..] and the JVM has limited thread count, too" I think I understand you point when it comes to the essentially single threaded Javascript runtime, but the thread limit of the JVM is huge, so how does that matter? Not trying to be pedantic, just wanted to know if I missed something.

gombosg 5y ago
Yes, for JVM, it's not that trivial and non-blocking code is definitely not mandatory. Our app backend has been written in a blocking fashion and we are gradually transitioning to non-blocking code. Your question is very valid as the JVM can handle even thousands of threads (given the host OS can). Having less threads does keep memory usage lower (as each thread in the thread pool has its own stack space). Also, it's more scalable because if using blocking code execution, you'll need to have one thread per concurrent request served. Lastly, thread starvation can become a problem with blocking code in case of delayed I/O or other failures. If that happens, the server becomes unable to serve new requests. See this SO answer: https://stackoverflow.com/a/63490797 https://stackoverflow.com/a/63490797

mpweiher 5y ago

> I don't agree with the author that we shouldn't use async/await because it _looks like_ synchronous code. Not having code that is actively deceptive sounds like a good idea to me, so agree with the author. > We _should_ use it to keep syntax simple and clean wherever possible! Having clean and simple syntax for async operations is a laudable goal. Having code that is actively deceptive about its semantics seems less than ideal for accomplishing this goal. Maybe we need to figure out new and different syntactic constructs that are clean and simple, but do not pretend to be something they are not?

wonnage 5y ago
How are they deceptive? I don't know where the idea that these keywords somehow mimic synchronous code comes from.
- mpweiher 5y ago
  It's not the keywords that are deceptive. It's keeping the rest of the code in a structure that is extremely different from what actually happens. https://dl.acm.org/doi/10.1145/3297280.3297528 https://dl.acm.org/doi/10.1145/3297280.3297528 "To solve JavaScript's callback hell problem, several language mechanisms like Promise and async/await have already been introduced to JavaScript. Using async/await, which is the most promising one, callback hell code can be rewritten to another simple and shallow nested code with (almost) the same behavior. Unfortunately, however, it is still difficult to precisely understand the execution order of the rewritten async/await code, because the semantics of async/await is difficult. This paper first clarifies that this problem is caused by the difficulty of the async/await semantics. Then, we propose and implement a novel async/await visualizer called AwaitViz, to support for programmers to understand the execution order of async/await. Our contribution is twofold. First, we show the feasibility of implementing the visualizer AwaitViz based on source-code instrumentation, which provides precise information on the JavaScript's asynchronous behavior. Second, we show the difficulties and limitations of implementing AwaitViz."