5 ms·

Async isnt about ordered operations its about waiting. When you make a database call, you thread can sit there for 50 ms or do something useful. You can outsour

Async isnt about ordered operations its about waiting. When you make a database call, you thread can sit there for 50 ms or do something useful. You can outsource rendering work to a child process. You dont have to let infinite loops block events.

echelon 10y ago
This seems absurd to me. What exactly are we going to sit there and do while waiting on the data we need to fulfill a query? I work on services where any given endpoint may handle many thousands of requests per second. We don't care about a slight penalty to query the database, because these are very short, and our services return responses on the order of 100 ms. Maybe these are things you care about in a language like Javascript, but in something statically typed, they just don't seem like a problem.
- mahyarm 10y ago
  In a client world, you definitely care about using all of your resources and never halting the rendering/main thread. There is often many things going on at once and you usually need to keep main thread halts under 16ms
- mplewis 10y ago
  You could use the same thread and process to do something else instead of having to spin up another thread or process. If you're running a web server, you can handle another request, then come back to the first one when the data arrives.
  - jtrtoo 10y ago
    So shouldn't the only question ever be: * Would we rather burn computing resources (i.e. on new threads) or calendar time+human resources (i.e. on code refactoring)? Followed closely by: * And does it even matter for our situation? (i.e. since for many situations getting every last drop of performance out of a system isn't the real obstacle; it's making it do something useful for the end-user or business)
    - cookiecaper 10y ago
      and let's not kid ourselves that anyone trying to get maximum performance out of anything would be running JavaScript. If you need max performance, you write C, and sometimes raw ASM.
      - formula1 10y ago
        Having a successful async paradime helps closer to bare metal by setting a standard for how things should work. Now you can likely find more asynchronous libraries that attempt to copy the functionality of something familiar than creating something completely fresh
      - akamaozu 10y ago
        That's like saying if you aren't driving a Veyron you obviously don't care about speed so use a moped.
- WatchDog 10y ago
  > What exactly are we going to sit there and do while waiting on the data we need to fulfill a query? Fulfil more/other queries. > ...in something statically typed, they just don't seem like a problem. What has static typing got to do with asynchronous IO?
- jackweirdy 10y ago
  > What exactly are we going to sit there and do while waiting on the data we need to fulfill a query? On the data you need to fulfil one client's query. The answer is that you do stuff you need to fulfil other clients queries, until you're ready to come back to the first one. I don't see what type systems have to do with your comment either. Scala uses asynchronous concurrency primitives (Futures) and it's statically typed.
- greenleafjacob 10y ago
  It's common in high performance code to use spin locks (also called busy waiting) to reduce latency. In some circumstances it's better to do nothing and be available almost immediately to do some work than to naively context switch away and pay the penalty of context switching back later. Check out how futexes are implemented in Linux for an example - hybrid mutex and spin lock.
- Salgat 10y ago
  If you're running a web server, you're processing possibly hundreds of requests at any given time. Especially since JS is single-threaded, you want to minimize blocking by awaiting, aka yielding your thread to another thread to let it continue processing its own request. Async minimizes time spent doing nothing.
flukus 10y ago
That 50ms isn't necessarily wasted. When I get the results of that database call I want the results returned to the user ASAP, with async operations the thread may be too busy to do that. We do this daily in real life. It's more efficient for me to have 10 minutes down time at work while I'm waiting for someone else than it is for me to start something else then either get interrupted or finish another task before I respond to the person I'm waiting on.
- vincnetas 10y ago
  It depends on how fast you can switch context. If you can switch context in 1ms, then waiting 50ms is a waste of 48ms. But if context switch takes 100ms then sure, it's better to wait idling.

echelon 10y ago

This seems absurd to me. What exactly are we going to sit there and do while waiting on the data we need to fulfill a query? I work on services where any given endpoint may handle many thousands of requests per second. We don't care about a slight penalty to query the database, because these are very short, and our services return responses on the order of 100 ms. Maybe these are things you care about in a language like Javascript, but in something statically typed, they just don't seem like a problem.

mahyarm 10y ago
In a client world, you definitely care about using all of your resources and never halting the rendering/main thread. There is often many things going on at once and you usually need to keep main thread halts under 16ms
mplewis 10y ago
You could use the same thread and process to do something else instead of having to spin up another thread or process. If you're running a web server, you can handle another request, then come back to the first one when the data arrives.
- jtrtoo 10y ago
  So shouldn't the only question ever be: * Would we rather burn computing resources (i.e. on new threads) or calendar time+human resources (i.e. on code refactoring)? Followed closely by: * And does it even matter for our situation? (i.e. since for many situations getting every last drop of performance out of a system isn't the real obstacle; it's making it do something useful for the end-user or business)
  - cookiecaper 10y ago
    and let's not kid ourselves that anyone trying to get maximum performance out of anything would be running JavaScript. If you need max performance, you write C, and sometimes raw ASM.
    - formula1 10y ago
      Having a successful async paradime helps closer to bare metal by setting a standard for how things should work. Now you can likely find more asynchronous libraries that attempt to copy the functionality of something familiar than creating something completely fresh
    - akamaozu 10y ago
      That's like saying if you aren't driving a Veyron you obviously don't care about speed so use a moped.
WatchDog 10y ago
> What exactly are we going to sit there and do while waiting on the data we need to fulfill a query? Fulfil more/other queries. > ...in something statically typed, they just don't seem like a problem. What has static typing got to do with asynchronous IO?
jackweirdy 10y ago
> What exactly are we going to sit there and do while waiting on the data we need to fulfill a query? On the data you need to fulfil one client's query. The answer is that you do stuff you need to fulfil other clients queries, until you're ready to come back to the first one. I don't see what type systems have to do with your comment either. Scala uses asynchronous concurrency primitives (Futures) and it's statically typed.
greenleafjacob 10y ago
It's common in high performance code to use spin locks (also called busy waiting) to reduce latency. In some circumstances it's better to do nothing and be available almost immediately to do some work than to naively context switch away and pay the penalty of context switching back later. Check out how futexes are implemented in Linux for an example - hybrid mutex and spin lock.
Salgat 10y ago
If you're running a web server, you're processing possibly hundreds of requests at any given time. Especially since JS is single-threaded, you want to minimize blocking by awaiting, aka yielding your thread to another thread to let it continue processing its own request. Async minimizes time spent doing nothing.

flukus 10y ago

That 50ms isn't necessarily wasted. When I get the results of that database call I want the results returned to the user ASAP, with async operations the thread may be too busy to do that. We do this daily in real life. It's more efficient for me to have 10 minutes down time at work while I'm waiting for someone else than it is for me to start something else then either get interrupted or finish another task before I respond to the person I'm waiting on.

vincnetas 10y ago
It depends on how fast you can switch context. If you can switch context in 1ms, then waiting 50ms is a waste of 48ms. But if context switch takes 100ms then sure, it's better to wait idling.