Hacker News Reader

Hacker News

Comment by woah | Hacker News Reader

Parent Full thread

woah

Here are the classes of bugs: http://www.viva64.com/en/examples/

I'm no expert, but it looks like most of these would be caught by the Rust compiler at the time they were typed in.

View on HN

Yes. That's why they don't like rust: http://www.viva64.com/en/b/0324/

That ... is pretty jarring. Their arguments boil down to:

a) No one wants to use a "minor" language, so it will never get traction

b) It's slow (citation: the Benchmarks Game)

c) Static and dynamic analysis can find anything anyways, so what's the point?

First off, anyone who is seriously citing the Benchmarks Game as to making a definitive declaration of whether a language is slow or fast is intellectually dishonest. It's a game (as its name illustrates), so it reflects more the effort that people put in to try to optimize code rather than a comparison of "idiomatic" code. A case in point: the fastest program in C uses SSE intrinsics for its implementation.

Given that they're selling a static analyzer, I would expect them to make the case for analysis. However, it's worth addressing the limitations. Almost no project has 100% test coverage, and even having test coverage isn't necessarily a cure for having no problems (IOC still found undefined overflows in SQLite, which is the only open source project I know of to have 100% line and branch coverage in their test suite). To my knowledge, there still exists no tools that can identify strict-aliasing violations or ODR violations. It's also worth minding Dijkstra's aphorism: testing cannot prove the absence of bugs, only their presence. Static analysis in C/C++ has to face the additional problem of the inability to write a precise pointer analysis--something that Rust's type-safety would fix.

> First off, anyone who is seriously citing the Benchmarks Game as to making a definitive declaration of whether a language is slow or fast is intellectually dishonest.

But Rust is actually significantly slower than C++, that's for sure. You're welcome to test it by yourself.

  >  You're welcome to test it by yourself.

If this is true, please file bugs. They're treated as such.

A Rust k-nucleotide program based on std::collections::hash_map would be welcome.

Edit (2017-02-09):

Here are Rust k-nucleotide programs -

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

I don't know the history here, but

https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...

https://github.com/TeXitoi/benchmarksgame-rs/issues/34 (though some things have changed since these comments...)

k_nucleotide.rs implements it's own hash table, and that is no longer accepted: k-nucleotide programs that do that have been removed.

Hence --

    k-nucleotide
	
    source 	secs 	KB 	gz 	cpu 	cpu load
  	    No program 	contribute your program

http://benchmarksgame.alioth.debian.org/u64q/rust.html

What about languages that do not include their own hash tables? C is allowed to, but Rust is not?

No, the C programs are not allowed to implement their own hash table -- and as a consequence no C k-nucleotide program was shown for a couple of months.

http://benchmarksgame.alioth.debian.org/u64q/knucleotide-des...

Rust std::collections provides hash table implementations, it's just a matter of using them.

  > some use a third-party hash table library.

This is what I'm getting at. Since C doesn't provide a built-in hash table, they get to choose one that's good on this benchmark, but other languages can't. That's not great.

(I actually have no idea if the std::collections hashmap is deficient in some way, I care about this in the abstract, not specifically.)

No, they don't "get to choose one that's good on this benchmark".

They get to use a third-party library that was not invented for this benchmark -- that would be the point!

> It's a game (as its name illustrates) <

As a matter of intellectual honesty -- 'The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money.'

http://benchmarksgame.alioth.debian.org/sometimes-people-jus...

See also this thread https://news.ycombinator.com/item?id=12262251

Reply on news.ycombinator.com