Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Prefer Rust to C/C++ for new code (cliffle.com)
13 points by ireflect on Nov 15, 2019 | hide | past | favorite | 8 comments


While it's certainly possible to introduce huge memory safety issues in C++, those usually stem from using C++ as C, i.e. directly allocating and freeing memory, or using plain integers as index variables, or messing with raw pointers etc. C++ contains the tools to minimize (but not entirely eliminate) those potentially difficult to make correct operations. The problem is the defaults are not those safe alternatives, and, especially in large teams, some one some how will use C++ as C eventually.

C++ is used in a lot of closed systems (i.e. closed as in 'no chance to communicate with outside code), as in embedded software, weapon systems, etc, so the potential of exploitation of bugs from the outside is very small.

Where does this leave Rust? well, if the extra safety is justified by the cost of the change, then Rust is the right choice there. But the cost of change can be really huge, because it's not only the retraining of the developers, but also the tools, the infrastructure, the ecosystem etc. And these can be potentially very expensive to change.

Also, C++ is not used alone in systems where increased safety is required. There are lots of tools that can be applied to C++ code to statically discover potential bugs. The combination of idiomatic C++ and of those tools can be cheaper than migrating to Rust and the result could be of the same quality, i.e. bug-free code.

In conclusion, using Rust shall be judged, as always, in economic terms: between C++/safety analysis tools and Rust, which one is the cheaper in the short term and long term? that's the question to answer.


> Your C/C++ programmers are likely not as well-trained as you think they are.

> The list of people who can write C/C++ correctly, under pressure, and then keep it correct under maintenance, is very short.

I see this assertion with increasing frequency lately. What if this list is not really as short as you think it is? People have been writing and maintaining massive C and C++ codebases all over the world for decades. These are wildly _successful_ languages.

Rust is a great language, and I'm happy to witness its rise in popularity.

If I'm being completely honest with myself, I love C++ for its razor's edge. Every piece of code can be _interesting_ (but normally shouldn't be, of course). The line between brilliance and insanity is fine, and exhilarating.

Is good software necessarily boring? Probably. Would the world be a better place if C++ were replaced with Rust tomorrow? Probably.

If I'm already competent in the exciting language, and there are plenty of places willing to pay me to write it, why should I switch to the boring language? Am I the only one who feels this way?

Maybe I should go learn Perl.


Perhaps what you're looking for is Raku: https://raku.org :-)


What makes you think Rust is a boring language?


There is no such language as C/C++.

The characteristics, best practices in, and pitfalls of C are fundamentally different than for C++. Anything that pretends to offer useful advice, but equates them, is certain to be deeply flawed. As, indeed, is TFA.


I have no chips in the game, but the author does state:

> I’ve been using C since about 1993, and C++ since 2002..

> ..I later put a lot of energy into talking other teams at X into using C++, rather than straight C, for their firmware.

So a charitable reading of the flawed phrase "C/C++" would be C and C++, and the author clearly knows both well to back up his assertions.

All in all, I found the title a fair statement to make, he does offer plenty of reasons and even alternatives.


Your critique hinges on my being unable or unwilling to rewrite "prefer Rust to C/C++ for new code" as "prefer Rust to C for new code and prefer Rust to C++ for new code", then verifying that OP's argument applies to the rewrite.


"C/C++", as such, is a reliable marker of ignorance or bias, regardless of the context you find it in, unless the topic is object-code generation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: