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

201–210 of 379 posts

Re: Rust vs C Pitfalls

#201

Post by mmstick »

zerofan wrote: post #32
gpderetta wrote: post #8

Earlier quoted context omitted.

I doubt that a significant amount of C programmers will switch to Rust. On the other hand, rust is very attractive for us C++ programmers.

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…

> Rust had the chance to make strings feel as comfortable as integers, but instead they introduced their own dichotomy with String and &str.

It makes perfect sense when you understand the differences and reasoning behind it. A `String` is a heap-allocated string that can grow in size. On the other hand, a `str` is basically a fixed-size string array, but you'll never interact directly with this type because there's no point in it. It's tucked away inside the `String` that created it.

Meanwhile, an `&str` is a slice of that fixed-size `str` array that's hidden within the `String`. You can think of a `str` as an `[char]` with it's own special `str` methods, and an `&str` as an `&[char]` which has access to all of the `str` methods as well.

> Speaking of integers, Rust's choice of 32 bit integers as the default for literals is painful given that every machine most of us will ever care about is now 64 bit. I routinely deal with arrays and files that are too large for a 32 bit integer.

I'm pretty sure the default integer is a `usize`, which is 32-bit on 32-bit systems and 64-bit on 64-bit systems.

Re: Rust vs C Pitfalls

#202

Post by kazagistar »

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…

Compared to a lot of C++ and other compile time polymorphism, the error messages are consistently excellent, if sometimes long, and some of this is due to the simplicity of traits.

I am also extremely fond of pattern matching and algebraic data types (first class tagged unions). It is a style of data modeling borrowed from ML/Haskell and is quite distinct from OOP. The key distinction is that by making a datatype with multiple variants closed to extension, you can clearly see and handle all possible cases for a particular purpose (with checking from the compiler) which is often more natural then having fragments of implementation across many child classes.

Re: Rust vs C Pitfalls

#203

Post by Animats »

Manishearth wrote: post #185
Animats wrote: post #171

Earlier quoted context omitted.

