3 ms·
> Are you a working web developer? If so, can you give a concrete example of a web application you've worked on that required multithreading on the web server?
by bluefishinit 3y ago
> Are you a working web developer? If so, can you give a concrete example of a web application you've worked on that required multithreading on the web server?
Yep, I'm a working (and successful) developer who has built a lot of different types of programs, often web servers.
A concrete multi-threaded example would be a web server that federates to Mastodon (which is quite noisy and benefits from having the "bridge" be in its own long running thread(s)). Really anything with long running processes that aren't keyed off of ux events is best done with multiple threads.
- lolinder 3y agoFair enough. If you're working on something like that, absolutely go with a different server than TypeScript! But it's still weird to insist that TypeScript has no valid applications when long-running processes that aren't direct responses to users are the exception and not the norm. When I've run into specific cases in TypeScript projects that require that, I've tended to just spin up a new long-running service for those requirements.
- bluefishinit 3y ago> When I've run into specific cases in TypeScript projects that require that, I've tended to just spin up a new long-running service for those requirements. But then you're not sharing memory and have to rely on message passing... it's all doable of course, but this is just one of many examples where the language will hold you back.
- lolinder 3y agoYes, you're not sharing, but the deployment requirements are usually quite different for services like that, which makes them better as standalone services regardless of implementation language. For one thing, you usually don't want to run multiple copies of long-running daemon-type services, where for your application servers redundancy is good to have no matter what language you're using.