Hacker News new | ask | show | jobs
by tempworkac 572 days ago
interestingly, my takeaway from this article is that Nodejs isn't actually as slow as I thought. I thought Rust would be at least two orders of magnitude faster. It's barely just one, for the OPs benchmark.

how can it be possible that nodejs is so fast, or that rust isn't multiple orders of magnitude faster (again, for the OPs benchmark it's about 8-10x faster in one case, and only twice as faster in another, which is much faster, but I expected it to be more like 100x faster).

is v8 really that fast? I'd be curious to see a multi threaded version of this implemented (some arbitrary multi-threaded benchmark). there I would hope that rust is multiple orders of magnitude faster, given that node is single threaded (with some caveats, of course as anyone who knows node knows). surely the rust written wasn't written optimally.

given how easy it is to write typescript compared to Rust and Python imho, maybe the JS community isn't as crazy as I thought

5 comments

With a JIT, you can examine what's actually running and compile on the fly a static portion and then execute that.

A downside is that you don't have as much time as time spent compiling is not spent actually doing the work. And I think typically for these dynamic languages, you still need some guard code at the edges to make sure the types you see are consistent with the compiled portion.

But there's the upside that you can observe runtime behaviour which is much more difficult to get into an ahead-of-time compiler. For instance, you might be able to JIT into a regexp engine executing a particular regexp.

> I'd be curious to see a multi threaded version

Some charts

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Some numbers -- Node.js versus Rust

(the underlines show links to program source code)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Nodejs/js runtimes in general get a lot of development effort to make the runtimes fast from Google et al. It's the default web language so there's a ton of effort put into optimizing the runtime. Python on the other hand is mostly a hacker/data science language that interops well with c, so there's not much incentive to make the base runtime fast. The rare times a company cares about python interpreter speed, they've built their own runtime for python instead.
> given how easy it is to write typescript compared to Rust and Python imho, maybe the JS community isn't as crazy as I thought

Speed and easiness of writing aren’t the only two metrics that matter. Unless you subscribe to “move fast and break things”, I guess. Simplicity of packaging/distribution/embedding, artifact size, reliability and trustworthiness of the ecosystem, pre-distribution correctness checks… All of those are important to consider.

It's also that running a benchmark by wrapping it in a shell script and invoking "date" externally adds a constant offset to all timings. It's negligible if the benchmark itself takes long enough, but not when you go down to 0.25s or even 0.06s.
And it's not like we can't find programming language benchmark comparisons that do better than that:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/