Data Processing benchmark featuring Rust, Go, Swift, Zig, Julia etc.
github.com
github.com
There's also no control on quality of contributions to the language-specific benchmarks.
Though, granted in the case of re-running it you can do things like take the minimum or median time which are much better benchmark metrics, rather than the mean which is thrown off more by outliers and system noise.
Definitely bot trying to defend this as a good benchmarking scheme.
Rant: As with many benchmarks, this suffers from the fact that there are multiple ways to do the same thing in multiple languages, and the most common one isn't necessarily the best for a particular use case.
In an ideal world, you would have the benchmark in each language written by people that work with that language on daily basis and have all the necessary knowledge to produce a fair benchmark, which is something that a naive implementation often fails to do.
Not that JSON parsing isn't valid to measure, but it's not the most interesting thing to me given the large number of JSON parsers that exist in each language.
But regardless, from LTS aspect, Rust and Go maybe the way to go
Genuine question; I've never used it before.
Go and Rust are both hugely popular and definitely will be around for decades.
Julia? Debatable.
> From my experience with Julia (and I love Julia and have used it extensively at school!), the "time to first plot" thing is still a big problem.
This part is true - it has improved by an order of magnitude in recent versions and continues to, but time-to-first-X is still a tangible issue you have to deal with.
> You would never want to write shell scripts in Julia, mostly because it takes several seconds to get the interpreter running.
This part overstates the case - it takes less than half a second for the Julia runtime to start, even on my mediocre laptop. Which isn't nothing, to be sure, and maybe a non-starter for some use cases.
But generally, for shell script like programs, the time taken by the runtime (the "interpreter", though it's not really one) itself isn't much of an issue. The delays come in when your code needs to load big packages to do its thing, their loading times and other time-to-first costs. And you can mitigate that too, by putting the main part of your code in a precompiled package, and just calling out to that from your script.
All that is to say only that, in the past few years, Julia has gone from "you would never want to write shell scripts in Julia" to "it's mildly annoying that you have to consciously arrange your code in a certain way to avoid latencies, but it's doable and not too hard".
Measuring in seconds (though easy) is not really as useful as measuring in opcodes (with retirement times). Wrong audience perhaps.
> WIP - Excluded from chart until it's ready
C and Fortran are also missing, but considering the task, that's understandable.
It's in the repo if you want to take a look. I have very little experience with c++.
let top5 = Array(5).fill({
idx: 0,
count: 0,
});
...this kind of code is nice source of bugs in js.