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

71–80 of 379 posts

Re: Rust vs C Pitfalls

#71

Post by steveklabnik »

lossolo wrote: post #67
mmstick wrote: post #31

Earlier quoted context omitted.

I was writing software in Go for a year before I switched to Rust. I've not felt a need to touch Go since. Basically, anything you can do in Go, you can also do in Rust, but Rust will let you do it with higher efficiency and with significantly less lines of code. In the end, it's just easier to write software with Rust than it is Go. Feature-wise, Rust features generics and functional programming via higher-order fun…

> Basically, anything you can do in Go, you can also do in Rust, but Rust will let you do it with higher efficiency and with significantly less lines of code. Then i challenge you. Read 5 GB text file, line by line and search for one string that occur lets say 200k times and count how many times it occurs in file without going into C or using unsafe keyword in Rust, do it as you say more efficient than in Go (faster…

http://blog.burntsushi.net/ripgrep/

There are only seven instances of unsafe: https://github.com/BurntSushi/ripgrep/search?q=unsafe&type=C...

Four of them are related to calling libc/kernel32 functions, which need unsafe to be called. One is due to using a memory map, which needs unsafe to be called. Only two are actual unsafe rust functions.

That's a "real-world" example though, you're asking for a more specific implementation. I can't compare because my Go would be very poor; if you posted a Go implementation, I'd be willing to give this a shot and write a Rust one.

(Mostly out of personal interest, I don't think it really proves anything larger about the two languages.)

Re: Rust vs C Pitfalls

#72

Post by steveklabnik »

gravypod wrote: post #66
mmstick wrote: post #55

Earlier quoted context omitted.

Rust's had great IDE support for more than a year now. - There's Atom with Tokamak, which you must also install racer and clippy via cargo to get rapid in-line linting. - Then there's Visual Studio Code with RustyCode which you can also integrate with racer and clippy, that provides faster code completion and hovering over items will show a tooltip that documents that items. - Some people like IntelliJ Rust, but I've…

I've still not been able to get Rust to work with work in IntellJ or Eclipse. I've not tried Atom but that doesn't support "Projects" or "Solutions" in the way I'd like. From what I understand there is no "go" button.

Have you tried https://intellij-rust.github.io/ and http://rustdt.github.io/ ? If they don't work, I'm sure their maintainers would appreciate bug reports.

Re: Rust vs C Pitfalls

#73

Post by pvg »

mmstick wrote: post #38
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 is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmark…

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.

Re: Rust vs C Pitfalls

#74

Post by steveklabnik »

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…

We've slowly been shifting how we talk about Rust as it evolves. I agree with you that these things matter, and they're all things we're actively working on.

Re: Rust vs C Pitfalls

#75

Post by lossolo »

mmstick wrote: post #38
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 is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmark…

> Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions.

They are useful in this case, aren't they? Custom hash map implementation can be also useful in other scenarios. This is feature of the language that allow you to do that so it's not "illegal" to use it. If Rust doesn't allow you to do something while other language does, it doesn't mean it should be illegal.

I don't see any tricks in Go and it's faster than Rust and more memory efficient in almost half of the benchmarks. So what's your excuse for those cases ?

Re: Rust vs C Pitfalls

#76

Post by lossolo »

steveklabnik wrote: post #71
lossolo wrote: post #67

Earlier quoted context omitted.

> Basically, anything you can do in Go, you can also do in Rust, but Rust will let you do it with higher efficiency and with significantly less lines of code. Then i challenge you. Read 5 GB text file, line by line and search for one string that occur lets say 200k times and count how many times it occurs in file without going into C or using unsafe keyword in Rust, do it as you say more efficient than in Go (faster…

http://blog.burntsushi.net/ripgrep/ There are only seven instances of unsafe: https://github.com/BurntSushi/ripgrep/search?q=unsafe&type=C... Four of them are related to calling libc/kernel32 functions, which need unsafe to be called. One is due to using a memory map, which needs unsafe to be called. Only two are actual unsafe rust functions. That's a "real-world" example though, you're asking for a more specific imp…

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 without going into unsafe/C code.

Re: Rust vs C Pitfalls

#77

Post by simcop2387 »

pvg wrote: post #73
mmstick wrote: post #38

Earlier quoted context omitted.

This is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmark…

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

Re: Rust vs C Pitfalls

#78

Post by steveklabnik »

lossolo wrote: post #75
mmstick wrote: post #38

Earlier quoted context omitted.

This is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmark…

> Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions. They are useful in this case, aren't they? Custom hash map implementation can be also useful in other scenarios. This is feature of the language that allow you to do that so it's not "illegal" to use it. If Rust doesn't allow you to do something…

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.

Re: Rust vs C Pitfalls

#79

Post by steveklabnik »

lossolo wrote: post #76
steveklabnik wrote: post #71

Earlier quoted context omitted.

http://blog.burntsushi.net/ripgrep/ There are only seven instances of unsafe: https://github.com/BurntSushi/ripgrep/search?q=unsafe&type=C... Four of them are related to calling libc/kernel32 functions, which need unsafe to be called. One is due to using a memory map, which needs unsafe to be called. Only two are actual unsafe rust functions. That's a "real-world" example though, you're asking for a more specific imp…

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.

Re: Rust vs C Pitfalls

#80

Post by burntsushi »

lossolo wrote: post #76
steveklabnik wrote: post #71

Earlier quoted context omitted.

http://blog.burntsushi.net/ripgrep/ There are only seven instances of unsafe: https://github.com/BurntSushi/ripgrep/search?q=unsafe&type=C... Four of them are related to calling libc/kernel32 functions, which need unsafe to be called. One is due to using a memory map, which needs unsafe to be called. Only two are actual unsafe rust functions. That's a "real-world" example though, you're asking for a more specific imp…

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 come down to highly optimized SIMD routines. For example, in Go, the code to search for a single byte on amd64 is written in Assembly (as it is in glibc too). This means it's probably not a good indicator of language performance overall.

Post reply on HN