Ask HN: What is preventing rust from replacing c/c++? - bulldoa
======
jfaucett
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.

~~~
memracom
I think you are correct in regards to the people who are currently using
C/C++. They already have done the hard work to make it usable for their
systems. But newer developers will look at the complexity of C/C++ development
and choose anything but.

Maybe it is like politics, rather than attacking your opponents you should
offer something that they do not. Then you will build your own constituency
and gain influence. It will take a long time, but if you keep on providing
benefits to users, then attrition might take you to the top. When someone
attacks your camp, ignore them. You do not need a better way to attack them,
you just need to stick to the knitting and make your offer provide benefits to
users. External forces will likely decide whether or not you overwhelm your
opponents.

~~~
AstralStorm
The problem with this approach is that you would really have to offer
something groundbreaking to displace C and C++ while also matching portability
(only matched by Java variants) and performance (often unmatched).

The about only languages that could compete right now are extended Ada for
high assurance environments and Fortran variants for HPC. They are old but not
dead and quite usable if you have the dollars to buy proprietary or invest
time.

Microcontrollers and constrained environments are another critical niche for C
and C++, especially given proprietary compilers.

Rust does not go far enough in safety to displace Ada (or Spark variant) while
not offering improved performance and comparable portability with all the
pains of a new language. It also does not do build once deploy everywhere
stuff Java and JS attempt. Rust is neither here nor there. A good effort but
not a solution.

~~~
smt88
> _you would really have to offer something groundbreaking to displace C and
> C++ while also matching portability_

If you offer something groundbreaking, you don't need to match portability.
Many people will be willing to make the tradeoff.

> _Microcontrollers and constrained environments are another critical niche
> for C and C++_

Why do you assume Rust can't be used for these niches? I understand the
potential issues with old environments, but what about modern/future ones?

> _It also does not do build once deploy everywhere stuff Java and JS
> attempt._

Rust compiles to JS today. It will eventually compile to WebAssembly.

~~~
steveklabnik
(It compiles to WebAssembly today too)

~~~
AstralStorm
Interesting, but is there any advantage there over more dedicated languages?

If not, then again, Rust has no clear selling point. It really has to be
better at something. Matching is not good enough.

It definitely is not easier to use nor embed. (To compete with the likes of
Python, Ruby or Clojure.)

~~~
smt88
> _easier to use nor embed_

"Easy" has no objective definition. Does it mean "getting code to run"? Or
does it mean "writing bug-free code"?

For me, easy means the latter. It means that human error is harder to
introduce into the code. A great language should not rely on the shaky pillars
of discipline or expertise, because neither of those are easy to find or
enforce, nor are they consistent. A disciplined expert might be too sleepy to
write safe code, for example.

Rust is much easier to use than C and C++ because the compiler helps you so
much and replaces discipline/expertise. That's the whole point. Rust prevents
you from doing something you don't intend to do (or at least it does it better
than most languages).

Python, Ruby, and Clojure don't have the same guarantees, and none of them can
be used without garbage collection, making them unsuitable for a variety of
cases where Rust can be used.

~~~
AstralStorm
Compiler does not help you. It is not a proof suggestion system like
Isabelle/HOL or the like.

In fact error messages rust produces rival the terrible nature of ones in
older C++ compilers thus far.

The compiler only prevents you from making mistakes. Intentions do not even
enter into it. See, some of the performance critical code in our apps has to
work around even the lax C++11 rules. It is completely impossible in rust
without using unsafe stuff liberally - specifically gets about 1000x slower
and this matters a lot. Compilers know nothing about intentions, nor can a
borrow checker enforce intentions unlike a type system.

~~~
burntsushi
> Compiler does not help you. It is not a proof suggestion system like
> Isabelle/HOL or the like

This seems like a gratuitous misrepresentation. A compiler does not need a
proof suggestion system to help you.

> In fact error messages rust produces rival the terrible nature of ones in
> older C++ compilers thus far.

No, it doesn't. The error messages are wonderful and constantly improving.

> It is completely impossible in rust without using unsafe stuff liberally -
> specifically gets about 1000x slower and this matters a lot.

Can you give specific concrete examples?

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

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

That's... actually one of the best descriptions I've ever heard about these
tradeoffs. :)

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

~~~
frik
Elixir brought a sane syntax to Erlang.

A Swift or Go inspired simple syntax could revive Rust.

~~~
AstralStorm
Syntax is not even really a consideration. See how much people put up with in
Perl and PHP world. PHP used to be language for web until displaced by JS.

