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

211–220 of 379 posts

Re: Rust vs C Pitfalls

#211

Post by EugeneOZ »

adrianN wrote: post #200
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…

I'm currently trying to learn Rust, but if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast (especially compared to something like Ruby!), the ecosystem is huge and tooling is extremely mature.

Java has not so great reputation about safety.

Re: Rust vs C Pitfalls

#212

Post by EugeneOZ »

voidlogic wrote: post #3
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…

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…

Rust is not more complex, it just takes some more time to get used to.

Re: Rust vs C Pitfalls

#213

Post by eridius »

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 best thing here for Rust would be to achieve the best performance on this game and nothing else.

That's absurd. The benchmarks game doesn't measure real-world performance in any sense whatsoever. And many of the implementations are written in ways that you'd never ever put into production code (for example, the laughably bad hashing functions that are mentioned elsewhere in this thread). From what I understand, the Rust implementations tend to not get up to those shenanigans, which makes them appear worse than the implementations from other languages that do.

It's not the goal of a programming language to be the top on a silly benchmarks game. The goal is to be an excellent language for real-world use.

Re: Rust vs C Pitfalls

#214

Post by eridius »

pvg wrote: post #84
simcop2387 wrote: post #77

Earlier quoted context omitted.

I think he's talking about the C code here, right at the top http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

If that's the one it's a custom hash function which is then inlined as a macro. That still seems like a pretty vanilla C optimization that one might write in real C code.

The problem isn't that it's a macro. It's that it's a horrifically bad hash function. It's blazing fast, but completely unsuitable for use in any real code.

Re: Rust vs C Pitfalls

#215

Post by neandrake »

keldaris wrote: post #23
sidlls wrote: post #13

The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Rust has other features that make it generally superior in certain (many) contexts. The safety is a nice "add-on" effect, I suppose, but my view is that constantly hyping safety as the biggest selling point is missing a mark.

I completely agree. The biggest reason I haven't seriously tried Rust yet is because, despite all the vocal pro-Rust opinions we've all been inundated lately, I struggle to name a single interesting thing about the language apart from "safety". I wish the Rust evangelists would come to terms with the fact that to many developers memory safety is not a particularly important concern (for many different and often very…

I've not seen it mentioned here (unless included under generic "safety"), but prevention of data races in concurrent code seems like a big thing for Rust. Most examples of Rust being "safe" compared to C are usually about buffer overflows use-after-free, but elimination of data races to me seems like a huge win in its own right. I'm primarily a Java developer and a lot of the practices I'm learning from Rust apply to how I think about implementations in regular work, such as aliasing and mutability.

Re: Rust vs C Pitfalls

#216

Post by duneroadrunner »

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…

While you're checking out the performance of Rust and Go benchmark implementations, you can also check out some SaferCPlusPlus benchmarks[1] (and kind of compare them with other languages (transitively via the C++ benchmaks)). I've already suggested that these days a "memory safe" implementation category for the benchmarks would be of interest. But apparently not to the current maintainer of the benchmarks. Anyone else out there got nothing better to do than maintain a benchmark site for memory safe implementations? :)

[1] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

Re: Rust vs C Pitfalls

#217

Post by copperx »

EugeneOZ wrote: post #211
adrianN wrote: post #200

Earlier quoted context omitted.

I'm currently trying to learn Rust, but if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast (especially compared to something like Ruby!), the ecosystem is huge and tooling is extremely mature.

Java has not so great reputation about safety.

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

Re: Rust vs C Pitfalls

#218

Post by 0xFFC »

cderwin wrote: post #169
pornel wrote: post #92

Earlier quoted context omitted.

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

I am no expert, but you should compile barebone executable for comparing executable size! not "hello world", because hello world does use shitload of library (for printing and loading and stuff), and those ones in C is compiled in dynamic, but in rust those compiled inot executable itself.

if I remember correctly you should compile with --nostd flag and provide _start function for loader to load your executable!

you can do same with rust too (But I think you should provide a special flag for compiler). You can find all of it on documentation.

Re: Rust vs C Pitfalls

#219

Post by enqk »

EugeneOZ wrote: post #211
adrianN wrote: post #200

Earlier quoted context omitted.

I'm currently trying to learn Rust, but if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast (especially compared to something like Ruby!), the ecosystem is huge and tooling is extremely mature.

Java has not so great reputation about safety.

That's interesting because it is based on the same principles of not letting developers do harmful thing as a way to guarantee security.

Re: Rust vs C Pitfalls

#220

Post by neoasterisk »

lobster_johnson wrote: post #147
euyyn wrote: post #137

Earlier quoted context omitted.

What's a good example of it?

I don't want to single out anyone or any specific projects, so this is going to be a generalization, but since you asked: In my experience, there's a lot of hostility and arrogance. More than in any other community, I've seen Go developers shut down discussion by closing comment threads on Github; reject pull requests and refuse to debate the merits of the change; castigate people for "not following proper procedure"…

> the official Go Slack channel

This is very misleading. There is no official Go slack channel. The slack channel you are referring is just a slack channel and is by no means official.

> In particular, Go developers, more than other cultures, seem to get an ego boost out of telling people "no".

This is misleading as well. Go was designed from the start to exclude certain features e.g. inheritance and many others. There are usually very good reasons for those decisions that people who've been following Go from its creation know and understand very well.

Now what happens when someone who does not understand those design choices comes to Go? They want their favorite feature obviously! When Go members attempt to explain them why something like that does not exist in Go (and probably will never be included) it starts feeling like "no". And people do not take "no" well. They get emotional and fail to see reason. If they had bothered to explore the language or at least read the official documentation and FAQ, that state of mind might have been avoided.

Including everyone's favorite feature does not make a language better.

Go has created a community around a certain school of programming. Nobody claims that it is better than other schools but it is a fact that it exists. But who is the one that is close-minded in this case? The new person that doesn't bother with the teachings of the school or the school that dismisses the ideas of the new person? Who is really the one that says "no"?

From my experience, the Go developers always carefully consider every new idea that is brought to the table. But it is also a fact that after the 10th time you've seen the same idea, you are not going to sit down and spend time considering it. You are just gonna link a previous discussion and say "Sorry this has been brought up before, please check these". How does that feel to a new person? I bet it feels like "no" again.

Post reply on HN