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

171–180 of 379 posts

Re: Rust vs C Pitfalls

#171

Post by Animats »

mmstick wrote: post #55
gravypod wrote: post #28

Earlier quoted context omitted.

Like you I need something like NumPy and SciPy for my work. I'd also like an IDE. An IDE goes a long way to helping me feel comfortable to use a language.

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…

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. "ndarray" has unsafe indexing. "scirust" has more raw pointer manipulation. "matrices" is an empty project.

In the "num" crate, there are bigints, along with rationals and complex numbers, but no matrices. "numeric" has matrices, but it's just a wrapper for some common C libraries. (Also, calling "panic" for a singular matrix in SVD is kind of drastic.[2])

Each of these matrix crates has its own representation for multidimensional arrays. You can't mix them easily.

Matrices in Rust really need some standardization.

[1] https://news.ycombinator.com/item?id=13230551 [2] https://github.com/numeric-rust/numeric/blob/master/src/lina...

Re: Rust vs C Pitfalls

#172

Post by Ericson2314 »

chj wrote: post #114

We are having new languages every year. Instead of debating which language is the best, why can't we invent a way to let components implemented in different languages talk with each other easily? We have pipes, sockets and message queues, but it's never simple enough to glue everything together.

The point of languages is not what you can do, but what you cannot do---making mistakes impossible so you can trust your own, and especially other's work (libraries).

Combining languages is likely to circumnavigate those prohibitions, defeating the purposes of the thrown-together languages. Your polyglot tower of babel is likely to fail.

See https://news.ycombinator.com/item?id=11830958.

-----

Now I'd love to see a deep RustHaskell bridge. But getting this right by not breaking the interesting invariants of either langauge is research-level work.

Re: Rust vs C Pitfalls

#173

Post by twblalock »

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 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 good reasons) and talk more about other aspects of their language.

Seriously. However, I've seen a lot of comments to that effect from C and C++ programmers who don't want memory safety.

I come at it from a different angle: I'm a Java developer, so I already have memory safety. Pointer arithmetic, dangling pointers, and buffer overflows are not allowed, there is a garbage collector, and so on. In fact, most of the currently popular languages other than C and C++ are memory safe in similar ways. So, in terms of memory safety, Rust does not give me anything critical that I don't already have.

When choosing among the memory-safe languages for a real-world project, I'm going to need a pretty compelling reason to choose Rust instead of Java, Scala, Go, Ruby, Python, etc. -- especially when it is so much easier to hire developers for more popular languages.

Re: Rust vs C Pitfalls

#174

Post by naasking »

groovy2shoes wrote: post #90
lacampbell wrote: post #6

Earlier quoted context omitted.

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

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

You say that like it's a good thing that with C, you can ignore 30 years of progress in software development. Colour me unconvinced.

Re: Rust vs C Pitfalls

#175

Post by mmstick »

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 example is kind of odd. Did you not see the linting errors in your editor or from the compiler? You can basically boil it down to just two lines of Rust.

https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b91...

As for timing, I'm doubtful that Go is any faster than Rust. I don't have this www.js file so I can't test it on my laptop, but I'm pretty sure you didn't even attempt to do things like enabling LTO, setting O3, disabling jemalloc, and using the musl target. All these things can make significant differences to the performance of the binary that's produced.

Re: Rust vs C Pitfalls

#176

Post by grzm »

naasking wrote: post #174
groovy2shoes wrote: post #90

Earlier quoted context omitted.

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

> Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates. You say that like it's a good thing that with C, you can ignore 30 years of progress in software development. Colour me unconvinced.

If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing. At the end of the day, it's what the software does that's important.

Re: Rust vs C Pitfalls

#177

Post by Manishearth »

dalailambda wrote: post #129
richard_todd wrote: post #107

Earlier quoted context omitted.

I have wondered the same for a while now, and I hope someone familiar with Rust can explain it: in many of the benchmarks Go is faster and/or uses less memory despite the GC. Like you, I don't see much trickiness in the Go code.

In many cases a garbage collected language will be faster when it comes to allocations than using naive allocation strategies (e.g. reallocating a hashmap many times as it grows instead of reserving memory upfront). This is because the garbage collector tends to have preallocated memory lying around, while the RAII needs to call malloc and free every time a heap object is created. Another factor could also be that th…

> This is because the garbage collector tends to have preallocated memory lying around,

This is an allocator feature independent of garbage collection; jemalloc does this for example. GCd languages have the potential to do this better since they can do additional analysis whilst tracing for little additional cost, but non-GCd languages can still benefit from this.

Re: Rust vs C Pitfalls

#178

Post by saghm »

treehau5_ wrote: post #126
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…

4th law of HN: Whenever Rust is brought up, Go inevitably follows, and vice versa.

It's kind of a shame, because I don't really feel like the languages are used for similar things in practice, so the constant comparisons don't do either of them justice.

Re: Rust vs C Pitfalls

#179

Post by naasking »

grzm wrote: post #176
naasking wrote: post #174

Earlier quoted context omitted.

> Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates. You say that like it's a good thing that with C, you can ignore 30 years of progress in software development. Colour me unconvinced.

If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing. At the end of the day, it's what the software does that's important.

> If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing

That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO.

And if the types of programs you're talking about are small UNIX-like utilities, well then they're small and easily updated aren't they?

Re: Rust vs C Pitfalls

#180

Post by mmstick »

Animats wrote: post #171
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…

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…

Did you not check out `nalgebra`?

https://docs.rs/nalgebra/0.10.1/nalgebra/

Post reply on HN