4 ms·

Can we talk about no async/await support? Can't build scalable apps when I'm in callback hell. It's like ES5 all over again.

capableweb 6y ago
> Can't build scalable apps when I'm in callback hell What? We've (JavaScript and developers dealing with asynchronous patterns) been able to build scalable (in terms of code and its maintenance) for many many years, probably 10+. async/wait is simply syntactic sugar and doesn't drastically change anything, you still need to understand the asynchronicity underneath it all, and if you do, you won't have any problems building scalable apps using your knowledge.
- ryanthedev 6y ago
  Pretty sure a callback vs synchronous style of coding is a little more than syntactic sugar. It's a complete shift in application design... If I have to flatmap one more time...
  - capableweb 6y ago
    > Pretty sure a callback vs synchronous style of coding is a little more than syntactic sugar Absolutely, asynchronous and synchronous are two very different patterns when programming with very different trade offs for both of them, but async/await is not synchronous, it only make that particular call _look_ synchronous, while actually being asynchronous. Failing to understand that async/await is just syntactic sugar for dealing with asynchronous programming will sooner or later bite you. Here is a gist that shows why async/await is not really synchronous (blocking) programming: https://gist.github.com/matt-mcalister/3f060bf32d292cfebc9448e210e043e2 https://gist.github.com/matt-mcalister/3f060bf32d292cfebc944...
kasperni 6y ago
Java is getting virtual threads/fibers instead of async/await. From https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.ht... ------------- An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa. While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.
- ryanthedev 6y ago
  This is some sauce. Ty.
lostmyoldone 6y ago
I have some trouble understanding what people mean by scalable today, especially why people seem to have to run entirely event driven, and not mostly on the socket read/write edges? Soon to be almost 20 years ago we pushed >10k messages per second on a JVM, using essentially pentium pro class hardware, and the messages spread over thousands of TCP consumers, yielding average latencies well below 0.5 seconds. Not really low latency, but low enough that we didn't need much lower This was on a purely blocking implementation, because that was before almost anyone did anything like that on the JVM. With the advancement in async IO, it's got to be possible to drive many millions of sockets, or have really low latency targets before you have to start being really careful? So what are you guys doing that seems to need so much async code? With that I mean actual async code, not code having locks but pretending to be async by using callbacks everywhere, because that's somewhat common. I'm not trying go be rude, I honestly don't get what people are doing that needs more than the JVM should rather easily provide, unless possibly you have super low latency targets? There seems to be too many that have to resort to quite cumbersome implementation strategies, so I'm starting to think there's some corner of the industry which I have completely missed, and which requires these strategies regularly?

capableweb 6y ago

> Can't build scalable apps when I'm in callback hell What? We've (JavaScript and developers dealing with asynchronous patterns) been able to build scalable (in terms of code and its maintenance) for many many years, probably 10+. async/wait is simply syntactic sugar and doesn't drastically change anything, you still need to understand the asynchronicity underneath it all, and if you do, you won't have any problems building scalable apps using your knowledge.

ryanthedev 6y ago
Pretty sure a callback vs synchronous style of coding is a little more than syntactic sugar. It's a complete shift in application design... If I have to flatmap one more time...
- capableweb 6y ago
  > Pretty sure a callback vs synchronous style of coding is a little more than syntactic sugar Absolutely, asynchronous and synchronous are two very different patterns when programming with very different trade offs for both of them, but async/await is not synchronous, it only make that particular call _look_ synchronous, while actually being asynchronous. Failing to understand that async/await is just syntactic sugar for dealing with asynchronous programming will sooner or later bite you. Here is a gist that shows why async/await is not really synchronous (blocking) programming: https://gist.github.com/matt-mcalister/3f060bf32d292cfebc9448e210e043e2 https://gist.github.com/matt-mcalister/3f060bf32d292cfebc944...

kasperni 6y ago

Java is getting virtual threads/fibers instead of async/await. From https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.ht... ------------- An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa. While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.

ryanthedev 6y ago
This is some sauce. Ty.

lostmyoldone 6y ago

I have some trouble understanding what people mean by scalable today, especially why people seem to have to run entirely event driven, and not mostly on the socket read/write edges? Soon to be almost 20 years ago we pushed >10k messages per second on a JVM, using essentially pentium pro class hardware, and the messages spread over thousands of TCP consumers, yielding average latencies well below 0.5 seconds. Not really low latency, but low enough that we didn't need much lower This was on a purely blocking implementation, because that was before almost anyone did anything like that on the JVM. With the advancement in async IO, it's got to be possible to drive many millions of sockets, or have really low latency targets before you have to start being really careful? So what are you guys doing that seems to need so much async code? With that I mean actual async code, not code having locks but pretending to be async by using callbacks everywhere, because that's somewhat common. I'm not trying go be rude, I honestly don't get what people are doing that needs more than the JVM should rather easily provide, unless possibly you have super low latency targets? There seems to be too many that have to resort to quite cumbersome implementation strategies, so I'm starting to think there's some corner of the industry which I have completely missed, and which requires these strategies regularly?