~~~
frik
That's your opinion. PHP, JS (nowadays to some extend also Go and Swift) are
so successful, BECAUSE they have a simple and C-like syntax. Rust syntax is
rather an afterthought, unfortunately.

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

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

~~~
AstralStorm
Java Achilles foot has always been memory use and really compute constrained
environments. Things like high end video game engines are not being written in
Java, Closure or Scala for these very reason.

I would be very careful about JIT performance being even close. See, the
language does not even expose SIMD well. Doing anything hard realtime (heck,
even more complex UI) with a JVM in the way is a big pain.

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

~~~
AstralStorm
Even when you do rewrite, there has to be a clear benefit. Rust does not offer
a clear one.

(No, reducing amount of bugs does not do anything when pitted against well
tested mature software that already exists.)

~~~
mmstick
Rust does much more than reducing bugs. It is able to reduce memory
consumption, decrease the required amount of CPU cycles, and increase
maintainability / adaptability. ADTs aren't a joke, and neither is Cargo, move
semantics by default, and the borrow checker / borrowing and ownership
mechanics as a whole. Shipping solutions in Rust can be done at record speeds,
and integrate with existing software. Rust is wildly successful, and there's
no way of stopping it.

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

------
kennywinker
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++

~~~
35bge57dtjku
There's really no way to trim down the rust binaries??

~~~
steveklabnik
There absolutely is; the smallest known Rust binary is 151 bytes.

~~~
AstralStorm
How about a smallest real application that doors something useful? Say, basic
networking on the level of static pages like uhttpd. (Used in many routers.)
Or a busybox ash equivalent at least.

------
jstewartmobile
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++!

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

~~~
acomjean
Its the operating systems libraries. They're in C.

I did a lot of ada programming (radar) and we had a fairly large library of
wrappers to the C network/ ipc / process control that the operating system
provided. It was a royal pain. So much so that at least a couple subsystems
moved to C (mainly to use the math libraries......)

~~~
AstralStorm
More modern styles of Ada work pretty well. The trouble is in getting the code
to run in a restricted environments. MCU compiler authors tend to provide C
only.

Perhaps a transpiler would be better.

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

~~~
JoeAltmaier
Perhaps they estimate the benefits correctly. In that case, they may never
switch.

~~~
AstralStorm
More modern styles of C++ just wholesale avoid most problems that are solved
by the borrow checker. Smart and owning pointers, dynamic and checked data
structures thanks to operator overloading. There are remaining warts but not
bad enough in practice.

~~~
jjpe
That's not really all that relevant for most existing commercial code since
legacy code tends to not get rewritten at all unless it's absolutely
necessary, and thus remains stuck with the Old Ways.

~~~
AstralStorm
Indeed, but unlike a rewrite, you can refactor staying in the same language at
your leisure, piece-wise.

Plus the argument was mostly pertaining to new code.

