Hacker News Reader

Comment by Capricorn2481 | Hacker News Reader

It's fine if you don't like JS, but it speaks to a bias or lack of experience if you think Zig is a better tool. Maybe it will be one day, but it's a flat out unfinished language with numerous bugs.

I was with you when you said command lines, but servers? JS is a fine choice for servers. I haven't seen Rust do anything on the server but slow people down, and I have found people who think they know Rust don't really

Plenty of people are productive in JS, and when working with ES6, it can even be comparable to immutable functional languages. It's on the team if they aren't reviewing code or are allowing bad habits.

View on HN

> 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.

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.

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.

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.

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.

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.

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.

> 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.

> 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.

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.

> 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.

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.

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

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.

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.

> 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.

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.

> As in compiled languages are usually low level languages that require some amount of memory management.

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".

That's why I brought up golang as an example of a GC language. It's a bigger success story for servers because a GC language is more appropriate

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

> I was with you when you said command lines, but servers? JS is a fine choice for servers.

This statement is the reason we're all having to use Electron applications.

The amount of tooling that you need to use to surround your JavaScript code to make it somewhat correct is insane.

You're using a dynamic language. There is literally a whole slew of bugs that you cannot detect until you actually run the code.

You do get those things with Rust.

Getting Rust (same like when I used F#) to compile is hard.

But claiming that that is the reason JavaScript is faster is actually a reflection of not understanding what this compilation does for you.

> But claiming that that is the reason JavaScript is faster is actually a reflection of not understanding what this compilation does for you.

I didn't even kind of say this. Rust is complicated for reasons beyond compilation. I actually like F# and strong type systems.

> The amount of tooling that you need to use to surround your JavaScript code to make it somewhat correct is insane.

There's no practical evidence of this, it's just a feeling you have. Big systems are built in dynamic languages fine.

> This statement is the reason we're all having to use Electron applications.

How is "JS is fine for servers" the reason you have to use Electron apps? Pick a topic. I am not overapplying JS

> You're using a dynamic language. There is literally a whole slew of bugs that you cannot detect until you actually run the code.

If you're using Rust, you're introducing a whole slew of bugs that you cannot detect unless you compile the code, and that you wouldn't run into in a GC language. And you're potentially doing it for no benefit because you don't understand servers aren't typically CPU bound.

Reply on news.ycombinator.com