3 ms·

Lack of threads is just one example of how JS is hobbled. You don't always need multi-threaded programming but there are times you do! I've also noticed that de

Lack of threads is just one example of how JS is hobbled. You don't always need multi-threaded programming but there are times you do! I've also noticed that devs that understand how to do multi-threaded programming are the most proficient. > completely ignoring the ecosystem that makes shipping projects possible in the first place. There are so many bad js libraries out there, more than any other language I've ever seen. There's no special sauce in the JS ecosystem, there's tons of libraries available for any modern language (not Zig, I included that as it probably will get there). There's nothing you can do in JS that you can't also do in Go and the quality of the library your using is going to be much higher than whatever's on NPM.

lolinder 3y ago
> You don't always need multi-threaded programming but there are times you do! 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? I've needed it client-side to avoid freezing the UI with heavy computations, but in all my years working on server-side code (in PHP, Java, Ruby, JavaScript, and Python) I have never wanted to manually create a new thread on the server, even in Java where I could have! > I've also noticed that devs that understand how to do multi-threaded programming are the most proficient. Knowing how to do multi-threaded is different from insisting on using a language that supports multi-threading on a project that will never require multi-threading. I've noticed that devs that understand their project requirements and don't engineer for problems that the project will never face are the most proficient.
- 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 ago
    Fair 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 ago
        Yes, 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.

lolinder 3y ago

> You don't always need multi-threaded programming but there are times you do! 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? I've needed it client-side to avoid freezing the UI with heavy computations, but in all my years working on server-side code (in PHP, Java, Ruby, JavaScript, and Python) I have never wanted to manually create a new thread on the server, even in Java where I could have! > I've also noticed that devs that understand how to do multi-threaded programming are the most proficient. Knowing how to do multi-threaded is different from insisting on using a language that supports multi-threading on a project that will never require multi-threading. I've noticed that devs that understand their project requirements and don't engineer for problems that the project will never face are the most proficient.

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 ago
  Fair 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 ago
      Yes, 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.