------
wbond
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](https://github.com/rust-lang/rfcs/issues/1061) feel
important enough to give me pause before spending much time with Rust.

~~~
steveklabnik
I use it daily, and it works well. I'm still a newbie Windows person so I
probably don't notice these pain points...

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

~~~
mmstick
Using a programming language does not force you to join a community; and what
is the Rust community, anyway? Which Rust community? The Code of Conduct
pertains to the official venues of communication, not the language itself. All
communities have rules. And the rules are quite normal of any community that
wants something resembling civility.

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

~~~
xfer
Coverity is expensive and majority of software people use are open-source
which don't make use of it(hence all the CVEs).

As an end user running a server, i __very __much care about whether my web
server has vulnerabilities. And the promise about safety is not vague, it has
clearly defined semantics.

To comment on your last point, it's seeing some light already, ripgrep is
already beating grep in performance and is purely written in rust. And i agree
that this is how rust will beat C++(if ever), by writing "better" tools than
those already exist.

~~~
jlarocco
> Coverity is expensive and majority of software people use are open-source
> which don't make use of it(hence all the CVEs).

It's definitely an area where the closed source tools are ahead of the OSS
alternatives, but there are open source (and free closed source) alternatives
to Coverity. PVS Studio, for example, has a free download:
[https://www.viva64.com/en/pvs-studio/](https://www.viva64.com/en/pvs-studio/)

> As an end user running a server, i very much care about whether my web
> server has vulnerabilities. And the promise about safety is not vague, it
> has clearly defined semantics.

You say that, yet you're still running a ton of software written in C and C++.

~~~
mmstick
> You say that, yet you're still running a ton of software written in C and
> C++.

Nice assumption. Much of the software I use is actually implemented in Rust.
And soon, I'll be using an operating system that's 100% written in Rust, with
a 100% Rust Servo-powered web browser. It's only a matter of time.

In addition, I've also implemented my servers (web server included) in Rust,
and they have zero dependencies upon C/C++ software, so your entire point is
rendered invalid.

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

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

~~~
mmstick
Rust has made major strides in the cryptocurrency industry. Cryptocurrencies
are largely becoming powered by Rust, because with cryptocurrencies, there is
no room for error.

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

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

~~~
AstralStorm
It probably will be just about as safe. The benefits of the borrow checker
only become apparent when you're doing complex things. C++ allows you to write
bad code easily though, though the most obvious modern way is safe typically.

At least until multiple threads or processes happen or you have hard realtime
requirements.

------
childintime
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?

~~~
steveklabnik
Cortex M works today, but since I'm not in the space I can't comment on
debuggers or IDEs.

~~~
AstralStorm
Rust produces quite fat code even without safeties on and when using a tiny
libc...

If you have megabytes of flash to spare, it could probably be fine...

~~~
steveklabnik
> even without safeties on

Most of Rust's "safeties" are only compile-time, and so have no effect on
binary size.

~~~
AstralStorm
Many of them cost nothing over base rust tax, but that is not the issue.

------
symlinkk
Over 30 years of momentum.

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

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

~~~
szemet
A big difference is that Rust has a zero overhead interop with C, so it it
allows mixed projects or gradual porting.

So Scala or Kotlin replacing Java, or F# replacing C# may be a better analogy.
What happens there, is that Java and C# are improving just enough that many
people are simply not considering the change... And C++ are trying really hard
nowadays too - new version with interesting features every few years etc...

(By the way - I'm a Rust fan, and also a functional programming fan, so I
would be happy if C++, C#, Java would slow down a little to let the
alternatives really catch up popularity;)

~~~
solidsnack9000
I am actually on your side on this one. But the changeover, I think you will
agree, will be somewhat slow. So no one should judge Rust too harshly, for not
replacing C++ in the Unreal Engine, Microsoft Office Suite, &al. even in the
next 5 years.

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

~~~
jjpe
While your use cases are definitely valid for you, this is not a Rust issue,
but something that's 100% decided by your distro. They decide if, when and how
they integrate Rust into it.

As for the multiple copies issue with Cargo: I generally agree with you that
this definitely feels like 1 source of major blow up in project compile times,
and it would be nice and useful if that were reduced as much as possible. But
there is a reason that this system is in place: each crate defines how it
compiles and consumes its dependency crates, so if crates A and B both depend
on crate C, then A might compile and consume C differently than B does. This
results in effectively different libraries once compiled, and ATM there is no
way to predict in advance what the effect of any given compile flag will be
since any flag can switch on/off arbitrary code. Hence Cargo keeps A's C
dependency separate from B's.

Then there's the not doubting whether an application uses the latest patches.
Up to a point, this can be automated through exploitation of SemVer: if Cargo
could figure out that a new library version is API and ABI compatible with the
previous version then I'd argue that Cargo should perhaps just auto-update it.
A bigger issue is what happens when a new major version of the library is
released, as those tend to break APIs in order to perform maintenance. That is
something that as of yet has not been automated.

~~~
flukus
> While your use cases are definitely valid for you, this is not a Rust issue,
> but something that's 100% decided by your distro. They decide if, when and
> how they integrate Rust into it.

It's a rust issue because it's up to the rust compiler to generate ABI
compatible binaries, at the moment there is no ABI so there isn't much distros
can do. It seems they have no intention of adding one any time soon:
[https://github.com/rust-lang/rfcs/issues/600](https://github.com/rust-
lang/rfcs/issues/600)

This is why system libraries are nearly always in c and not c++. The ones that
aren't (Qt) have a long history of broken language bindings.

~~~
jjpe
This is not as much as a problem as you believe. Rust is perfectly capable of
making objects that have a C API and ABI precisely for this reason, and the
most popular distros only work with supported compile targets anyway. That
said, a distro like Debian might indeed encounter some issues at this time for
the less prominent platforms eg MIPS or PowerPC based chips. That shouldn't
prevent Debian from including Rust altogether though, they merely should
exclude it on those less or even unsupported platforms.

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

------
joshAg
Time.

