Hacker News new | past | comments | ask | show | jobs | submit login

The article very clearly calls out the data structure difference.

Your statement that they simply are "chalking this up to language differences" is false. It's not surprising that you received a negative reaction.




Despite the author’s claim that they are not trying to make a comparison, and their lengthy discussion on the details why such a comparison is not apt, we still ended up with a title that suggests a comparison and comments that focus on the two languages in relation to each other.


That is a fair point. The title may be a bit misleading.

Although, not entirely, as I'm sure you would agree we can't claim that different data structure is the only reason that the rust program was fast.


Which is exactly why it's a terrible benchmark -- it doesn't tell you anything about what you care about. Which is one reason why it's a terrible article.

Another reason is that the author seems to have put a lot more engineering into the Rust program than the C program. Most of the word-count of the article is devoted to extra engineering on the Rust program! (The whole thing about sorting out lumps, etc). It's reasonable to infer that this also mirrors the situation prior to the first benchmark. If you put more effort into optimizing one program than another, you'd expect the higher-effort program to be faster, all else being equal.

It's embarrassing that HN thinks this article is worth posting. There might be something to write about here, somewhere, but it would have to be framed in a very different way in order to be honest. Also, it would be a much shorter article.


The author appears to disagree with your assessment in the previous article that is linked at the start:

Because I had written my Rust naively (and my C carefully), my hope was that the Rust would be no more than 20% slower — but I was braced for pretty much anything. ... my naive Rust was ~32% faster than my carefully implemented C.


I don't think the author was claiming that this is a rigorous benchmark, but I can see how it might look that way. I agree that it could have been framed a bit better, but I also don't think the author was trying to make any bold declarations.

The technical aspects of the article are interesting and well written, but only if it is not viewed as an exercise in rigorous benchmarking.

The context here was that the Rust program was a reimplementation of an existing C program, as part of an effort to learn Rust.


Unfortunately, that's not entirely accurate. The problem with language level benchmarking is that the benchmarks are only as good as their implementations and while I agree that different languages encourage different kinds of idioms it seems only fair to use the same data structure/technique when the language offers that choice (as Rust does with intrusive data structures).

The Rust program was not a faithful reimplementation as the author concedes. I expected a more closer comparison given the somewhat broad title of the article. Claiming the perf benefit came out of the thinking encouraged by the language is okay but debatable.


Can you think ofa simple, unambiguous, descriptive title?

How about — Why Rust BTreeMaps beat C AVL Trees ?

I don't know if that would be an adequate title, but it doesn't claim that different data structure is the only reason and it doesn't generalize to a claim about C and Rust.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: