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

151–160 of 379 posts

Re: Rust vs C Pitfalls

#151

Post by tines »

Manishearth wrote: post #146
gravypod wrote: post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

> If you're fighting, you've lost. I don't really get this attitude, it means that nothing new will ever overcome anything that's been established. > Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly p…

>> If you're fighting, you've lost.

> I don't really get this attitude, it means that nothing new will ever overcome anything that's been established.

I think he's trying to quote Dan Saks' "extern c: Talking to C Programmers about C++" when he said "If you're arguing, you've lost." Saks, at least, meant that if you're striving with someone, you've already lost because your partner is already in a "frame" of mind set against your arguments that is unbreakably strong, even by logic. The talk is really good just for that aspect.

Re: Rust vs C Pitfalls

#152

Post by lossolo »

caconym_ wrote: post #111
lossolo wrote: post #85

Earlier quoted context omitted.

The thing is I don't really care if Go implementation is highly optimized for amd64 like memchr is in C which is also written in assembler and optimized for different platforms. What I care is that simple code written by me is faster without going into C/unsafe code myself. So it's correct, fast, simple and I do not pay with my time to figure out how to make it as fast in Rust. This is the point I am making. Of cours…

> but still a proof that what OP wrote is not valid in all cases. You are not proving anything until you post your Go code, which you don't seem to have done (please correct me if I'm wrong, I am legitimately curious to see for myself how Go and Rust stack up against each other for this problem). Until then, all you're doing is making vague claims backed up by precisely zero evidence. Why should anyone take you serio…

I have posted the code in reply to burntsushi. You can check it out yourself.

Re: Rust vs C Pitfalls

#153

Post by Ericson2314 »

lacampbell wrote: post #6
gravypod wrote: post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

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

libc is very hard to use portably

Re: Rust vs C Pitfalls

#154

Post by burntsushi »

lossolo wrote: post #149
burntsushi wrote: post #109

Earlier quoted context omitted.

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

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.

Re: Rust vs C Pitfalls

#155

Post by sanderjd »

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…

It isn't a "moral" issue. It is about the usefulness of the benchmarks. If you're using them to make a recommendation about which programming language to choose, it is important to have a sense for how well the results generalize to the kind of programs you will be writing. Using unrealistic hacks targeted specifically to each benchmark is contra that goal.

If, on the other hand, you're just treating the benchmarks as a fun competition akin to code golf, then by all means, hacks ahoy!

Re: Rust vs C Pitfalls

#156

Post by colejohnson66 »

steveklabnik wrote: post #58
colejohnson66 wrote: post #42

Earlier quoted context omitted.

Depends on your Rust implementation. You can have an implementation without one and use it to make, say, an operating system.

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)

Re: Rust vs C Pitfalls

#157

Post by bluejekyll »

all2well wrote: post #113
gravypod wrote: post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

I mean by that logic, no progress is possible at all in programming languages, because at some point every language had worse tooling than the competition. I'd say the greatest part about Rust is the community, which realizes all of the issues you've listed, and especially the really tough learning curve for beginners. Generally, use the right tool for the job. I don't think I'd really want to use Rust in production…

> I don't think I'd really want to use Rust in production yet...

Why not out of curiosity? I've already been showing off to people at work how much shorter Rust code is than our corresponding Java, how much easier it is to build and deploy, and how much more stable it is.

Granted I've been using it at small micro service scale at the moment, but I see no reason not to go into production at the moment (well, except for the fact that I'm the only one that will be called at night if it fails... luckily it hasn't, and I'm not worried).

Re: Rust vs C Pitfalls

#158

Post by [deleted] »

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…

[deleted]

Re: Rust vs C Pitfalls

#159

Post by [deleted] »

lossolo wrote: post #149
burntsushi wrote: post #109

Earlier quoted context omitted.

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

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

[deleted]

Re: Rust vs C Pitfalls

#160

Post by Manishearth »

tines wrote: post #151
Manishearth wrote: post #146

Earlier quoted context omitted.

> If you're fighting, you've lost. I don't really get this attitude, it means that nothing new will ever overcome anything that's been established. > Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly p…

>> If you're fighting, you've lost. > I don't really get this attitude, it means that nothing new will ever overcome anything that's been established. I think he's trying to quote Dan Saks' "extern c: Talking to C Programmers about C++" when he said "If you're arguing , you've lost." Saks, at least, meant that if you're striving with someone, you've already lost because your partner is already in a "frame" of mind se…

Ah, I see. Yeah. I read that post more as a demonstration than a "fighting".

But that's a valid point.

Post reply on HN