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

81–90 of 379 posts

Re: Rust vs C Pitfalls

#81

Post by lossolo »

steveklabnik wrote: post #79
lossolo wrote: post #76

Earlier quoted context omitted.

I told you NO unsafe code. Use only standard library, no third party tools. I have posted Go implementation to Rust magicians (it's just simple buffered reader, you do not need to be Go wizard to write it, any beginner can write it) and I've asked for Rust solution on Rust IRC channel because it was slower than easy Go solution, what I found out it's impossible to do it more efficient in Rust using standard library w…

Yes, and I was saying "even in production-grade, world-class grep implementation, there is barely any unsafe." I also acknowledged that that was different than what you were asking about. When did you ask on IRC? I'll take a look.

In past two weeks, I've posted c++ solution there. From what I remember It took around 3s for Go solution, 1.92s for C++ and ~4s for Rust. Rust was slow because you are UTF-8 input validating by default. Faster solutions were only those with unsafe keyword or using C.

Re: Rust vs C Pitfalls

#82

Post by dozzie »

empath75 wrote: post #36
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…

It's very rare that any programmer switches computer languages. You're probably going to retire as a c programmer. What are they going to teach in school? What are new systems programmers going to start with? I suspect it'll be rust and go, not c.

> It's very rare that any programmer switches computer languages.

Or is it?

I regularly use six different languages of three paradigms and various abstraction levels, and this doesn't count DSLs nor Turing-complete tools like make. Of my colleagues from current job, half of the more experienced set write in at least three languages as well. Of the team from my previous job, all of them are polyglots. And of course none of us started with all the languages, we picked them up as needed and wanted.

Re: Rust vs C Pitfalls

#83

Post by [deleted] »

lossolo wrote: post #81
steveklabnik wrote: post #79

Earlier quoted context omitted.

Yes, and I was saying "even in production-grade, world-class grep implementation, there is barely any unsafe." I also acknowledged that that was different than what you were asking about. When did you ask on IRC? I'll take a look.

In past two weeks, I've posted c++ solution there. From what I remember It took around 3s for Go solution, 1.92s for C++ and ~4s for Rust. Rust was slow because you are UTF-8 input validating by default. Faster solutions were only those with unsafe keyword or using C.

[deleted]

Re: Rust vs C Pitfalls

#84

Post by pvg »

simcop2387 wrote: post #77
pvg wrote: post #73

Earlier quoted context omitted.

Which ones do you have in mind? Preprocessor sounds a little cheaty but picking a hash function that's a better fit for the data is a pretty basic, practical sort of optimization.

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.

Re: Rust vs C Pitfalls

#85

Post by lossolo »

burntsushi wrote: post #80
lossolo wrote: post #76

Earlier quoted context omitted.

I told you NO unsafe code. Use only standard library, no third party tools. I have posted Go implementation to Rust magicians (it's just simple buffered reader, you do not need to be Go wizard to write it, any beginner can write it) and I've asked for Rust solution on Rust IRC channel because it was slower than easy Go solution, what I found out it's impossible to do it more efficient in Rust using standard library w…

None of the unsafe code that Steve linked to had anything to do with searching a file line by line. It has to do with other parts of ripgrep, like determining whether a tty is available or communicating with a Windows console to do coloring. (Hell, ripgrep doesn't even require memory maps, but they are faster in some cases.) Your benchmark proposal is interesting on the surface, but if done correctly, its speed will…

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 course this is only one example, but still a proof that what OP wrote is not valid in all cases.

Re: Rust vs C Pitfalls

#86

Post by burntsushi »

lossolo wrote: post #85
burntsushi wrote: post #80

Earlier quoted context omitted.

None of the unsafe code that Steve linked to had anything to do with searching a file line by line. It has to do with other parts of ripgrep, like determining whether a tty is available or communicating with a Windows console to do coloring. (Hell, ripgrep doesn't even require memory maps, but they are faster in some cases.) Your benchmark proposal is interesting on the surface, but if done correctly, its speed will…

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…

ripgrep is your proof. Go read the blog post Steve linked. If you still don't believe it, read the code. There's not that much of it.

Then compare it with similar tools written in Go, like sift and the platinum searcher.

The problem is, searching a file quickly is not as simple as you want to believe. If you show me a naive line by line approah, I'll show you an approach that is much faster but more complex. Top speed requires work, sometimes algorithmic work, regardless of the language you choose.

Re: Rust vs C Pitfalls

#87

Post by lossolo »

burntsushi wrote: post #86
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…

ripgrep is your proof. Go read the blog post Steve linked. If you still don't believe it, read the code. There's not that much of it. Then compare it with similar tools written in Go, like sift and the platinum searcher. The problem is, searching a file quickly is not as simple as you want to believe. If you show me a naive line by line approah, I'll show you an approach that is much faster but more complex. Top spee…

> 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 reason to fight with facts if we get bias out of the equation. In other cases? I don't know. What I would expect is that naive searching for one string in haystack to be faster than Go in a language that is performance/zero-cost abstractions oriented like Rust but its false in this case. But it doesn't mean it's false in every case. And to be honest writing that "but they have faster implementation in assembler" is not an excuse at all, you can also write your own, especially if it works so well for those languages that have custom asm for specific platforms. In the end average Joe will not care if it's hand written assembler, he will care that his naive solution using standard library without any magic is just faster.

Re: Rust vs C Pitfalls

#88

Post by pornel »

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…

I write libraries.

In Go I can only write libraries for Go programs. In Rust I can write libraries for any program.

i.e. Rust can easily produce static and dynamic libraries that are linkable with C programs and any language with a C FFI. I can write Rust code that works for programmers using C, C++, C#, D, Go, Swift, Python, PHP, Java, etc.

Re: Rust vs C Pitfalls

#89

Post by zerofan »

steveklabnik wrote: post #61
zerofan wrote: post #32

Earlier quoted context omitted.

To me it's almost the opposite. I like C a lot, but I ended up compromising on C++11 because in some programs I need more features to keep the implementation clean. I pay the cost of a messy language (C++) when implementing my libraries in order to have simpler applications that use those libraries. I've written C-like programs in Rust, and that goes very well. But I really like function overloading, generic operator…

How would you have gone about making Strings be "as comfortable as integers"? Arrays are indexed by usize, so if you're on a 64-bit machine, then you shouldn't need a cast. It's _unconstrained_ numbers that default to i32, not anything without a suffix.

> How would you have gone about making Strings be "as comfortable as integers"?

I would prefer a str be a str be a str, regardless of how you got it. Lowercase type-name and fundamental like an integer.

I'm fairly certain I understand why Rust made the choice they did. I've read the forum threads at HN, Reddit, and users.rust-lang, and I've seen previous replies by you and other Rusties, so I hope you won't try to educate me about the performance advantages of having slices as references and another string type as an ownership class or why we need OsStr and friends.

If strings are the fundamental processing concern in your application, then I think you should be able to opt-in to that kind of micro-optimization and complexity, but it would've been better to spare the rest of us who have different concerns. I don't want to become a string expert to build a filename, and the default implementation could (at least conceptually) be always on the heap for all I care. Go one step further and implement the "small string optimization" (Alexandrescu's fbstring), and you'd probably get back most of the performance without nearly the complexity.

> Arrays are indexed by usize

I've spent the last half hour trying to troubleshoot why this line hangs:

    let aa = vec![1u8; 10e9 as usize];
However, I'm at home using the Ubuntu under Windows thing, so maybe there's some bad mojo between Rust and my less than usual setup. (If you're interested, I have 32 Gigs of memory, and the equivalent C malloc and memset code runs just fine, so I don't think Rust is doing the right thing here...).

Anyways, I wanted to test the commented out line, but I'm stuck for now. If that line would work, I'll admit I was wrong, but I think the uncommented line shows a similar complaint.

    for ss in 0..63 {
        //print!("{}\n", aa[1
> It's _unconstrained_ numbers that default to i32, not anything without a suffix.

Looking at the present and the future, why is that a sensible default? Both x64 and ARM are going to use a 64 bit integer register for the operations, and many of those operations are going to be 1-clock throughput. You can probably find a counter example, but 32 bit integers aren't generally faster than 64 bit ones.

Re: Rust vs C Pitfalls

#90

Post by groovy2shoes »

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.

C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks.

Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds.

Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates.

Don't get me wrong. I like Rust and what the project is trying to do. But I see two major problems that are preventing me from using it for anything major at the moment: 1) the extremely rapid rate of change, and 2) difficulty of implementation (both of which, taken together, lead me to expect no serious alternative implementations any time soon).

Before I will be willing to adopt Rust as a C replacement in full, there needs to be a solid, stable language definition that compiler writers can target and programmers can rely on for a good chunk of time. I have a feeling we'll get there eventually once the number of new, useful features that are missing from the language starts to dwindle and it begins to stabilize naturally.

In the meantime, I'd settle for an "LTS" release or something. That could work.

Post reply on HN