Ever wonder how quickly different programming languages can handle massive workloads? We tested one billion nested loops to find out. Zig, Rust, and C blazed through in about half a second—lightning fast! Fortran, Odin, and Dart followed closely, while Java, Kotlin, and C# landed comfortably in the middle. But when we got to Python, Ruby, and R, it took a few seconds—or even more. The difference? Compiled languages excel at raw speed, while interpreted ones trade some performance for flexibility and ease of use. Which would you pick? #coding #programming #learning #jobs #classess

YouTube

A detailed test of a billion nested loop operations reveals that Zig, Rust, and C are the fastest programming languages, completing in about half a second. Fortran, Odin, and Dart also perform well, though slightly slower. Java, Kotlin, and C sit in the middle, while Python, Ruby, and R take much longer, showcasing the speed advantage of compiled languages over interpreted ones.

Which Programming Languages Are the Fastest? | 1 Billion Loops: Which Language Wins?

“Pure language speed” benchmarks have a tendency to being ignored by the overall developer community. While we always rely on some amount of libraries to do the job for us (and that’s where the benchmarking mostly takes place), you should at least be aware of the pure language speed, so you have a complete image.
I did a language benchmark once that relied on Nilakantha time series to calculate the value of Pi with the given number of digits. Just to see how fast different languages are at math and control instructions. While I didn’t test all the languages mentioned in the video (only C/C++, Rust, Java, JavaScript/Node.js, Python), the results were pretty similar with C/C++, Rust leading the pack, Java being the next one, JavaScript being quite close to Java (but slower) and Python seriously lagging behind (all languages took below or around 1 second, while Python took 26 seconds).
That being said, you should really be careful making benchmarks like this, e.g. I really needed to use the calculated value (outputing it at least), so that the compilers don’t optimize away all the calculcations (resulting in an empty program) - the return value was not used, so the call was optimized away (C/C++ did that mostly). Of course this was nothing near a professional benchmark, as I just did it out of curiosity. :)