Hacker News Reader

Comment by PaulHoule | Hacker News Reader

It's completely wrong that performance doesn't matter for the server side, in fact it's the complete opposite.

Javascript is a fine language for client-side software because the client is paying for it (and the client's computer, tablet or phone is running idle most of the time anyway)

Firms that run web services pay dearly to run their servers on the cloud, expect to run at a high utilization fraction, and if they ran their infrastructure on a slow language like Ruby they would be paying cloud bills 10x what they'd get for infrastructure written in Go.

The people who make the decision are paying the bills and that means they make a very different decision.

View on HN

I wouldn't lump JavaScript / Node.js with the other interpreted languages. While it may look similar on the surface, JS has an advantage over most other languages: It's used in browsers, and as such, there's an arms race between 4 very large companies to make their browser the fastest, resulting in enormous amounts of effort being made in making JS faster.

While it's never going to match compiled languages like C or Go, it's definitely the fastest interpreted language out there; I've seen studies putting it in the same order of magnitude as C (i.e it's 2x slower, not 10x). Moreover, its concurrency model (callbacks / event handlers) makes it uniquely suited to handle IO-bound workloads easily, which is 99% of the web nowadays (getting a request, sending a query to the database, and sending the reponse back).

That’s only relevant for browser side JS, though. V8 has a monopoly on server side JS. It’s quite slow on its own, but the bloat that people pile on top of it makes it even slower. And V8 is definitely not “the fastest” interpreted language - I have found that LuaJIT performs much better for my scripting needs.

> And V8 is definitely not “the fastest” interpreted language - I have found that LuaJIT performs much better for my needs.

According to a 2021 performance test¹, Lua with LuaJIT is slower than JavaScript with V8. Note that the "quite slow" JavaScript running on V8 is nearly as fast as Java.

¹ https://eklausmeier.goip.de/blog/2021/07-13-performance-comp...

Yeah, but V8 is Chrome's engine, which _is_ in competition for fastest engine against Safari, Firefox & Edge (although Edge isn't much of a competitor anymore).

The event loop is the original sin of node.js.. I feel like you either fight the broken concurrency model at every step, or you slip beneath the waves. The fact that languages like erlang have been around forever makes it a real slap in the face.

I don't know erlang, but honestly it's much easier to grasp / easier to avoid footguns with callbacks than threads. The main "issue" is callback pyramids when you have a lot of dependent callbacks, but that's solved relatively easily with Promises, and even easier with async / await.

It's not a binary choice between runloop with callbacks or threads, that's why you should probably take the time to learn about Erlangs actor model implementation, which Dart's Isolates also implement to some degree.

> Moreover, its concurrency model

JS is a single-threaded language, there is no concurrency

I generally agree and for one welcome our systems-language-based-backend overlords in the form of robust Rust and Crystal-based web frameworks (Go I dislike for other reasons, but its heart is in the right place).

That said, I've had to eat my words recently on this -- serverless compute is just so damn easy to use and scale, it almost doesn't matter how inefficient the language you're running on it is as long as there are good ways of optimizing around cold starts (i.e. pre-warming), etc.. General efficiency of the backend language mattered a lot more when we had long-running web servers where memory leaks and stability issues would rear their heads inevitably after the server has been running for a few days. With serverless, these things almost no longer matter, because every micro VM is so short lived, there is no opportunity for these types of issues to arise. When it comes to raw performance, scripting languages _are_ sufficient if all you're doing is CRUD, in which case the main bottleneck is going to be your database anyway, especially if you are using a robust ORM like ActiveRecord which heavily optimizes the server side portion of this.

At Arist (YC S20) we are using Ruby on Jets in production, and it's quite efficient. We have a ~0.996 Appdex score, pages load typically within ~80-150ms, and many of our pages are server side rendered. I also operate a personal project that uses a Rust-based web framework. If I run this project on a raw EBS cluster (instead of serverless), I can get pages to load from the server in as quick as 20-40ms, but my point is that the difference visually is usually imperceptible -- 110ms is fast enough 99% of the time. When you factor in the fact that scripting languages, and in particular, Ruby, has significantly higher productivity than some of the systems languages, it becomes pretty obvious why a lot of startups stick with scripting languages.