Agree that Rust lacks something comparable to NumPy for numeric work. Rust does have lots of numeric crates. Too many. I took a look at matrix multiply functions recently.(See [1], below "Here is what the Rust compiler actually does", for some notes on the effectiveness of Rust's subscript checking optimization.) "algebloat" wouldn't compile on stable. "matrixmultiply" is all unsafe code, with C-type raw pointers. "n…

> "ndarray" has unsafe indexing We've had this discussion before. ndarray exposes both a safe and unsafe API for indexing, just like the stdlib vector (or core arrays). That is not problematic. I agree that the lack of standardization is a problem, though. I think that mostly folks use ndarray or nalgebra (and num if they need bigints). Anyone can upload a crate, the question is if the crate is the main one used by t…

Is it really necessary to expose an unsafe API that bypasses subscript checking? Another Rust advocate was arguing, the last time this came up, that LLVM could optimize out most of the subscript checks. As I showed, it optimizes out about half of them for multidimensional arrays implemented with an explicit multiply. That may improve, especially if there's some standard idiom for declaring multidimensional arrays and the compiler handles that idiom well.

For 1D, though, the optimization of checking is pretty good. "get_unchecked" for Vec may be obsolete. There's an amusing Stack Overflow question [1] from someone who complains that he changed an access from "[]" to "get_unchecked()" and his program didn't get faster.

Maybe it's time to deprecate some of the legacy "unsafe" stuff. Preferably before the first CERT advisory involving a buffer overflow in a Rust program.

[1] http://stackoverflow.com/questions/39196594/why-dont-i-get-p...

Re: Rust vs C Pitfalls

#204

Post by mmstick »

zerofan wrote: post #89
steveklabnik wrote: post #61

Earlier quoted context omitted.

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

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

The lowercase type names are reserved to primitives. The String type is not a primitive but a comprehensive data structure, hence the capital S. The String type contains an `str` primitive though, along with size information.

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

Is it that hard to understand that when you create a string, you will create it as either a `String` or `PathBuf`? File methods are designed to automatically convert input parameters into a `&Path` so it doesn't matter what string structure you provide.

There is also no way (currently) to create a stack-allocated string with the standard library out of the box. You can do this with crates like `arrayvec` though. It's very much opt-in for that performance.

let path = String::from("/tmp/file");

let mut file = File::open(&path).unwrap();

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

No need to use a 64-bit integer when you only need a 32-bit integer. You can fit two 32-bit integers into a single 64-bit integer and perform a calculation on both simultaneously with a single cycle, versus spending two cycles to calculate two 64-bit integers. There's also no need to pay that memory cost either.

Re: Rust vs C Pitfalls

#205

Post by akiselev »

gpderetta wrote: post #54
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…

> But I really like function overloading, generic operators that I can overload from the left and the right, integer parameters for my templates/generics, copy semantics as the default [etc.] I do too, and I'd like to think that rust needs all those things to be a replacement, but realistically I think that the only killer feature that rust is still missing is reasonable interoperability with C++ (which admittedly mi…

What do you mean by "reasonable?" There are several crates that provide inline C++ macros on both nightly (rustcxx) and stable (rust-cpp). I haven't used the latter but the former works really well (albeit using a gcc specific feature). I usually break out the C++ code into a wrapper (unless its a few lines) to make it more idiomatic Rust but at the end of the day, there aren't that many hoops to jump through.

Re: Rust vs C Pitfalls

#206

Post by mmstick »

Scuds wrote: post #18
gpderetta wrote: post #8

Earlier quoted context omitted.

I doubt that a significant amount of C programmers will switch to Rust. On the other hand, rust is very attractive for us C++ programmers.

Do you think we'll see major games having significant engine components being written in Rust?

DICE and others have been investigating and using it to create tools for developing games. There is interest in using it within game engines, but there's just the issue of Rust support for major consoles. There is great interest in the PC gaming world though that's not constrained by console support.

Re: Rust vs C Pitfalls

#207

Post by neandrake »

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…

I've seen several of your comments indicate "requiring naive implementation". This seems strange to me. Why require a naive implementation and then be concerned over some slight differences in performance?

Re: Rust vs C Pitfalls

#208

Post by Animats »

mmstick wrote: post #197
Animats wrote: post #192

Earlier quoted context omitted.

That's mostly a library for small vectors for 3D graphics and such. (I once did one of those myself, for C++.[1]) There's some support for 2D matrices in "nalgebra", but with heavy use of "unsafe".[2] Every matrix package I've seen so far in Rust turns off subscript checking with unsafe code. [1] http://graphics.stanford.edu/courses/cs148-10-summer/algebra... [2] https://docs.rs/crate/nalgebra/0.10.1/source/src/linal…

Is there a problem with doing that with unsafe code? You have to remember that unsafe doesn't mean unsafe in Rust. If a developer is choosing to use the unsafe keyword, it's merely telling the compiler that they know what they are doing and what they are doing is safe. One shouldn't automatically infer that unsafe code is bad or negative. It doesn't deserve the negative stigmatism that it's given.

No, it means the developer thinks they know that they are doing. Often, they don't. Read some CERT advisories for buffer overflows. There are hundreds of them.

The whole point of Rust is to put an end to that.

Re: Rust vs C Pitfalls

#209

Post by mmstick »

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've seen fatal flaws from supposed experienced C and C++ developers in a large number of high profile projects, that would otherwise be nuked from existence had they used Rust.

I've also encountered severe flaws in libraries written by experienced programmers working for companies like Google and Red Hat that the Rust compiler caught during translation to Rust.

That's not counting the immense amount of tooling and features that make managing large projects a breeze in Rust. Managing a 100K Rust project with a large team is easier than managing a 100K C++ project with a large team. You can't guarantee that no one will ever make mistakes.

I find segmentation faults to be common place in C/C++ projects from experienced developers, and it's quite difficult to debug them at times.

Re: Rust vs C Pitfalls

#210

Post by mmstick »

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…

You're only going to anger people by referring to another group as 'evangelists' when you yourself have already made note that you don't know enough about Rust to see why they are promoting it. There's much more to Rust than safety. You should actually spend a few months with it, and then give your opinion.
Post reply on HN