6 ms·

> when you have a huge number of very small tasks running concurrently because that's generally where OS-driven parallelism tends to suffer but is it such a com

> when you have a huge number of very small tasks running concurrently because that's generally where OS-driven parallelism tends to suffer but is it such a common scenario Web servers are all about I/O and handling small tasks (requests), and are a perfect use case for asynchronous programming. > That sounds like premature optimization in many situations IMO Maybe in some cases... but then just don't use futures. Rust does not have a runtime, so it gives you the choice. std is all blocking, so you can spawn threads and do event-driven programming, which might be just fine for a lot of people. async is more ergonomic for Rust specific reasons, makes sense for a lot of use cases, and was a highly requested language feature, so it was added to the language. OS threads can work just fine for many people. If that includes you, you don't have to use async.

sanxiyn 6y ago
You may want async if you are writing the next nginx, but for most web application servers threading is perfectly fine.
- Xorlev 6y ago
  Again, depends on if you're doing a lot of IO, especially if you want request-based IO parallelism. It's worth mentioning that even if you're IO-bound at your DB, running an async application server now means you don't need to tie up a thread waiting on it. Memory usage aside, you more or less don't need to think about threads much, whereas a threadpool (one waiting on IO) is something you have to actively manage.
- deleted 6y ago
  [deleted]
- maccam94 6y ago
  But nginx is usually just a proxy for connecting to app servers, and your app servers still need to handle all of those requests.
- mycoliza 6y ago
  Rust is intended as a systems programming language, it's for people who are writing "the next nginx". It turns out that there are also a bunch of people who want to write webapp servers in Rust, too, but that's never really been the goal.
  - sanxiyn 6y ago
    Eh, so Rust is not for me? I seem to have heard Rust being inclusive and empowering everyone blah blah. I must have misheard.
    - hombre_fatal 6y ago
      It's clear this is one of your hobby horses. Every comment thread here is encumbered with you pointing out that you wouldn't like it if async were the default, fair enough. In fact, you don't seem to like the idea in general. ctrl-f "sanxiyn" yields 28 instances, most of them restating in every subtree the same point about how you think threads > async. Since I think most of us tend to read the comments section top to bottom, it seems ideal to limit your opinion to a couple comments and then put your effort into making those comments a good rundown of your position. It would certainly be more interesting to read and consider.
      - ldng 6y ago
        He's multi-threading ! (Sorry could not help myself :-D)
      - sanxiyn 6y ago
        You may want to contribute something concrete. I did learn some new advantages of async over threading from replies, besides tired C10K. Yes, async is useful for C10K. No, I am not solving C10K problem. 1. If you use async in single thread mode, you can save thread synchronization. 2. async works better for idle connections and slow connections, even when the absolute number of connections is not large. 3. async task is easier to cancel than thread. I still won't use async since thread synchronization hasn't been slow for me, thread cancellation hasn't been problematic for me, and I use nginx to handle idle connections and slow connections, but it's useful to know in case I need.
judofyr 6y ago
> Web servers are all about I/O and handling small tasks (requests), and are a perfect use case for asynchronous programming. In principle yes, but in practice I disagree. Due to keep-alive you want to be able to handle many idle connections at the same time, but you rarely want to handle many active connections at the same time. Example: Whenever you talk to another services (e.g. a database) you need to limit the number of connections you have open. You can't just blindly open a new connection per incoming request. This means that your practical level by parallelism is often bounded by your database. If every request talks to Postgres and you have a connection pool with a limit of 50, then there is nothing to gain by having support for 1000s of "active" connections. You'd rather want Postgres to focus on finishing existing requests than opening new ones. And once you look into Postgres you'll observe the same thing: There's only limited amount of CPU/IO so there's no point in having 1000s of "active" requests going on at the same time.

sanxiyn 6y ago

You may want async if you are writing the next nginx, but for most web application servers threading is perfectly fine.

Xorlev 6y ago
Again, depends on if you're doing a lot of IO, especially if you want request-based IO parallelism. It's worth mentioning that even if you're IO-bound at your DB, running an async application server now means you don't need to tie up a thread waiting on it. Memory usage aside, you more or less don't need to think about threads much, whereas a threadpool (one waiting on IO) is something you have to actively manage.
deleted 6y ago
[deleted]
maccam94 6y ago
But nginx is usually just a proxy for connecting to app servers, and your app servers still need to handle all of those requests.
mycoliza 6y ago
Rust is intended as a systems programming language, it's for people who are writing "the next nginx". It turns out that there are also a bunch of people who want to write webapp servers in Rust, too, but that's never really been the goal.
- sanxiyn 6y ago
  Eh, so Rust is not for me? I seem to have heard Rust being inclusive and empowering everyone blah blah. I must have misheard.
  - hombre_fatal 6y ago
    It's clear this is one of your hobby horses. Every comment thread here is encumbered with you pointing out that you wouldn't like it if async were the default, fair enough. In fact, you don't seem to like the idea in general. ctrl-f "sanxiyn" yields 28 instances, most of them restating in every subtree the same point about how you think threads > async. Since I think most of us tend to read the comments section top to bottom, it seems ideal to limit your opinion to a couple comments and then put your effort into making those comments a good rundown of your position. It would certainly be more interesting to read and consider.
    - ldng 6y ago
      He's multi-threading ! (Sorry could not help myself :-D)
    - sanxiyn 6y ago
      You may want to contribute something concrete. I did learn some new advantages of async over threading from replies, besides tired C10K. Yes, async is useful for C10K. No, I am not solving C10K problem. 1. If you use async in single thread mode, you can save thread synchronization. 2. async works better for idle connections and slow connections, even when the absolute number of connections is not large. 3. async task is easier to cancel than thread. I still won't use async since thread synchronization hasn't been slow for me, thread cancellation hasn't been problematic for me, and I use nginx to handle idle connections and slow connections, but it's useful to know in case I need.

judofyr 6y ago

> Web servers are all about I/O and handling small tasks (requests), and are a perfect use case for asynchronous programming. In principle yes, but in practice I disagree. Due to keep-alive you want to be able to handle many idle connections at the same time, but you rarely want to handle many active connections at the same time. Example: Whenever you talk to another services (e.g. a database) you need to limit the number of connections you have open. You can't just blindly open a new connection per incoming request. This means that your practical level by parallelism is often bounded by your database. If every request talks to Postgres and you have a connection pool with a limit of 50, then there is nothing to gain by having support for 1000s of "active" connections. You'd rather want Postgres to focus on finishing existing requests than opening new ones. And once you look into Postgres you'll observe the same thing: There's only limited amount of CPU/IO so there's no point in having 1000s of "active" requests going on at the same time.