5 ms·

> I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead. In fact, Rust does have a great solution fo

> I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead. In fact, Rust does have a great solution for nonblocking code: just use threads! Threads work great, they are very fast on Linux, and solutions such as goroutines are just implementations of threads in userland anyway. (The "what color is your function?" post fails to acknowledge that goroutines are just threads, which is one of my major issues with it.) People tell me that Rust services scale up to thousands of requests per second on Linux by just using 1:1 threads. Async is there for those who want better performance than what threads/goroutines/etc. can provide. If you don't want to deal with two "colors" of functions, you don't have to! Just use threads.

temac 7y ago
> The "what color is your function?" post fails to acknowledge that goroutines are just threads, which is one of my major issues with it. """Three more languages that don’t have this problem: Go, Lua, and Ruby. Any guess what they have in common? Threads. Or, more precisely: multiple independent callstacks that can be switched between. It isn’t strictly necessary for them to be operating system threads. Goroutines in Go, coroutines in Lua, and fibers in Ruby are perfectly adequate.""" What more do you need?
nullwasamistake 7y ago
Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency. Say you have 1000 threads. To handle a request each one needs to make 50ms of external or DB calls. In one second, each thread can handle 20 calls. So you can handle 20k requests/second with 1000 threads. But Rust is so fast it can serve 500k requests a second. So with regular threads, you need ~25,000 threads. The OS isn't going to like that. With async you can run a single thread per core, with no concurrency limits. So you get your 500k requests without overhead. With fibers you just run 20k fibers which is a little bit of overhead but easy to do. This is the core reason everyone is pushing async and fibers in fast languages. When you can push a ton of requests/second but each one has latency you can't control, regular threads will kneecap performance. In "slow" languages like Python, Ruby, etc, async/fibers don't really matter because you can't handle enough requests to saturate a huge thread pool anyways.
- staticassertion 7y ago
  Java services have managed for a long time to do just fine. Usually you just have dedicated threadpools for those db/ whatever calls. But yes, eventually, for very heavy cases (more than what I would call "high") you will want async/await.
  - pjmlp 7y ago
    Which can still be done via java.util.concurrent (Callable, Futures, Promises, Flow) until Project Loom arrives.
- j88439h84 7y ago
  In Python I use async instead of threads for reasons unrelated to performance. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html
- noncoml 7y ago
  Why only 1000 threads? Why not 10k or 100k? With 8k stack for each, you can easy have 10k-100k threads in a low-end system
  - MrBuddyCasino 7y ago
    Let's be real here, its not just the memory requirements, because context switching and the associated nuking of cpu caches are not free. You can go very far with it nowadays, but you can go much farther with async code, if you really need to.
    - noncoml 7y ago
      Nobody is denying that async code is faster. But it’s not as dramatic as presented in the grand parent post. And IMHO the added code complexity is not worth the trouble.
      - MrBuddyCasino 7y ago

temac 7y ago

> The "what color is your function?" post fails to acknowledge that goroutines are just threads, which is one of my major issues with it. """Three more languages that don’t have this problem: Go, Lua, and Ruby. Any guess what they have in common? Threads. Or, more precisely: multiple independent callstacks that can be switched between. It isn’t strictly necessary for them to be operating system threads. Goroutines in Go, coroutines in Lua, and fibers in Ruby are perfectly adequate.""" What more do you need?

nullwasamistake 7y ago

Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency. Say you have 1000 threads. To handle a request each one needs to make 50ms of external or DB calls. In one second, each thread can handle 20 calls. So you can handle 20k requests/second with 1000 threads. But Rust is so fast it can serve 500k requests a second. So with regular threads, you need ~25,000 threads. The OS isn't going to like that. With async you can run a single thread per core, with no concurrency limits. So you get your 500k requests without overhead. With fibers you just run 20k fibers which is a little bit of overhead but easy to do. This is the core reason everyone is pushing async and fibers in fast languages. When you can push a ton of requests/second but each one has latency you can't control, regular threads will kneecap performance. In "slow" languages like Python, Ruby, etc, async/fibers don't really matter because you can't handle enough requests to saturate a huge thread pool anyways.

staticassertion 7y ago
Java services have managed for a long time to do just fine. Usually you just have dedicated threadpools for those db/ whatever calls. But yes, eventually, for very heavy cases (more than what I would call "high") you will want async/await.
- pjmlp 7y ago
  Which can still be done via java.util.concurrent (Callable, Futures, Promises, Flow) until Project Loom arrives.
j88439h84 7y ago
In Python I use async instead of threads for reasons unrelated to performance. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html
noncoml 7y ago
Why only 1000 threads? Why not 10k or 100k? With 8k stack for each, you can easy have 10k-100k threads in a low-end system
- MrBuddyCasino 7y ago
  Let's be real here, its not just the memory requirements, because context switching and the associated nuking of cpu caches are not free. You can go very far with it nowadays, but you can go much farther with async code, if you really need to.
  - noncoml 7y ago
    Nobody is denying that async code is faster. But it’s not as dramatic as presented in the grand parent post. And IMHO the added code complexity is not worth the trouble.
    - MrBuddyCasino 7y ago