3 ms·

Today (but not in 2002) if i needed a server with 100k concurrent activities, I'd look to async frameworks - futures/ callbacks but a small number of threads. A

Today (but not in 2002) if i needed a server with 100k concurrent activities, I'd look to async frameworks - futures/ callbacks but a small number of threads. Akka, reactive streams, etc. Is a huge number of threads as useful today as 2002?

inglor 3y ago
If you could easily spin up hundreds of thousands of threads you wouldn't need any of those frameworks, callbacks or userland threads. You could use the OS level abstraction and not have your language/framework implement its own different abstraction.
gorjusborg 3y ago
There is a certain amount of Stockholm syndrome built into the current acceptance of async programming paradigms. Linear code is far easier to reason about, but that is easy to forget once someone has become accostomed to thinking in async constructs. The thing is, there are only so many things a person can mentally juggle. Removing the consideration of a whole dimension of issues means the developer can take on more useful complexity.
- ttfkam 3y ago
  Naive threads and async are for fundamentally different tasks: Threads are for working in parallel, splitting a single compute-intensive tasks into many. Async is for waiting in parallel for disk I/O results, database queries, network responses, etc. The former are for doing more work. The latter is for efficiently waiting for others to do their work without using a bunch of excess thread context resources. You don't reduce complexity by ignoring the difference between two quite distinct use cases. That's false simplicity.
  - hu3 3y ago
    The point is you don't need native threads. You can use lightweight (green) threads. So if a green thread is waiting for I/O, another can use the CPU just fine. Yes there's context switching but it does scale and code becomes simpler to write and reason about.
  - fiedzia 3y ago
    > without using a bunch of excess thread context resources If the threads are cheap, there is no point in making this distinction, which greatly simplifies the language. And they can be, we just need programming languages designed for that.
    - ttfkam 3y ago
      Some people, when confronted with a problem, think, “I know, I’ll use threads,” and then two they hav erpoblesms. – Ned Batchelder
    - ttfkam 3y ago
      Non-blocking I/O channels use fewer threads (native or green) than tasks. Some programming languages ARE designed to handle this: they use async/await. You could argue that Go does this more elegantly with goroutines, but this further highlights the point that threads should not be a silver bullet to development models.
    - the_biot 3y ago
      Here, here. The elephant in the room in just about any discussion about threads/async is Python. Threads simply don't function in Python because of the GIL. Instead of accepting this fact and using another language if threads are needed, Python has been doing various async-style things for years and pretending it's good enough, including what can only be described as cooperative multitasking, that horror from the early 90s.
      - fiedzia 3y ago
        Python is working on removing GIL (I am not sure about timeframe) and will have subinterpreters - the last one will come in 3.13 and solves the thread problem.
hu3 3y ago
If I can make good use of hardware without resorting to async programming, I would prefer to. Green threads allow that. For starters, debugging async stacktraces is a nightmare in many languages/runtimes. There's also the cognitive load that async programming adds to humans. And there's function coloring. It tends to spread and "infect" the codebase. Also most languages have to duplicate their APIs to support both linear and async calls. And then there's driver support. In languages I have seen, async support came with the requirement of specialized or at least adapted drivers.

inglor 3y ago

If you could easily spin up hundreds of thousands of threads you wouldn't need any of those frameworks, callbacks or userland threads. You could use the OS level abstraction and not have your language/framework implement its own different abstraction.

gorjusborg 3y ago

There is a certain amount of Stockholm syndrome built into the current acceptance of async programming paradigms. Linear code is far easier to reason about, but that is easy to forget once someone has become accostomed to thinking in async constructs. The thing is, there are only so many things a person can mentally juggle. Removing the consideration of a whole dimension of issues means the developer can take on more useful complexity.

ttfkam 3y ago
Naive threads and async are for fundamentally different tasks: Threads are for working in parallel, splitting a single compute-intensive tasks into many. Async is for waiting in parallel for disk I/O results, database queries, network responses, etc. The former are for doing more work. The latter is for efficiently waiting for others to do their work without using a bunch of excess thread context resources. You don't reduce complexity by ignoring the difference between two quite distinct use cases. That's false simplicity.
- hu3 3y ago
  The point is you don't need native threads. You can use lightweight (green) threads. So if a green thread is waiting for I/O, another can use the CPU just fine. Yes there's context switching but it does scale and code becomes simpler to write and reason about.
- fiedzia 3y ago
  > without using a bunch of excess thread context resources If the threads are cheap, there is no point in making this distinction, which greatly simplifies the language. And they can be, we just need programming languages designed for that.
  - ttfkam 3y ago
    Some people, when confronted with a problem, think, “I know, I’ll use threads,” and then two they hav erpoblesms. – Ned Batchelder
  - ttfkam 3y ago
    Non-blocking I/O channels use fewer threads (native or green) than tasks. Some programming languages ARE designed to handle this: they use async/await. You could argue that Go does this more elegantly with goroutines, but this further highlights the point that threads should not be a silver bullet to development models.
  - the_biot 3y ago
    Here, here. The elephant in the room in just about any discussion about threads/async is Python. Threads simply don't function in Python because of the GIL. Instead of accepting this fact and using another language if threads are needed, Python has been doing various async-style things for years and pretending it's good enough, including what can only be described as cooperative multitasking, that horror from the early 90s.
    - fiedzia 3y ago
      Python is working on removing GIL (I am not sure about timeframe) and will have subinterpreters - the last one will come in 3.13 and solves the thread problem.

hu3 3y ago

If I can make good use of hardware without resorting to async programming, I would prefer to. Green threads allow that. For starters, debugging async stacktraces is a nightmare in many languages/runtimes. There's also the cognitive load that async programming adds to humans. And there's function coloring. It tends to spread and "infect" the codebase. Also most languages have to duplicate their APIs to support both linear and async calls. And then there's driver support. In languages I have seen, async support came with the requirement of specialized or at least adapted drivers.