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

161–170 of 379 posts

Re: Rust vs C Pitfalls

#161

Post by steveklabnik »

fungos wrote: post #125
steveklabnik wrote: post #78

Earlier quoted context omitted.

Rust can do custom hashes as well, to be clear. There's been some arguments over what hashes are allowed in the game in the past.

If it compiles and run it is allowed. There is no rule to benchmark other than having the same end result with best performance. I still can't get all the moral over this. The best thing here for Rust would be to achieve the best performance on this game and nothing else. To me this game is important and winning on it is more yet. So, if Rust don't have better result by "morals" this is so wrong that hurts. But each…

The Benchmarks Game has more rules than that. It's not about "morals."

Re: Rust vs C Pitfalls

#162

Post by lossolo »

burntsushi wrote: post #154
lossolo wrote: post #149

Earlier quoted context omitted.

I have different times for both naive solutions on my machine than you. It's 2.6 seconds for Go and 3.5 seconds for Rust, both perf results and code here: http://pastebin.com/WwhvHH6S

Your Rust program corresponds to my second Rust program. Your Go program is not what I would expect. A bufio.Scanner is the idiomatic (and naive) way to read lines in Go. But this is immaterial. Your results are consistent with mine. They aren't different. I just included more analysis and more programs to provide proper context to this challenge of yours.

I gave you naive solution, now lets see amateurish solution (someone totally new to both languages)

Rust 4.6s

Go 3.1s

http://pastebin.com/r6K22Dt2

EDIT:

Using grep 0.6s

Then I have installed rigrep and...

Using ripgrep 0.4s

Really nice burntsushi. I am surprised by those (ripgrep) results compared to grep.

Re: Rust vs C Pitfalls

#163

Post by smitherfield »

To play the devil's advocate a bit, most of these are features you already get with C++, especially if you turn on all relevant warnings and treat them as errors. I can see the advantage of having things (sorta, given "unsafe") statically guaranteed for a shared codebase, but what are some compelling reasons to switch for personal projects?

Re: Rust vs C Pitfalls

#164

Post by steveklabnik »

lobster_johnson wrote: post #148
steveklabnik wrote: post #60

Earlier quoted context omitted.

Thank you! Carol and I are working on the second edition, you can read what we have so far here: http://rust-lang.github.io/book/ (I think it's even better, but I'm biased)

I believe I reported this once, but it's still there: You're hijacking alt-cmd-left/right, which I use for switching tabs in Safari. Your arrow-key event handler needs to have a guard: !(event.ctrlKey || event.shiftKey || event.altKey || event.metaKey) (Thanks for writing great documentation, though.)

Yeah I'm not sure mdbook has patched it yet. I'll make sure a ticket is filed tomorrow, I thought we did, but am not sure. Even if we did, well, that's open source.

Re: Rust vs C Pitfalls

#165

Post by steveklabnik »

copine wrote: post #104
steveklabnik wrote: post #102

Earlier quoted context omitted.

Thanks! If you do check it out, don't hesitate to file issues.

How far along is the new documentation? Would it be better to read https://doc.rust-lang.org/book/ or the github.io page? Maybe both?

Both would be ideal, if you have the time. The new book is far enough along that you can learn the most basic stuff from it, and the intermediate bits are coming along. The more advanced stuff is only an outline. So if you start with new, and then switch to old, you'll get the best of both.

Re: Rust vs C Pitfalls

#166

Post by michaelmior »

> “Safe” code is guaranteed to be 100% safe. Not statistically safe. Not safe when the compiler feels like it. As long as your code compiles, it will be safe in terms of memory safety and data-race freedom.

As far as I am aware, the Rust compiler has not been proved correct. So whether or not your code is correct still depends on the correctness of the compiler. Of course this is probably correct, but still not 100% guaranteed.

Edit: Relevant discussion - https://github.com/rust-lang/rust/issues/9883

Re: Rust vs C Pitfalls

#167

Post by degurechaff »

burntsushi wrote: post #109
lossolo wrote: post #87

Earlier quoted context omitted.

> If you show me a naive line by line approah, I'll show you an approach that is much faster but more complex. Of course, I did it myself many times. But this is NOT the point, I've already wrote it. The point is that I wrote naive approach in both languages and it's a lot faster in Go. Which is a reply to what OP wrote (don't forget where this discussion started). In this case this is the fact and I don't see any re…

> The point is that I wrote naive approach in both languages and it's a lot faster in Go. I tried your challenge, and the first data point I uncovered contradicts this. Here is the source code of both programs: https://gist.github.com/anonymous/f01fc324ba8cccd690551caa43... --- The Rust program doesn't use unsafe, doesn't explicitly use C code, is shorter than the Go program, faster in terms of CPU time and uses less…

woah, amazing comment. I usually just a silent reader on hacker news, but this comment urge me to create an account. I think lossolo just want a flamewar. He already has opinion which you cannot easly change. So any futher discussion after this comment will be pointless.

EDIT: and how can you have time to write this? I just usually close the browser tab when this situation occurs...

Re: Rust vs C Pitfalls

#168

Post by Animats »

dispose13432 wrote: post #22
voidlogic wrote: post #3

Earlier quoted context omitted.

On similar note, why Rust over Go? If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for. For the stuff where having a GC and slightly less control is OK, I don't see why I would want to use Rust. Rust is just much more complex and I prefer to keep it simple stupid (KISS). Basically, Go is good for 90% of what I used to use Java for and 80% of wha…

>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…

The binary trees benchmark forks off a large number of threads. Those are OS threads in Rust, and that is probably an inefficient way to compute something if you have more threads than CPUs.

Re: Rust vs C Pitfalls

#169

Post by cderwin »

pornel wrote: post #92
lacampbell wrote: post #6

Earlier quoted context omitted.

C is a very small and very portable language. Rust is not. I wondering why people bother comparing them at all.

Because Rust is IMHO the first viable replacement for C. Well-written C programs translate almost 1:1 to Rust. It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime. Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningf…

On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat.

Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wins by a lot.

Relevant blog post: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

Re: Rust vs C Pitfalls

#170

Post by TheDong »

colejohnson66 wrote: post #156
steveklabnik wrote: post #58

Earlier quoted context omitted.

There is only one implementation of Rust, and it does not have tracing GC. The language does not include semantics for one, so it would be an extension of the language.

Right. I had that backwards. (I don't program Rust)

> I don't program Rust

If you don't know anything about rust, you shouldn't respond to a question about rust.

Post reply on HN