Comment by sidlls | Hacker News Reader

Comment by sidlls | Hacker News Reader

The biggest flaw in Rust's marketing, as far as I can tell, isn't noting that it's safer than C or C++, or that it's a systems programming language, it's the simultaneous (implicit and explicit) confrontational bashing on languages that aren't Rust, but especially C and C++, and the egregious ego-inflating comparisons (x-in-Rust is y-times-as-fast-as-x-in-C-or-C++).

I've only written a few relatively small ("toy") applications to completion in Rust. I have one application I'm working on in Rust at work, which is in an advanced stage of development and that will replace a significant part of our production-deployed current implementation (in python). I also have one application I'm working on in my spare time that is not a toy (although it is for entertainment purposes). My view is that for a good number of tasks Rust is nicer to use than C++, and probably I'd reach for Rust before C++ in instances where I'd normally choose C++. It would depend heavily on the context when comparing Rust vs. C. The safety argument simply doesn't register most of the time.

No, this isn't because "I don't have problems writing safe C or C++ code," (although I certainly expect the above comment to be misinterpreted uncharitably in this way) this is because the kinds of safety guarantees Rust provides simply don't register on the list of reasons to explicitly choose it (over C or C++) in a large number of contexts. Even in contexts where it does matter, the current state of affairs is that those terrible languages, C and C++, run the world well enough. There are some pretty good examples of terrible safety flaws that may have been avoided with Rust's guarantees. These aren't universally applicable to all problems to be solved in programming.

My advice, for all it's worth, is to stop hyper-focusing on safety and definitely stop the oblique insults to C, C++ (and other languages--some notable GC'd ones come to mind, from recent posts and comments I've seen around here). Rust has so much more to offer than an implementation detail (which is what "safety" is).

> The safety argument simply doesn't register most of the time.

Just like Steve said:

> Rust is safer than C or C++. (“I never have problems with safety in the C++ code I write” is a common reply.)

The CVE provides a pretty convincing argument that people can't write safe code in C/C++. And improving safety over C/C++ specifically is Rust's raison d'etre (you know, being developed by Mozilla which has a pretty large C/C++ codebase where safety is an important aspect). The bashing isn't based on people merely disliking C/C++. It's based on the fact that we observed 30 years of C/C++ being used in the industry and yet we still discover security holes caused by the same underlying flaws in the language.

Yes, Rust may have other features to offer, too. But safety is a big one and is thus mentioned so often.

C++ can be safe. Just use only safe pointers and vectors.

The thing is that rust does two things:

1. Safety

2. FP style code ("magic")

I wouldn't mind #1, but #2 kind of turns me off.

> C++ can be safe. Just use only safe pointers and vectors.

Defaults matter. In C++ safety is opt-in, you have to explicitly chose safety, the default is unsafe code. Rust is opposite, safety is opt-out, you have to explicitly use 'unsafe' functions to write unsafe code. Take a guess which strategy makes junior developers write better code.

>Take a guess which strategy makes junior developers write better code.

An org can mandate use of only safe pointers.

Yes, but my experience at enterprise level, is that no one does.

C++ can be safe, and I usually make sure to use those features when I need to integrate C++ code within JVM/.NET applications.

However that is a personal option, I seldom have seen such options in enterprise code.

Safe pointers aren't guaranteed safe. If you move a uniq_ptr, you get nullptr, which can be dereferenced. You'll get zero help from lints, as this is defined behavior by the standard, yet you'll still be having UB. In Rust it's a compile-time error.

Last I checked it's still quite easy to invalidate a std::vector's iterator in "safe" C++. Is that no longer the case?

Still possible. There is no "safe subset" of C++. There is a safer subset, which is usually safe. One usually ends up using lots of std::shared_ptr anyway.

I haven't noticed this "bashing" you speak of, and I've kept a close eye on every Rust thread on HN the last few years.

That said, I think that in 2016, whatever one can say about the unsafety of C and C++ deserves to be said, loudly, and I think it needs to be heard. Programs shouldn't be susceptible to buffer overruns, race conditions or null-pointer crashes. Users shouldn't be disrupted, and servers shouldn't be compromised. In other words, we should expect more, and I think giving C and C++ some competition is a good idea.

