4 ms·

> I was with you when you said command lines, but servers? JS is a fine choice for servers. I disagree. JS is single threaded. Sure there are some hacks to kin

> I was with you when you said command lines, but servers? JS is a fine choice for servers. I disagree. JS is single threaded. Sure there are some hacks to kinda, sorta get around that, but it's the nature of the language. Tying yourself to a single thread or dancing around that is an unnecessary restriction that compiled languages aren't going to have. JS is designed for web pages, not servers and not apps.

brokenbyclouds 3y ago
The single threading isn't an issue for many backend use cases and even though JS was initially designed for use in the browser, there's been a decade of development on the language and ecosystem for using it outside the browser.
- crdrost 3y ago
  Also people routinely use other single threaded things for the web, notably Python and Ruby have global interpreter locks and PHP has also usually been multithreaded only by being multi-process (you have to add pthreads on I think?). Multithreading is a nice to have; it has a bunch of costs around needing to introduce locking and synchronization primitives into the language, those costs aren't the worst thing ever but it's often nice to not have to deal with them.
  - zelphirkalt 3y ago
    I think you are mixing up lots of stuff or at least write about them in a misleading way. Python has async, has green threads, and has OS threads through the multiprocessing module. The fact that it has the GIL does not mean, that it cannot use OS threads or multiple processes. JavaScript in comparison does not have multithreading. NodeJS itself is multithreaded, but you cannot put application computation on those threads. You will need to use worker-threads and basically like PHP run multiple instances. However, neither of those languages is particularly nice for using the multiple cores available in modern machines anyway.
lolinder 3y ago
In actual practice a single thread is a non-issue. Web applications are almost never CPU bound, wait times are almost always a function of IO—database queries and requests to external services. JavaScript's async IO is plenty fast for any typical web use case, and the marginal savings you might get from having a few fewer servers will be more than made up for by the time your team of web developers (who already know JavaScript) wasted learning Rust or Zig.
dns_snek 3y ago
The fact that JS is single threaded doesn't make it any less useful as a web server. It seems like you're evaluating languages based on runtime performance and some made-up arbitrary metric that JS fails to meet, while completely ignoring the ecosystem that makes shipping projects possible in the first place. Zig looks promising, but the ecosystem isn't mature yet. Suggesting that Zig can replace a production-grade server based on Express.js today is.. madness.
- bluefishinit 3y ago
  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.
Capricorn2481 3y ago
So then Python, Ruby, and PHP are also bad for servers?
- bluefishinit 3y ago
  In my controversial opinion: yes they're bad for servers. Not just because they're single threaded but because they're interpreted and have dated tooling. Compiled languages have reached a DX level that I see no reason to use something interpreted in 2023 unless you really are building a web page and need to use js in the browser.
  - Capricorn2481 3y ago
    Because compiled languages tend to introduce a class of errors that are hard to deal with and offers no benefit for IO bound applications. Compiled GC languages? Maybe. There's a reason Go is exploding, even though it's type system actually sucks.
    - bluefishinit 3y ago
      > Because compiled languages tend to introduce a class of errors that are hard to deal with I've actually never heard this before, can you elaborate? Typically it's expected that the compiler will give you better errors than what you get if your app crashes at runtime.
      - Capricorn2481 3y ago
        As in compiled languages are usually low level languages that require some amount of memory management. So in C++, I have to worry about integer overflow. In Rust, I have to worry about how I return a variable or where a variable can still be used. In JavaScript, I return whatever I want and the garbage collector handles it. Slower, but perfectly fine when my servers main job is waiting. Using Rust instead is not just "better errors," it's more potential for errors. If CPU cycles aren't important for my app, why not just use Typescript? Rust is not just "JavaScript but with better errors," it's targeting a completely different use case. If you want a fast, multi threaded language with a good type system, you can do it without Rust. C# is extremely fast, and in some use cases, faster than Rust.

brokenbyclouds 3y ago

The single threading isn't an issue for many backend use cases and even though JS was initially designed for use in the browser, there's been a decade of development on the language and ecosystem for using it outside the browser.

crdrost 3y ago
Also people routinely use other single threaded things for the web, notably Python and Ruby have global interpreter locks and PHP has also usually been multithreaded only by being multi-process (you have to add pthreads on I think?). Multithreading is a nice to have; it has a bunch of costs around needing to introduce locking and synchronization primitives into the language, those costs aren't the worst thing ever but it's often nice to not have to deal with them.
- zelphirkalt 3y ago
  I think you are mixing up lots of stuff or at least write about them in a misleading way. Python has async, has green threads, and has OS threads through the multiprocessing module. The fact that it has the GIL does not mean, that it cannot use OS threads or multiple processes. JavaScript in comparison does not have multithreading. NodeJS itself is multithreaded, but you cannot put application computation on those threads. You will need to use worker-threads and basically like PHP run multiple instances. However, neither of those languages is particularly nice for using the multiple cores available in modern machines anyway.

lolinder 3y ago

In actual practice a single thread is a non-issue. Web applications are almost never CPU bound, wait times are almost always a function of IO—database queries and requests to external services. JavaScript's async IO is plenty fast for any typical web use case, and the marginal savings you might get from having a few fewer servers will be more than made up for by the time your team of web developers (who already know JavaScript) wasted learning Rust or Zig.

dns_snek 3y ago

The fact that JS is single threaded doesn't make it any less useful as a web server. It seems like you're evaluating languages based on runtime performance and some made-up arbitrary metric that JS fails to meet, while completely ignoring the ecosystem that makes shipping projects possible in the first place. Zig looks promising, but the ecosystem isn't mature yet. Suggesting that Zig can replace a production-grade server based on Express.js today is.. madness.

bluefishinit 3y ago
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.

Capricorn2481 3y ago

So then Python, Ruby, and PHP are also bad for servers?

bluefishinit 3y ago
In my controversial opinion: yes they're bad for servers. Not just because they're single threaded but because they're interpreted and have dated tooling. Compiled languages have reached a DX level that I see no reason to use something interpreted in 2023 unless you really are building a web page and need to use js in the browser.
- Capricorn2481 3y ago
  Because compiled languages tend to introduce a class of errors that are hard to deal with and offers no benefit for IO bound applications. Compiled GC languages? Maybe. There's a reason Go is exploding, even though it's type system actually sucks.
  - bluefishinit 3y ago
    > Because compiled languages tend to introduce a class of errors that are hard to deal with I've actually never heard this before, can you elaborate? Typically it's expected that the compiler will give you better errors than what you get if your app crashes at runtime.
    - Capricorn2481 3y ago
      As in compiled languages are usually low level languages that require some amount of memory management. So in C++, I have to worry about integer overflow. In Rust, I have to worry about how I return a variable or where a variable can still be used. In JavaScript, I return whatever I want and the garbage collector handles it. Slower, but perfectly fine when my servers main job is waiting. Using Rust instead is not just "better errors," it's more potential for errors. If CPU cycles aren't important for my app, why not just use Typescript? Rust is not just "JavaScript but with better errors," it's targeting a completely different use case. If you want a fast, multi threaded language with a good type system, you can do it without Rust. C# is extremely fast, and in some use cases, faster than Rust.