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.
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.
> 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.
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.
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.
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.
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.
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.
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.
Compiled GC languages? Maybe. There's a reason Go is exploding, even though it's type system actually sucks.
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.
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.
That's not true of any of the languages I've listed. You may not like the borrow checker, but it's not manual memory management. Also, Go has a garbage collector you don't manually manage memory there. I don't think any of these languages would be considered "low level".
But no, just because Rust has a borrow checker doesn't mean you aren't manually managing memory. It just means there are guard rails for it and the way you do it is different. Here's the gut check, does Go not allow me to use a variable because it's location has already been freed? That's what automatic memory management looks like. Not only does Rust not have that, it's even more complicated than c++ RAII in some places