Right... but using virtual threads I got 1,000,000 (in a second or two...) and likely for fraction of the memory. And I can even get many millions without a problem.
I agree that for a low volume typical CRUD-only server that never bursts above a few dozen requests per second that's not an issue.
Messaging is one special "rare" case.
Imagine a messaging channel in Slack/Discord/Telegram/WhatsApp-type app, where there's thousands of participants (say 10,000) in one channel. 1 person posts a message...
9,999 messages are generated (one to for each of the other participants). One might say, that can be handled with a few machines...
Now imagine a person posts something super interesting to the channel where 100 people respond with an emoji reaction almost instantly.
Now you have 100 * 9999 = 999,900 (!) messages, all within a few seconds! And this is for just one message _reaction_. Each one of those messages likely involves multiple steps of IO (sending/receiving data over the socket, writing to one or multiple databases...). So a thread might be blocked for hundreds of milliseconds at various times, which would ultimately likely require 100-1000x more servers to operate as scale increases.
The thing is that you _can_ write a program efficiently using regular threads by using asynchronous techniques. Another name for such style of programming is _callback hell_ :) . And when something does go wrong, it is a lot harder to debug.
I agree that for a low volume typical CRUD-only server that never bursts above a few dozen requests per second that's not an issue.
Messaging is one special "rare" case.
Imagine a messaging channel in Slack/Discord/Telegram/WhatsApp-type app, where there's thousands of participants (say 10,000) in one channel. 1 person posts a message...
9,999 messages are generated (one to for each of the other participants). One might say, that can be handled with a few machines...
Now imagine a person posts something super interesting to the channel where 100 people respond with an emoji reaction almost instantly.
Now you have 100 * 9999 = 999,900 (!) messages, all within a few seconds! And this is for just one message _reaction_. Each one of those messages likely involves multiple steps of IO (sending/receiving data over the socket, writing to one or multiple databases...). So a thread might be blocked for hundreds of milliseconds at various times, which would ultimately likely require 100-1000x more servers to operate as scale increases.
The thing is that you _can_ write a program efficiently using regular threads by using asynchronous techniques. Another name for such style of programming is _callback hell_ :) . And when something does go wrong, it is a lot harder to debug.