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

221–230 of 379 posts

Re: Rust vs C Pitfalls

#221

Post by vatotemking »

Manishearth wrote: post #146
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…

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

> 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 python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.

This resonates well with me. I came from PHP and I decided to learn C in order to contribute to an existing PHP extension. I was doing well following a C tutorial. Until I arrived at string manipulation at which point I said, f* this sh.

So looked for an alternative systems programming language to learn, and found Rust. And its a pleasant language to work on. Its a low level language that feels like a high level language.

My only fear is that, if Rust becomes a popular language, the community will end up as toxic as the JS and PHP community. Right now, the Rust community is filled with the smartest and friendliest devs I know of among open source communities, and I kinda like it to stay that way.

Re: Rust vs C Pitfalls

#222

Post by Manishearth »

Animats wrote: post #203
Manishearth wrote: post #185

Earlier quoted context omitted.

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

> Is it really necessary to expose an unsafe API that bypasses subscript checking?

Sometimes you don't want to rely on LLVM, and sometimes the size invariants aren't as easily available to LLVM.

I'm not even sure if this would be that necessary outside of the library itself; unchecked indexing would be useful to implement ops like matrix multiplication within the library, once, and probably never used after that.

The API exists mostly to mirror the stdlib one and its use cases. I don't think it's supposed to be the API you reach for usually. Just because the API exists doesn't mean it's the one you're supposed to reach for.

> That may improve, especially if there's some standard idiom for declaring multidimensional arrays and the compiler handles that idiom well.

I mean, multidimensional arrays do exist in the language. I'm not sure what you're getting at here.

These libraries provide support for treating multidimensional arrays as matrices, with the semantics of matrices (multiplication, addition, etc). You seem to be arguing for making this a first-class compiler feature? I'm not sure how that's very different from just implementing it with some unsafe code -- the bug-prone-ness of the unsafe code is about the same as the bug-prone-ness of a compiler optimization that replicates it. There is a case to be made for moving it into the stdlib itself to avoid the "10 ways to do it" issue, but Rust wants to keep the stdlib small so that's not going to happen.

This is the point of unsafe code. You use it to implement a few safe abstractions like matrix multiplication and iteration in libraries, verify that, and use them. There's a stigma attached to unsafe code; rightly so; because there be nasal demons. But we shouldn't take it to its extreme and conclude that all unsafe code is bad.

> "get_unchecked" for Vec may be obsolete.

Wouldn't count on it. A single datapoint doesn't really mean much here.

I mostly see get_unchecked being used in the context of other unsafe code. Rust's stdlib uses it for the internals of CString and for implementing iterators. It also uses it in an optimization for the rand crate; which does some trickyness with bitmask indexing that LLVM might optimize but I suspect the authors didn't want to rely on LLVM optimizing.

Servo doesn't use it at all, though. Going through my cargo cache dir the crates that use it are those which implement abstractions. Some, but not all, of the use cases there probably get optimized out anyway. The regex stuff also uses it but the invariants there are complicated enough that llvm won't optimize it (there are some decent comments listing out these invariants and explaining exactly how to use it safely, though).

Re: Rust vs C Pitfalls

#223

Post by ainar-g »

jerf wrote: post #150
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 problem isn't that communication is hard, it's that semantics matter, we want different semantics between languages, and there is always difficulty bridging those gaps. As a simple example, consider the JSON string {"a": 36893488147419103232} That's 2 to the power of 65. Let's decode that in Python. What do I get? >>> import json >>> >>> json.loads('{"a": 36893488147419103232}') {'a': 36893488147419103232} >>> js…

Just as a nit, you can deserialize this number in Go just fine with big.Int: https://play.golang.org/p/s1EFgyXxl5.

Re: Rust vs C Pitfalls

#224

Post by estefan »

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've literally just started learning Rust after following it for a few years. I wanted a language that was type-safe and produced binaries to simplify deployment. I chose Rust over Go because I wanted a functional language with generics. Go's repetitiveness regarding error handling just put me off.

