Hacker News new | ask | show | jobs
by qweqwe14 452 days ago
The fact that it's faster than the C implementation that surely had more time and effort put into it doesn't look good for C here.
3 comments

C++ surpassed C performance decades ago. While C still has some lingering cachet from its history of being “fast”, most software engineers have not worked at a time when it was actually true. C has never been that amenable to scalable optimization, due mostly to very limited abstractions and compile-time codegen.
I think you'll find that if you re-write an application, feature-for-feature, without changing its language, the re-written version will be faster.
This is known as the Second System Effect: where Great Rewrites always succeed in making a more performant thing.
I am not sure if the semantics have drifted over the decades to what you say, but this seems not quite right according to wikipedia: https://en.wikipedia.org/wiki/Second-system_effect

EDIT: but I do agree that starting greenfield from an old code base is often a path towards performance.

Just having a laugh, mate, but it is nice to have the truth posted as well.
It says absolutely nothing about the programming language though.
Doesn’t it say something if Rust programmers routinely feel more comfortable making aggressive optimizations and have more time to do so? We maintain code for longer than the time taken to write the first version and not having to pay as much ongoing overhead cost is worth something.
How can it not? Experts in C taking longer to make a slower and less safe implementation than experts in Rust? It's not conclusive but it most certainly says something about the language.
> Experts in C taking longer to make a slower and less safe implementation than experts in Rust?

How do you know this exactly?