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

241–250 of 379 posts

Re: Rust vs C Pitfalls

#241

Post by Ar-Curunir »

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…

> Memory safety is not a concern

That is how we end up with the miserably insecure state of affairs of today :)

Re: Rust vs C Pitfalls

#242

Post by hordeallergy »

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…

"My only fear is..." - this is why I'm in the process of moving to Rust after 3 years of Go. I've come to the conclusion that a low barrier to entry leads to a bad state of affairs. Rust has a learning curve that I hope will help it avoid devolving into chaos.

Re: Rust vs C Pitfalls

#243

Post by greatest-ape »

pklausler wrote: post #27

A more interesting question for me is: is there any reason why would I want to use Rust over Haskell on any task where Haskell is "fast enough"?

The syntax for accessing records (dot notation) is a lot nicer in Rust in my opinion. This makes a huge difference in practice, since I don't have to have ridiculously long accessor functions. Though I haven't learned how to use lenses in Haskell yet, they're supposed to alleviate some of that pain.

I know you left out performance, but it's very nice to have code that can be easily profiled.

Re: Rust vs C Pitfalls

#244

Post by adrianN »

hueving wrote: post #229
adrianN wrote: post #200

Earlier quoted context omitted.

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.

Java is pretty popular for HFT applications. I think most programs are less latency sensitive than that. But of course, Java is not for you if you have hard real time constraints.

Re: Rust vs C Pitfalls

#245

Post by chousuke »

j1vms wrote: post #53
db48x wrote: post #19

Earlier quoted context omitted.

If only these mythical experienced developers that never shoot themselves in the foot actually existed.

> If only these mythical experienced developers that never shoot themselves in the foot actually existed. Rust is a great language, but people have to stop "marketing" it by saying things like: no matter how great you are with C, you're going to fuck up at some point, so that's why you should be using Rust. Like Go or whatever other language, the main grab needs to be a positive: you know what you're doing, and here'…

I don't see it as a negative, really, just realistic. It is a fact that everyone makes mistakes, and with the inherent complexity and features that are demanded of modern software, it is harder and harder to maintain a comprehensive understanding of a codebase so that you can detect these mistakes before they cause damage. This means that even if you are a perfect developer, you need to expend a lot of energy to maintain that perfection if you're using tools that don't help you.

To me, modern tools like Rust are supposed to relieve part of the burden. In the common case, if I can be reasonably certain that I can't make certain classes of errors, my brainpower is freed to focus on other things and I can work with significatly less stress.

Rust is interesting because it allows you worry less without actually compromising much in capability. In the cases where I would need to be able to bypass the tooling, it is explicitly possible.

Re: Rust vs C Pitfalls

#246

Post by adrianN »

duneroadrunner wrote: post #227
copperx wrote: post #217

Earlier quoted context omitted.

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

The Java VM is written in C though.

Re: Rust vs C Pitfalls

#247

Post by groovy2shoes »

steveklabnik wrote: post #94
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…

There's at least two alternate compilers I know of in the works. We'll see when they're in a workable state, or at least, enough to compile rustc. > In the meantime, I'd settle for an "LTS" release or something. That could work. This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.

I could definitely live with such a solution, but even six months might be too quick. So, as long as the plan is to lengthen the LTS window, I think that could work.

The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They want to know they can get bug fixes, and vetting/upgrading the compiler is a lot of work regardless, so they tend to do one and stick with it for a while. OpenBSD does the same thing for security reasons. If Rust wants to replace C and/or C++, these are things that will need consideration eventually. I don't see my company allowing Rust any time soon, unfortunately.

As a compiler-writer, I'm more concerned that Rust is a quickly-moving target at the moment. I think that as Rust becomes more mature, it will naturally begin to stabilize feature-wise, in which case something akin to the Haskell model would work well, with innovation happening in the flagship compiler and "snapshots" of the language being taken as standards periodically. That's just a matter of time, though.

Re: Rust vs C Pitfalls

#248

Post by masklinn »

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.

> 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

Context is pretty important to the original comment:

> python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.

they're not looking for a fast language in isolation, they're looking for a fast language in the broader context of their existing technological stacks. Java doesn't help that much when you're looking into ways to speed up your Ruby application, at least not easily.

Furthermore, Java has the issues that it's only fast when memory is plentiful and it has a long startup/running time, it's "eventually fast" if you will.

Re: Rust vs C Pitfalls

#249

Post by cesarb »

EugeneOZ wrote: post #211
adrianN wrote: post #200

Earlier quoted context omitted.

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.

Java has not so great reputation about safety.

Java's bad safety reputation comes mostly from the Java plugin, where many inventive ways to bypass its sandbox have been discovered. When used as a normal programming language, without depending on it for sandboxing (that is, when all code running in the JVM is trusted), its safety is quite good.

(Java also has a not so great reputation about speed. That one also comes from the Java plugin, which often took minutes to start up, while keeping the Netscape browser UI locked up.)

Re: Rust vs C Pitfalls

#250

Post by groovy2shoes »

naasking wrote: post #179
grzm wrote: post #176

Earlier quoted context omitted.

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

More often than not, brand-spanking-new software is written against 30-year-old APIs.

Lots of software we use day-to-day is old. For example, a couple years ago I fixed a 20-year-old bug in netcat, which itself hadn't been updated since the mid 90s. After I fixed the bug, I didn't need to fish out an old compiler or any compatibility libraries; I just compiled it with the latest GCC and glibc, and carried on with my day.

Don't get me wrong, I like Rust a lot and I'm excited that there's finally a real contender for the systems programming throne after all these years. I'm just less enthused about the prospect of refactoring my codebase once every few months to stay current. This is something that I think will level out with time, though. C itself was almost 20 years old before it was standardized, after all. I don't think it will take Rust that long, and I look forward to the day my copy of the Rust standard arrives on my doorstep.

Post reply on HN