Ask HN: What is preventing rust from replacing c/c++?

Basically I think it boils down to the fact that the c/cpp tooling is actually really sophisticated at this point and developers have already learned how to deal with the pain points of c/c++ so there is little incentive to change. Especially, since it means swapping out a highly advanced ecosystem i.e. UnrealEngine for the chance to spend the next 5 years building your own not-as-good system to then be able to start to program your own game. And its like this in every C/C++ industry I'm aware of (embedded devices / games / desktop apps).

I'm a rust fan, even more so of cargo (wish C/C++ had a cargo). But at the end of the day it almost always boils down to transition costs vs. benefits, and the benefits currently don't outweigh the transition costs IMHO.

What's preventing the tree you planted from replacing the old tree next to it? Nothing really, ask again in 30 years.

Software is slow, your OS and browser have taken 20+ years of C/C++ development with top professional development teams to become the nearly tolerable products they are.

Rust will never take off until someone (or some group) uses it as the basis for a new, mind-blowing, must-have thingie.

For C it was Unix.

For JavaScript it was the web.

My guess for when something like that will happen with Rust? Never.

Unfortunately, verbose, anal-retentive languages like Rust are simply poorly-suited for writing new, mind-blowing, must-have thingies. On the scale of languages that support exploratory programming, I'd put Lisp at the top, JavaScript fairly near the top, C somewhere above the middle (though it was quite close to the top when it was new), and Rust somewhere down in the FORTRAN and COBOL region of the spectrum.

Note that this is completely orthogonal to type-safety, running speed, or any other traditional measure of programming language merit. The shoals of the language ocean are littered with the wreckage of "better" languages (the various Wirth languages, e.g.). What really matters is whether a programmer can sit down and casually explore a cool idea in a few minutes of spare time, and you can't do that in a language that requires half a page of code to concatenate two strings.

Swift has managed to roll type safety (more or less) into a language that's actually fun to use, or at least not actively painful. Rust hasn't.

Code already written in C/C++. I don't think there's anything stopping Rust from snowballing at this time. It's built some very strong libraries for certain problem domains, and because there's package management, it's possible to reuse it. This has already substantially reduced the friction of "systems" programming since you don't run into a challenging build process. But for the majority of folks the answer for an immediate need is still a tool or framework they already use.

1. Rust is not C/C++ 2. Lots of software is already written in C/C++ 3. Rust follows the same convention as C/C++, that you integrate functionality by writing a library, compiling and linking it into a monolithic binary 4. Systems that rely on a monolithic binary are NP hard to replace with something different 5. Replacing a monolithic binary works best, in practice, when it is done by refactoring into services that are integrated by something other than a link editor. Although the buzz is all about web microservices, the reality is that message queuing to tie together microservice, macroservices and monolithic binaries, provides better performance more consistent with the linker/monolithic model. 6. Go with its channels and packages may be a more advanced model, and is also competing with Rust. In other words, it is not just a question of comparing Rust to C/C++ 7. The JVM with its JIT has in many cases equaled or exceeded the performance of C/C++ monoliths, but languages like Clojure and Scala take it well beyond mere Java. 8. It may be that replacement of systems is driven more by economics than by technology. In other words it is not Rust that will determine the fate of Rust, but the economic sucess of companies using Rust for mission critical systems. In 20 to 30 years, the businesses that have succeeded will determine which technology is better.

Inertia. You don't rewrite an existing codebase unless the current one is simply not capable of doing what you need it to. And there are a lot of existing codebases in C and C++.

This question is both a leading and also ill-posed. What is preventing Rust from replacing C/C++ _where_? In existing applications? For new code development? In some particular application (e.g. game engines)?

There are lots of good answers in the comments here. I think Rust has a good story for why you might choose it over C/C++ for some uses today, but it's still early days. If Rust is going to take share from C/C++, it will do so over the period of decades, not years.

Just one data point, but: I'm currently learning about embedded microcontrollers. The standard starting point for this is arduino, which is C/C++ based, so there is a strong pull towards C++ already. But I really wanted to avoid C/C++, and I spent a long time researching alternatives. Rust was one of the most mature for MCUs, but a) it's not very mature and b) you have to pick an MCU with a lot of flash memory as even the smallest rust binary is >100kb. For reference, one of the chips I've been testing out for this project has 127kb of flash. This evening I loaded on a medium-sized C++ project and it took just 24kb.

So that's what's preventing ME from using rust instead of C++

The chorus of Rust zealots who can't let a week pass by without writing yet another "Why won't you stupid plebeians stop using C++?" article.

That alone makes me want to crack open some STL code just to spite them, and I hate C++!

Why hasn't another language, like Ada with similar goals to Rust, replaced C/C++?

