Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust vs C Pitfalls

garin.io

Post reply on HN
Print view View original

341–350 of 379 posts

Re: Rust vs C Pitfalls

#341

Post by igouy »

steveklabnik wrote: post #323
igouy wrote: post #316

Earlier quoted context omitted.

To be clear: anyone can contribute a Rust k-nucleotide program that uses a custom hash function, just like those used by other programming languages.

Wasn't there some issues around a "custom library" for this? I distinctly remember there being some kind of argument about what is legal and what isn't. That is, I think I'm thinking of this: > k-nucleotide will explicitly require built-in / library HashMap. https://alioth.debian.org/tracker/?func=detail&group_id=1008... Since C doesn't have a standard library hashmap, you can write an entirely custom one just for th…

To be clear: anyone can contribute a Rust k-nucleotide program that uses a custom hash function, just like those used by other programming languages.

> Since C doesn't have a standard library hashmap, you can write an entirely custom one just for the benchmark.

NOT TRUE!

#315195 states the opposite!

"k-nucleotide will explicitly require built-in / library HashMap"

Re: Rust vs C Pitfalls

#342

Post by steveklabnik »

igouy wrote: post #334
steveklabnik wrote: post #310

Earlier quoted context omitted.

You're making an assumption that the C code is allowed to have the same algorithm as the Rust code. This is not actually exactly true, based on the rules of the game.

Where is it forbidden for programs written in C to use FNV? For example https://github.com/haipome/fnv/blob/master/fnv.c

I'm referring to my reply to you above about not being able to implement a different map, not the hash function itself.

Re: Rust vs C Pitfalls

#343

Post by steveklabnik »

igouy wrote: post #341
steveklabnik wrote: post #323

Earlier quoted context omitted.

Wasn't there some issues around a "custom library" for this? I distinctly remember there being some kind of argument about what is legal and what isn't. That is, I think I'm thinking of this: > k-nucleotide will explicitly require built-in / library HashMap. https://alioth.debian.org/tracker/?func=detail&group_id=1008... Since C doesn't have a standard library hashmap, you can write an entirely custom one just for th…

To be clear: anyone can contribute a Rust k-nucleotide program that uses a custom hash function, just like those used by other programming languages. > Since C doesn't have a standard library hashmap, you can write an entirely custom one just for the benchmark. NOT TRUE! #315195 states the opposite! "k-nucleotide will explicitly require built-in / library HashMap "

The "library" distinction you're drawing here is arbitrary. Or at least, my understanding of it is.

Am I allowed to use a custom HashMap for the game, or am I required to use the one in std::collections? My understanding is that it's the latter, and so that penalizes Rust or any other language that includes a map in their standard library.

Re: Rust vs C Pitfalls

#344

Post by igouy »

steveklabnik wrote: post #343
igouy wrote: post #341

Earlier quoted context omitted.

To be clear: anyone can contribute a Rust k-nucleotide program that uses a custom hash function, just like those used by other programming languages. > Since C doesn't have a standard library hashmap, you can write an entirely custom one just for the benchmark. NOT TRUE! #315195 states the opposite! "k-nucleotide will explicitly require built-in / library HashMap "

The "library" distinction you're drawing here is arbitrary. Or at least, my understanding of it is. Am I allowed to use a custom HashMap for the game, or am I required to use the one in std::collections? My understanding is that it's the latter, and so that penalizes Rust or any other language that includes a map in their standard library.

Just like everyone else Rust advocates can contribute programs that use a custom Hash function with a library Hash map.

In fact, the current Rust k-nucleotide DOES use a custom Hash function with a library Hash map.

No one is allowed to -- in your words -- "write an entirely custom [hashmap] just for the benchmark".

