5 ms·

I used/worked on a similar async model at FB long before I'd ever touched node. Threads are not really solving the same problem as async. Imagine you are buil

by ahupp 3y ago

I used/worked on a similar async model at FB long before I'd ever touched node. Threads are not really solving the same problem as async. Imagine you are building the FB newsfeed. You have 10 stories and want to fetch them as quickly as possible. The stories are all different types and each refers to other data: profile info, privacy, comments (which depend its own profile fetch), likes, etc. So you have this tree of dependent data fetches, how do you minimize the time waiting? You could walk the tree node-by-node, but that balloons your wait time. So you kick each bit of work off to a new thread and wait for it to be done. How do you wait for it? Lots of options of course, but they all end up looking like an ad-hoc implementation of async. Which is fine! But if you have a large codebase where a large fraction of code is dealing with this stuff you pretty soon want the runtime to handle this. And if you are mixing code written by others you really want everyone to use the same mechanism. So the value of async isn't really in the specific implementation choices, it's that it lets you represent this tree in a consistent way. This is less about the number of requests per second, and more about how much code you have to deal with; plenty of places have low RPS but have accumulated lots and lots of code. Second, threads have their own costs even ignoring performance. Arguably a big reason PHP/Hack worked so well for FB is that each request was single-threaded and started with a clean state; there's whole universes of bugs that are avoided in this model. And node doesn't have threads because JS doesn't have threads, microcontrollers may not have threads, etc.

jerf 3y ago
I used "async" long before Node too. It's one of the reasons I knew to stay away from Node. "ad-hoc implementation of async" I think you're confusing the problem with the solution. I solve this sort of thing in Go all the time. This is literally what I was doing yesterday. It's fine in that context. You had to reach for async because it was the only option in your context, not because it was the best choice. Async as it is conceived of today was a hack for dynamic scripting languages that basically had no other option. They "won" there because the environments simply couldn't support any other solution, not because they outcompeted anything.
- osmarks 3y ago
  Go is internally doing async-like cooperative multitasking. You just don't see it because they actually integrated it into the language well.
  - yencabulator 3y ago
    As jerf said in a parent comment, > It's just you manually doing what the compiler ought to be doing for you,
  - jacquesm 3y ago
    Which is the proper way of doing it. As soon as you expose all that plumbing a whole generation of inexperienced programmers are going to use it to build their sandcastles with and then you can spend the next two decades on the cleanup. Such stuff should be implemented once and made bulletproof rather than to give everybody a box with interesting shiny parts that will explode when used wrong.
funcDropShadow 3y ago
> So you have this tree of dependent data fetches, how do you minimize the time waiting? You could walk the tree node-by-node, but that balloons your wait time. So you kick each bit of work off to a new thread and wait for it to be done. How do you wait for it? This is exactly the kind of problem that is targeted by Project Loom [1] and structured concurrency [2] on the JVM. Async programming makes a lot of tools not applicable (or at least very cumbersome to use): debuggers, profilers, tracing tools, stack traces, etc. [1]: https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 [2]: https://openjdk.org/jeps/428 https://openjdk.org/jeps/428

by ahupp 3y ago

jerf 3y ago

I used "async" long before Node too. It's one of the reasons I knew to stay away from Node. "ad-hoc implementation of async" I think you're confusing the problem with the solution. I solve this sort of thing in Go all the time. This is literally what I was doing yesterday. It's fine in that context. You had to reach for async because it was the only option in your context, not because it was the best choice. Async as it is conceived of today was a hack for dynamic scripting languages that basically had no other option. They "won" there because the environments simply couldn't support any other solution, not because they outcompeted anything.

osmarks 3y ago
Go is internally doing async-like cooperative multitasking. You just don't see it because they actually integrated it into the language well.
- yencabulator 3y ago
  As jerf said in a parent comment, > It's just you manually doing what the compiler ought to be doing for you,
- jacquesm 3y ago
  Which is the proper way of doing it. As soon as you expose all that plumbing a whole generation of inexperienced programmers are going to use it to build their sandcastles with and then you can spend the next two decades on the cleanup. Such stuff should be implemented once and made bulletproof rather than to give everybody a box with interesting shiny parts that will explode when used wrong.

funcDropShadow 3y ago

> So you have this tree of dependent data fetches, how do you minimize the time waiting? You could walk the tree node-by-node, but that balloons your wait time. So you kick each bit of work off to a new thread and wait for it to be done. How do you wait for it? This is exactly the kind of problem that is targeted by Project Loom [1] and structured concurrency [2] on the JVM. Async programming makes a lot of tools not applicable (or at least very cumbersome to use): debuggers, profilers, tracing tools, stack traces, etc. [1]: https://openjdk.org/jeps/425 https://openjdk.org/jeps/425 [2]: https://openjdk.org/jeps/428 https://openjdk.org/jeps/428