Changing languages isn't free. Rust isn't enough better than C++ for most developers (or their management) to switch.

Or, if you're more of the skeptical sort, Rust doesn't seem to be enough better. You could argue that C++ developers don't think they write code that creates memory issues very often. So they underestimate the benefits. (And the borrow checker is a different concept, so they may also overestimate the costs of switching.)

The net result, though, is that they perceive the benefits to not be worth the costs.

For me, equivalent support for the MSVC toolchain on Windows. Obviously it won't ever be 100% without support from Microsoft, and a lot of work has been done, but some items on https://github.com/rust-lang/rfcs/issues/1061 feel important enough to give me pause before spending much time with Rust.

Another reason that I don't see given its fair chance might be politics. The human race has a wide variety of values that are often counteracting. Forcing a specific set of values participants must adhere to in order to interact with the community will undoubtedly alienate adopters.

That's why most projects, companies, and even governments tend to strip down the rules that govern them to what is necessary for them to function (e.g. separation of religion from state for governments).

The common reason given by the rust community to justify their behavior is that technology does not exist in a vacuum, and that technology can not be separated from politics. I completely agree. However, politics should be tackled on a layer incompletely independent from technology. Mixing the two only causes instability and uncertainty for rust. Here are two risks that arise from this mixing. I'm sure there are many, far more serious, risks besides these two:

- What happens when (not if) a significant shift in values occurs in the community? Will it collapse?

- What about technical or legal changes to the project that were driven by community values rather than technical or legal merits? This is not far fetched when technology and politics are made inseparable in the way it was done in Rust.

I use rust in a professional context, and I appreciate what it brings in terms of technical benefits. but I would be lying if a said this aspect of it didn't worry me. I can not recommend its adoption to colleagues from other companies if asked for this very reason (I was asked once so far).

Community instability or the mere perception of such is a big barrier to adoption, at least for companies.

Why would it?

As a C++ developer, I think Rust's main selling point (memory safety) isn't as big of a problem as it's made out to be. For every unsafe memory access that results in a crash or exploit, there are millions and millions of memory accesses that work just fine and never cause a problem. Tools like Coverity and Valgrind can catch a ton of errors, and its not clear Rust offers any significant advantages over C++ with Coverity.

Parallelism is nice, too, but C++ already has a ton of options there: OpenMP, MPI, TBB, OpenCL, standard library threads, boost/standard library async tools, etc.

On the other hand, as an end user, "written in Rust" or "written in <any language>" isn't something I care about. I don't even remember the last time I had a piece of software crash due to a seg fault, so a vague promise of being "safer" isn't good enough to accept an otherwise inferior product.

I guess to summarize, C and C++ developers are going to keep writing C and C++ and if Rust is going to take over the world, the people advocating for it will have to write better software in it and beat out software written in the other languages.

People to write code instead of sitting on their high horse. That and performance as good as c, not c-like, not selective benchmarks, not other nonsense.

Greenfield systems work by startups isn't really done these days. If it's not greenfield, it's probably already in c/c++. If it's not a startup, they probably already have a bunch of expensive c/c++ tooling (static analyzers, IDEs, CI systems, ...) that they aren't going to get in rust.

I would've started using Rust way sooner if academia hadn't forced me to use c++ or c for anything systems related. Upon graduation I felt like a kid in a candy store with all the languages and platforms I hadn't tried in my four years of fun.

Partly time, but also it's much more difficult to get "something that works" in Rust than it is in C++ due to the borrow checker.

Of course your C++ code will probably not be as safe as your Rust code, but many people don't care about that.

I guess that, if you can dislodge C in the embedded space, everything else will follow.

So my question is: when can I use Rust on the Cortex M0 (or on a 32 bits RISC-V), with an interactive debugger, preferentially from a simple IDE?

Over 30 years of momentum.

It doesn't need to replace it (it's not like c++ is being deprecated), and there has to be real reasons to port over existing code, because there are real costs.

The technically best format doesn't always win. Just look at Betamax vs VHS.

If it happens, it will take some time. Java has been replacing C++ for many years now...

Binary compatibility. As a developer I want to be able to:

1. Write an app in rust.

2. Use a rust library in that app, via the native rust interface (using c interfaces negates a lot of the pros of rust).

3. Dynamically link that app to the distro repository version.

4. Have the distro apply security updates to that library without recompiling my app.

5. Ignore cargo completely.

As a user I want to:

1. Not download and install multiple copies of common rust libraries (as is the cargo norm).

2. Not be in doubt whether a particular application is using the latest patched libraries.

It seems that rust community has learned from the mistakes of c, c++, and java. But they failed to learn the successes as well.

Also some people just do not like coding in rust and that combined with the fact that its new means they refuse to switch.

Time.