I agree that Rust's marketing has been too focused on safety, though. For me, it's a few bullet points down on the list. I'm much more excited by ADTs, pattern matching, solid generics, and the performance potential that can come from zero-cost abstractions and flexible approaches to memory management.

Interesting comment. I'm not sure Rust's safety guarantees are what many would consider merely an "implementation detail". Aren't the merits and caveats in any programming language (not with regard to its overall ecosystem), just implementation details? Or is my line of thinking not correct about that?

I'd agree with you on this point if a language really marketed its relatively simple safety facilities — like, say, C++11's std::shared_ptr — but relatively high-level (or perhaps "mid-level") guarantees provided by the standard or by the implementation strike me as features of real substance. Something substantial enough that I would take it into account in choosing a language, among many other things, and I think Rust's are relevant to a large number of systems.

From what I can tell Rust is being marketed well enough to create a lot of enthusiasm. I don't know if that's necessarily an indication that it's being marketed properly (by whatever definition of "properly" makes sense).

The safety features of Rust are core to the design of the language, that's what makes it so effective. It essentially takes part of what makes the design of pure functional programming so safe and makes it highly performant and pragmatic for a systems programming context. An implementation detail would be like the intricacies of better code generation, which is not at all key to Rust.

Granted, it's "C fast," but the whole point of the safety features is that they are intrinsic and pervasive to how the language functions so that the programmer is not allowed to make certain kinds of mistakes that C and C++ are totally fine with and will generate crashing code for. It's not just about making unsafe programming practices safe through better compiler practices, it's about stopping the unsafe programs before they reach the compilation step.

> It's not just about making unsafe programming practices safe through better compiler practices, it's about stopping the unsafe programs before they reach the compilation step.

I would like to add to the end of that: "...unless you explicitly tell the compiler to do it." I can't think of anything that you can do in C that you can't do in Rust unsafe blocks, you just have to tell the compiler explicitly.

Yes, the unsafe parts are always explicit so you never forget about the gravity of working with unsafe code.

Safety is definitely part of implementations at least as much as it is a property of languages. The baseline measure of that is with compiler error messages. Classically bad(as in, this is what you'd get in many environments circa 1980) error messages just terminate and say "error code 100", and then you'd go look in your reference manual to figure out what error code 100 meant, because the system was too crude to have actual error printouts. Maybe you'd use a machine code monitor, or roll your own trace logs. So you'd be mostly in the dark as to what is wrong and how to fix it, and debugging was default-hard rather than default-trivial, shaping the entire nature of the programs you wrote towards easy wins that would not break catastrophically.

Rust, on the other hand, has invested so much into its error technology. It tells you what the offending lines are, the type of error, and gives a best-effort to point out the underlying issue causing the error. It guides you towards a code style that best exploits the nature of the errors, allowing you to take "risky" moves that only the compiler can successfully guarantee, and in-the-large, to an architecture that follows the grain of the compiler instead of fighting with it.

This. I've noticed the same exact thing. I have even wrote the same thing about insulting other languages by Rust community here/on Reddit couple of months ago. I don't know why but whenever someone have different opinion that sometimes shows flaws of Rust or shows some trade offs, he is getting attacked by Rust fans here on HN or sometimes on Reddit, sometimes personal. Doesn't matter if he only post facts/numbers it will get down voted to hell. But it's not everywhere like this. Rust community on their official IRC channel is great, I was there, discussing different languages and solutions, comparing Rust to C++, discussing what is great and what is not so great about both. We did it there without any bias or bad emotions. Great technical discussion in great atmosphere. But if you write here for example that in one case C++ made better design decision than Rust then you need to get ready for a war. It feels like some people live in this bubble and whenever you say something that can get them out of this bubble they are starting to be very defensive. But not all, for example discussion with burntsushi on HN that advocates Rust was great and this is an example of behavior that should be followed. He recognize the trade offs and flaws of the language because we all know there is no such thing as ideal programming language. He is not having problem with writing that case 1 is better in Rust than language Y but case 2 is better in language Y than in Rust. It would be great if other known Rust advocates would give same example as he does. His educated, long answer showed me something I wasn't aware about Rust regex implementation, which is a lot better than Go or C++ one. And he did that without too much bias or bashing other languages.

The discussion he referenced, if you haven't seen it: https://news.ycombinator.com/item?id=13267537

Compared to C++ even Java looks good.

Reply on news.ycombinator.com