(This was all discussed to death, in early December on https://www.reddit.com/r/rust/ ).

Re: Rust vs C Pitfalls

#345

Post by mmstick »

groovy2shoes wrote: post #257
mmstick wrote: post #193

Earlier quoted context omitted.

The problem with your concept is that C does not offer an official standard library and compiler suite, so you're trying to compare the C spec to the Rust standard library + compiler. The actual Rust API has changed very little since the 1.0 release. All the changes that have occurred have been mere additions to the language -- nothing breaking. Hence why the 1.0 release was termed as a 1.0 release. There won't be an…

C does have a standard library. It's described in full in the ANSI/ISO/IEC standard for the C programming language, and it's on your system, likely called libc or something along those lines. Anyway, I don't think that's a problem with my concept at all. What I want for Rust, and what I think will eventually be feasible for Rust as the language matures, is a standard that can be shared by compiler writers and Rust pr…

> C does have a standard library. It's described in full in the ANSI/ISO/IEC standard for the C programming language, and it's on your system, likely called libc or something along those lines.

What you're describing is the spec and not the implementation. An implementation would be glibc (GNU Libc with open source proprietary extensions) and musl (MIT implementation that strictly adheres to spec). These libraries are updated often.

Meanwhile, Rust offers more than just a specification. It offers an implementation. This is libcore-rust + libstd-rust. This is what receives updates each 6 weeks. It also offers a compiler that comes with it, rustc, which is also what receives updates each 6 weeks.

Rust strictly adheres to semantic versioning, so changes to the API are not allowed without a major version bump. Code that was written for Rust 1.0 will still compile on Rust 1.15. Code written for Rust 1.15 may not compile for a Rust 1.0 compiler though because bumping the second version implies adding new features. Rust doesn't yet utilize a patch version though. There's never been any critical issues discovered in each stable release.

> Frankly, I don't see wide adoption happening in the corporate world until there's an LTS compiler at the very least.

Can't say that I understand why a LTS compiler would be required for adoption. Many in the corporate world are already using Rust, either publicly as an official friend of Rust or privately in smaller projects. There's nothing a LTS compiler would provide that would be beneficial to the corporate world. Semantic versioning and the ease of managing Rust toolchains with rustup has everything pretty well covered.

Re: Rust vs C Pitfalls

#346

Post by steveklabnik »

igouy wrote: post #344
steveklabnik wrote: post #343

Earlier quoted context omitted.

The "library" distinction you're drawing here is arbitrary. Or at least, my understanding of it is. Am I allowed to use a custom HashMap for the game, or am I required to use the one in std::collections? My understanding is that it's the latter, and so that penalizes Rust or any other language that includes a map in their standard library.

Just like everyone else Rust advocates can contribute programs that use a custom Hash function with a library Hash map. In fact, the current Rust k-nucleotide DOES use a custom Hash function with a library Hash map. No one is allowed to -- in your words -- "write an entirely custom [hashmap] just for the benchmark". (This was all discussed to death, in early December on https://www.reddit.com/r/rust/ ).

You didn't answer my question. Does "library" here mean that you are able to use a hashmap other than the one in std::collections, or not?

Re: Rust vs C Pitfalls

#347

Post by igouy »

hamilyon2 wrote: post #313
dispose13432 wrote: post #22

Earlier quoted context omitted.

>On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)). It's true that rust is a new language, but so is Go. [1]: I assume it's because it's a test of GC, but…

This site explicitly mentions that results of benchmarks mean almost nothing. Google published results that tell that golang is slower than java in real applications

> This site explicitly mentions that results of benchmarks mean almost nothing.

Quote?

Re: Rust vs C Pitfalls

#348

Post by igouy »

merb wrote: post #33
dispose13432 wrote: post #22

Earlier quoted context omitted.

>On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)). It's true that rust is a new language, but so is Go. [1]: I assume it's because it's a test of GC, but…

yeah of course, doing simple programs and checking their time is a good benchmark... oh wait.. also real world performance in bigger programs is mostly different, especially when you deal with big heaps. Btw. this site is extremly bad for benchmarks since it also measure's the startup time of the runtime in java/go/rust.

> startup time

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

Re: Rust vs C Pitfalls

#349

Post by mmstick »

blub wrote: post #269
groovy2shoes wrote: post #257

Earlier quoted context omitted.

C does have a standard library. It's described in full in the ANSI/ISO/IEC standard for the C programming language, and it's on your system, likely called libc or something along those lines. Anyway, I don't think that's a problem with my concept at all. What I want for Rust, and what I think will eventually be feasible for Rust as the language matures, is a standard that can be shared by compiler writers and Rust pr…

When Rust (or Swift or golang) gets ISO standardized we'll know that it's mature and left the "move fast and break things" phase. This won't happen, because it's still growing now, so it doesn't make sense to standardize. They might even always want to be able to move fast. I don't see golang ever being standardized. The fact that someone says on HN "we're backwards compatible" doesn't quite offer the same level of t…

> The fact that someone says on HN "we're backwards compatible" doesn't quite offer the same level of trust as an ISO standard.

Then you shouldn't take the word of a random person but from the Semantic Versioning guidelines. If you're not following the semantic versioning guidelines then you're doing it wrong.

http://semver.org/

> Especially when there are some conflicting reports out there i.e. there are many super-awesome libraries that only work with nightly (I think it's called), because many of those maintainers are early adopters that love to try out new features.

Totally irrelevant. Very few libraries, if any, require a nightly compiler. The libraries that do offer features that require a nightly compiler have those features as optional. Anyway, once the new Macros update releases, the need for that nightly compiler will go away. These libraries are just taking advantage of compiler plugins.

Re: Rust vs C Pitfalls

#350

Post by Manishearth »

mmstick wrote: post #339
Manishearth wrote: post #321

Earlier quoted context omitted.

No, the default integer is u32. If type inference can't provide a better type, Rust will pick u32. If type inference can pick a better type it will use it. So if you create an unsuffixed int literal and use it for indexing, that literal will be a usize. Rust will type error if you try to use u32s with an array so it's all good though. Just means that you need to specifically `: usize` things. If you need an integer t…

That makes sense. I've never noticed what the default size was, but because it always worked with indexing, I assumed that it was always usize.

I believe it used to be uint (usize) back in pre-1.0, and IIRC inference didn't work well or wasn't supposed to work at all. I recall needing explicit prefixes on my int literals back then. No longer the case.
Post reply on HN