All of that said, bring on the good and robust Rust and crystal web frameworks!!!

This is just not the case for a vast majority of businesses. It doesnt matter if you are using Ruby or Go or ASM if you write N+1 SQL queries all over the place.

Similarly, caching is universal and is the answer to nearly all API issues. Raw compute is such a non-factor in a significant portion of use-cases.

What car do you use to go to the supermarket? An F1 car? A truck? A sedan?

JavaScript is totally fine for serving thousands of reqs per second. In many cases the bottleneck will be third party APIs or the DB. The cost of running that will be negligible.

If you have hundreds of thousands (or millions) of reqs per second, then of course cost can become an important factor. But at that stage you probably have the resources to build whatever you want with the best possible language for the use case.

I don't think it's unfair to say that 1 man-hour equates to many machine-hours (in terms of dollar cost). Then in terms of per-core performance, modern JavaScript runtimes are nearly competitive with Go and per-core performance is ultimately what matters at scale since you'll load-balance between cores or VMs to saturate your compute.

Per-core performance is one thing, realized performance on today's multi-core machines is something else.

I have been writing back ends in Java and C# for more than a decade and it is widespread for people to take advantage of multi-core systems in two ways if they can: (1) threads sharing data structures such as system configuration and caches (e.g. it is no problem to have 10 or 100 megabytes of configuration data for a Java-based system) and (2) using Executors to split up tasks into smaller pieces and running them concurrently.

In Node.js, Python, and other GIL languages you can't do the above and slow down from "configuration at the speed of RAM" to "parsing configuration over and over again", "configuration at the speed of the database", etc.

I see people using Node.js for build systems but I think it's still an unusual choice (like Python) for a back end for a commercial system.

I'm not disagreeing with you but I am curious: what's the effective difference for most people (concerning perf and utilization) between multicore support in Java and Go and just running multiple processes in Node (edit: let's just ignore Python to make this simpler) ?

> what's the effective difference for most people (concerning perf and utilization) between multicore support in Java and Go and just running multiple processes in Node

The perf difference here probably isn't that great (although Java/Go will likely still be faster), but if you're at the point of running multiple processes you may well find that it's less dev effort to write your code in Java/Go (assuming you are familiar with both).

Yes I agree, it's always been simpler for me to operate Go apps rather than Node ones (but also because of memory usage in callback- and streaming-heavy JavaScript).

Multi-process in node.js web serving is doable but operationally more of a pain. The cluster module will let you spawn a bunch of processes all sharing the same listening port, but sharing caches, connection pools, etc become much more difficult. If some aspect is particularly CPU-bound you can use web workers, but for run-of-the-mill web requests I'm not sure it's worth it.

Processes eat more resources, and even taking them out of the equation, dynamic language runtimes have less opportunities for good JIT code optimization, at the same level as languages like Java and Go type systems allow for.

In regards to Node, as Python is anyway mostly CPython 99% of the deployments.

A fixed process pool of 1 process per core is truly overall more resource intensive than a goroutine per request model in Go?

It would kind of seem like a wash to me, naively.

Because you're missing the picture that a goroutine doesn't use the stack size, heap from OS data structures, or CPU context switches into kernel code, as a full blown process.

Let alone the detail that the goroutine is full blown native code, while the node/Python process is interpreted, and even if a JIT is used, many C2 level optimisations are out of reach for dynamic languages.

It is no wonder that even with the herculean effort that has gone into V8, for the ultimate performance it needs help from GPU shaders and WebAssembly, both typed.

I will extend this question to things like fargate

For most firms that run web services, developer time (the engineers’ salary) is 10x or 100x the cloud bills.

They'll choose Ruby over C++ any day for purely financial reasons (obviously there are more consideration, but if it had been only about money).

So you are saying no scripted language is appropriate for the server? As far as I know, JS is extremely optimized and has no issues holding its own against Python.

I recently compared the performance of a node vs rust server

Js has many tricks up its sleeve that cant be underestimated

Reply on news.ycombinator.com