I've tried learning C/C++ at several times but I just don't have the inclination to have to bother about null-terminating strings, etc in 2016. I don't mind spending a little more time getting something to compile if it prevents silly mistakes.

Having said all that, it's obviously too early for me to say whether I like Rust. I'm picking it up pretty quickly since I know FP thanks to Scala, but I'll see how much time I spend fighting the borrow checker.

Re: Rust vs C Pitfalls

#225

Post by rubber_duck »

shmerl wrote: post #120
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.

> The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Avoiding security related issues based on a whole class of problems prevented in Rust by design is a huge benefit. It's better for compiler to prevent that, than to rely on levels of experience, while anyone can make a mistake in reality.

Rust only deals with half of the story at the compile time because it can't deal with stuff like cyclical refs, etc., and even without it it also makes a lot of valid code invalid because of it's borrowing rules.

That's not saying that borrow checker is worthless but it does add overhead and frankly in a lot of scenarios that's just not necessary, even with all that fancy compile time checking you still need to do testing and there are many applications where "working for the stuff tested" is enough. Obviously when you're writing a browser that people will try to exploit and you need to execute third party code and load content from entrusted sources things will be different.

So I get where OP is coming from, Rust safety is oversold IMO - it's nice but it's not the only thing that's interesting about Rust - just the fact that it has modules, an official build system and a package manager that's used by everyone is enough for me to consider it over C++. It's lacking IDE like tooling and meta-programming capabilities (in stable at least)

Re: Rust vs C Pitfalls

#226

Post by EugeneOZ »

Manishearth wrote: post #131
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 don't really consider this to be "great IDE support", I consider this to be a start at IDE support. I love Rust, and I'm productive even without racer or YCM -- but I think there's a large gap between what Rust has and what many IDEs get you. Most Java/C# IDEs will get you: - Type-based autocomplete (racer/YCM/etc have this for Rust) - Jump-to-definition / documentation (YCM/etc has this) - Autoimport - Non-grep-ba…

IntelliJ IDEA Rust plugin gives all of that, although sometimes types detection is not smart enough.

Re: Rust vs C Pitfalls

#227

Post by duneroadrunner »

copperx wrote: post #217
EugeneOZ wrote: post #211

Earlier quoted context omitted.

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.

Well, I don't know about java's reputation, but there's this:

http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend...

http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...

Re: Rust vs C Pitfalls

#228

Post by hueving »

vatotemking wrote: post #221
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…

> 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 python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues. This resonates well with me. I came from PHP and I decided to learn C in order to contribute to an existing PHP extension. I w…

>Right now, the Rust community is filled with the smartest and friendliest devs I know of among open source communities, and I kinda like it to stay that way.

I have yet to find a community that has gotten popular and hasn't turned into a sewage plant. I think it's just a reflection on what the general population is like... :(

Re: Rust vs C Pitfalls

#229

Post by hueving »

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.

>It's plenty fast

Unless you need guarantees that can't be offered by garbage collection.

Re: Rust vs C Pitfalls

#230

Post by estefan »

EugeneOZ wrote: post #226
Manishearth wrote: post #131

Earlier quoted context omitted.

I don't really consider this to be "great IDE support", I consider this to be a start at IDE support. I love Rust, and I'm productive even without racer or YCM -- but I think there's a large gap between what Rust has and what many IDEs get you. Most Java/C# IDEs will get you: - Type-based autocomplete (racer/YCM/etc have this for Rust) - Jump-to-definition / documentation (YCM/etc has this) - Autoimport - Non-grep-ba…

IntelliJ IDEA Rust plugin gives all of that, although sometimes types detection is not smart enough.

I've been using this plugin but it doesn't seem to do auto-import. Does it definitely support that? Apart from that, as you say, type detection isn't always particularly useful. Apart from those two features, it's pretty much there, definitely usable.
Post reply on HN