> It wouldn't help if you moved your JavaScript to Python or Ruby or PHP...
Hum, no. The point is exactly that it would help a great deal if you moved to Python or Ruby or PHP.
Of course, Rust will give you even better memory efficiency. But Javascript is a particularly bad option there, and almost anything else would be an improvement. ("Almost", because if you push it enough and move to something like MathLab, you'll get worse results.)
If moving from JS to CPython would help, it might help memory consumption, because JITs generally trade speed for increased memory. But then you'd get slower execution, because CPython is slower than the JS engines we tend to use. PyPy might generally track JS on performance (big, BIG "it depends" because the speed profile of JITs are crazy complicated, one of my least favorite things about them) but then you're back to trading memory for speed, so it's probably net-net a sideways move.
Also, I don't know what Node is doing exactly, but if you take a lot of these dynamic languages and just fork them into multiple processes, which they still largely need to do to effectively use all the CPUs, you will generally see high per-process memory consumption just like Node. Any memory page that has a reference counter in it that is used by your code ends up Copied-On-Write in practice by every process in the steady state because all you need to do to end up copying the page is looking at any one reference it happens to contain in such a language. At least in my experience memory sharing gains were always minimal to effectively zero in such cases.
> But then you'd get slower execution, because CPython is slower than the JS engines we tend to use
I have not found this to be generally true. It depends heavily on whether your code is limited by pure high level language code[1] and culture makes comparisons harder if you’re not just switching languages but also abstraction models and a big stack of optimizations. In theory Java beats Python but in practice I’ve seen multiple times where a Java program was replaced by Python seeing whole number multiple improvements in performance and reductions in memory consumption because what was really happening is that a bunch of super complicated, optimization-resistant Java framework code was being replaced with much simpler code which was easier to optimize. Node is closer to that side of Java culturally, I think in both cases because people reacted to the limited language functionality by building tons of abstractions which are still there even after the languages improved so even though it’s possible to do much better a lot of programmers are still pushing around a lot of code with 2000s-era workarounds buried in the middle.
1. I’m thinking of someone I saw spend months trying to beat Python in Go and eking out a 10% edge because the bulk of the work devolved to stdlib C code.
I cite CPython specifically as CPython both to indicate that I mean that specific interpreter, and that I mean Python code, not Python driving other languages.
While I fully believe that a Python program with a superior O()-complexity class can beat Java (or, indeed, any language), and that a simpler Python program can hypothetically beat a Java program that is just too complicated, it would also be the case that taking that faster Python program and then porting that into Java would then see order of magnitude+ speed increases. Python is slow. When comparing languages I generally add the caveat "with some non-zero and comparable amount of time dedicated to optimization" to try to build a reasonable comparison, because most programs that have had no effort done on optimization at all will have their performance dominated by something stupid that the programmer didn't even realize they wrote.
The speed increases aren't relevant if the old Java was "too slow" and the new Python is "fast enough". Every program I've ever written could be made faster... but they're all fast enough now.
Pure Python with some non-trivial optimization effort can not beat a Java program with some non-trivial optimization effort, and that's before the Java code starts using multiple CPUs, if the problem is amenable to that.
This is not cheerleading, dumping on Python, or promoting Java, as if anything my personal biases are in fact the other way (tbh I don't particularly like either at this point but I'd much rather be using Python). This is just engineering stuff that good engineers should know: https://jerf.org/iri/post/2024/not_about_python/
I’m not saying that Java or even V8 shouldn’t be able to beat Python but rather that in many cases the optimizations needed to beat it are to a first approximation saying “stop using Spring/NextJS/etc.” and never happen. The gap between potential and actual speed has been quite frustrating to see expanding over the years.
"This Post Is Not About Python" seems to say the fans are acting irrationally by letting their political brain take over. Failure to calmly evaluate the downsides of their favorite options because they see them as attacks on the target of their fandom is a mistake that only hurts them. I think this understates the fans' case. When they see criticism of their favorite platform as an attack, it is because it is an attack in the war over network effects. Losing this war doesn't just deprive your platform of the benefits of popularity; it actively harms it by diverting shared resources.
I'll quote "Technology Holy Wars are Coordination Problems": [1]
> The enduring phenomenon of holy wars in computing, such as the bitterness around the prolonged Python 2 to Python 3 migration, is not due to mere pettiness or love of conflict, but because they are a coordination problem: the problem is not getting everyone to make a good decision, but making the same decision.
I agree that you can make better software engineering decisions if you avoid thinking like a fan and that a poor choice of language can hinder a project from the start. In light of what is at stake, though, "engineers should never be fans" is an unrealistic call for peace. It reminds me of this dialogue: [2]
> There’s a passage in the Principia Discordia where Malaclypse complains to the Goddess about the evils of human society. “Everyone is hurting each other, the planet is rampant with injustices, whole societies plunder groups of their own people, mothers imprison sons, children perish while brothers war.”
> The Goddess answers: “What is the matter with that, if it’s what you want to do?”
It depends, of course, on what you're doing. Re-using the toy web API in the article, I expect Python would be significantly faster. The QR code library you'd end up using in Python is probably written in C, and the web-serving portion should have comparable performance characteristics as you'd get with nodejs.
My guess is that if you were to rewrite this same app in straight Python (no Rust at all), it would probably already give you "Tier 3" performance.
But sure, I bet there are a bunch of use cases where nodejs would be faster than Python.
This seems a bit unfair to JavaScript. There’s a lot of optimizations made to the language and its runtimes that have made a more than viable choice for server side applications over the years. The JavaScript that started as a Webbrowser client side language is very different from the ECMAScript that we have today. Depending on its usage it can also be one of the fastest, only regularly eclipsed by rust[1]. So no, JavaScript really isn’t a bad option for server side applications at all.
Hum, no. The point is exactly that it would help a great deal if you moved to Python or Ruby or PHP.
Of course, Rust will give you even better memory efficiency. But Javascript is a particularly bad option there, and almost anything else would be an improvement. ("Almost", because if you push it enough and move to something like MathLab, you'll get worse results.)