
Ask HN: Will Rust replace C/C++? What's holding it back? Are you using it? - aerovistae
I just wonder if it will become the language of choice for things like game development and embedded applications in the future, and I wonder if people are already starting to use it for these purposes, and I wonder why people so far choose <i>not</i> to, if indeed that is their choice.
======
jungler
Rust is good at solving certain scaling issues in large applications: Servo,
the lead usecase for Rust, can safely take many parallelizing optimizations
that would be unfeasible to debug anywhere else.

That does not make it a defacto winner for any other problem space. For games,
for example, having to reason about concurrency is the status quo for most of
the gameplay code regardless of the memory management system, and tightening
memory only addresses a fragment of the problem space, because dynamic memory
allocation is not a primary requirement(fixed sets of assets and fixed design
constraints mean that a heavily static, early-binding approach to game coding
works for most things, most of the time - so the difficult errors will tend to
surface outside of memory management as an odd runtime behavior). [0]

As a drop-in "better C" it's not a great fit, either, because the focus is on
making these in-the-large problems a top concern at all times. It creates
friction in migrating to Rust, leaving the floor open for a smaller language
that operates at the lowest levels of safety, doing its best to be both
C-compatible and improve the parts that can't be addressed by leveraging or
patching up the existing C ecosystem.

Zig is my top pick for a language that can address this niche, though it's
still an early stage project.

[0] AAA-scale code can still benefit, of course. Most games aren't AAA.

~~~
eridius
Rust’s solution to concurrency is a hell of a lot more than just solving
memory management. As long as you avoid `unsafe`, Rust statically prevents all
race conditions. Rust also makes it so if you _can_ parallelize something,
then you’ve proven that it’s _safe_ to parallelize it, and therefore you can
parallelize complex systems in Rust that you simply wouldn’t have the
confidence to do with other languages.

~~~
steveklabnik
Rust prevents data races, not race conditions.

~~~
eridius
You're absolutely right, I meant to write "data races" there.

------
yakubin
I work as a C++ programmer. I would love to switch to Rust, but:

(1) To my knowledge, it has only one implementation, which isn't surprising,
given there is no spec, so basically there is nothing to reimplement. As
@sircmpwn put it:

> Rust doesn't have a specification > Therefore all Rust code is undefined
> behavior

I mean, if something isn't specified in the docs and the compiler changes its
behaviour in this area, is it a bug? There is no spec, so nope, but your
program may still start malfunctioning.

(2) It has a lot of features, looks very complex, and complexity is something
I want to avoid after seeing how ugly C++ can get.

(3) For now, there are more libraries available to use for C++.

(4) I don't follow its development very closely, but, from what I've seen, it
changes pretty fast for a programming language and it's not something I like
(in programming languages).

So for now I will continue learning more Python and perhaps in the future I'll
look at Rust again.

~~~
steveklabnik
There is a second implementation of everything but the borrow checker.

> I mean, if something isn't specified in the docs and the compiler changes
> its behaviour in this area, is it a bug?

Since Rust is so strongly typed, we _do_ have strong rules for many kinds of
changes, even if there's no formal specification. That can only help with some
things, but it does help a lot.

> it changes pretty fast

The key here is that the changes are _additive_ , that is, we don't make
egregious backwards incompatible changes. We _do_ sometimes for things like
soundness fixes, but even then, we have tooling to estimate the impact of
breakage on the ecosystem, and have strategies for easing that pain. Most
users report that their code never breaks, and virtually all of the users
whose code has broken report that it was trivial to get building again.

~~~
now
gets

~~~
steveklabnik
I’m not sure what you’re saying exactly. You’re referring to the inherently
dangerous c function?

------
nickm12
Though I haven't programmed in it beyond toy problems, Rust is exciting
because it actually has an answer to the question of "why would you use this
instead of C/C++ for systems programming?" and the answer is memory safety,
concurrency, and rich, no-cost abstractions. It also has a good story for
interop with C.

Having an answer to that question is necessary, but not sufficient. There's
also a lot to be said for being in the right place and the right time---who'd
have thought in the early 2000s that Objective-C would suddenly become a hot
language? Killer apps like the iPhone can make a huge difference.

It's still early days. Industry standard languages have lifespans on the order
of decades; C is rougly 45 years old, C++ roughly 35 years old. I think Rust
has a chance, but we won't really know until it's a decade old.

~~~
bpicolo
Only 2 years off ;) Time flies

~~~
coder543
1.0 was 2015.

~~~
aleph-
Yeah but overall it's existed for 8~ years.

------
flukus
The two big ones for me (neither of which apply to games or embedded) are the
lack of a stable ABI and the over reliance on cargo this causes. These two
make rust more of a platform like c#/nuget and js/npm than a replacement for c
and c++, no to mention the extra bloat and security issues they cause. I want
my system software to work with the system, not add layers of duplication on
top of it.

The rust community has no desire to address either of these.

~~~
jononor
What's the problem with a good integrated package manager? I mean, one can
choose to not use it. Is it curated single-source libraries ala Boost/Qt you
miss, or something else?

~~~
flukus
> What's the problem with a good integrated package manager?

The problem is that I already have a better one and things like security
patches get back-ported to it. I get to make managing that a job for the
distro maintainers but with cargo it's my problem. As a user I have absolutely
no control or visibility of what versions of dependencies are in there.

If I choose not to use it then there's not much point to rust in the first
place, I have to work with everything through c interfaces.

Then of course there's the binary bloat. All-in-all cargo is just putting
developers needs before users.

~~~
wtetzner
You seem to be mixing up distro package managers and language package
managers.

Distro package managers don't let you do versioning in any reasonable way,
_and_ they are OS-specific, so they are not good for versioning dependencies
of a software project. In particular, if you want reproducible builds, you're
out of luck.

> As a user I have absolutely no control or visibility of what versions of
> dependencies are in there.

Which is also true of header-only libraries for C, or vendored dependencies.
While sometimes shared libraries are used by projects, it's certainly not the
only way dependencies are handled in C/C++ land.

The only reasonable solution I see to combining a distro package manager with
a language package manager is the nix package manager...if only it was more
cross platform. As it is now, it only supports Linux and macOS.

------
peapicker
I can’t use it my workplace because it doesn’t support platforms my product
requires. (In addition to Linux and Windows, I have to support AIX, HP-UX,
Solaris, and OS/400). If Rust were more portable/ported I could start to
consider it. For now that means I’m sticking with C++, C, and Java which work
all those places.

~~~
jjnoakes
I'm in a similar situation. I am cautiously optimistic that "mrustc" can help
in this area. Compiling rust to C++ seems like the right direction for the
more esoteric operating systems and platforms.

------
TillE
My litmus test for Rust ergonomics is when they implement named arguments.
They're still not there.

Rust does some things well, but too many times I've gone looking for a Rust-y
way of doing something I can comfortably accomplish in C++, and found the
answer was inadequate or convoluted.

~~~
pjmlp
Using Ada then?

------
nineteen999
There was some discussion of it on the "C conferences" thread a couple of
hours ago. Steve Labnik posted some links to discussions around it's use at EA
etc.

[https://news.ycombinator.com/item?id=18505307](https://news.ycombinator.com/item?id=18505307)

Personally I think it's a bit early for Rust to displace the incumbents there,
but if any modern language has a chance, it's probably Rust IMHO. Consider one
of the largest and most popular game engines right now (UE4), that's a huge
codebase and rewriting it in Rust at this point doesn't make a lot of
financial sense, even if it could technically be done.

It seems to making some inroads in the embedded space from what I can tell
too, but rustc will need to have a wide range of architectures supported
before it can replace C/C++ there too.

------
kstenerud
I'm waiting for native support for primitive int, ieee 754 binary float, and
ieee 754 decimal float types in 32, 64, and 128 bits. Not classes. Not
structs. Actual primitive, interoperable types like c and c++ have.

~~~
GolDDranks
Rust has everything in your list expect for IEEE 754 decimal float types and
float types in 128 bits. Is the lack of those two holding you back?

Rust's primitive types such as i32, u32, u8, f32 are interoperable with
foreign functions.

~~~
kstenerud
Yes, I'm dealing with binary formats containing binary and decimal floating
point in various sizes. I also sometimes need to talk to C APIs that take
_Decimal64 and friends. Rust's interoperability is hampered by the lack of
basic types.

------
ncmncm
There is no language called C/C++. There is C, and there is C++. The answers
are qualitatively different for the two languages, so conflating them, in any
context, can only ever produce confusion, noise, and misery.

The answer is that C++ is replacing C anywhere C is not dug in too deeply --
mainly OSes conceived long before C++ stabilized, and specialized embedded
environments where manufacturers are actively hostile to change. Rust is also
replacing C, in the same places, but of course still overwhelmingly more
slowly. In a few places, Rust is used where C++ would have been, such as in
Mozilla's page rendering, but the difference between Rust's and C++'s
expressiveness is not, generally, big enough to overcome structural drivers.
Both are so overwhelming better in every conceivable way than C that only
inertia maintains any remaining niches for C. It is just so overwhelming
better to code Rust or C++ than C, and so much very much C, that there is no
need for either Rust or C++ to see the other as competition.

In the future, Rust and C++ may come into competition, but today it is more
like motorcycles vs tractor-trailers. (Back in the '90s Jonathan Schwartz
compared C++ to another language, saying if the other was like a seaplane, C++
was more like a boat anchor with feathers.) C++ still has historical baggage
Rust lacks, but that is changing. C++ is getting better very fast, so that
Rust is chasing a moving target.

~~~
pjmlp
> There is no language called C/C++.

I love how people are pedantic with a term that the respective ISO members use
on their official communication. Just go search the mailing lists and papers.

Oh, and then there was the "The C User's Journal" that got renamed as "The
C/C++ User's Journal" when C++ started to be adopted across all C compiler
vendors.

C/C++ is just an abbreviation to _C and C++_.

~~~
hawski
Practically C/C++ means C++ and sporadically C++ first and C second. When you
see a job offer for a C/C++ programmer you can safely assume that nobody cares
for the literal C part. It all depends on context, in this case I agree with
you.

------
pjmlp
Having been an earlier C++ adopter, I have grew with the language and witness
how it struggle to take over C use cases, and there are still areas where it
isn't the case.

So from my point of view, for game development, until there is an engine
comparable to CryEngine, Unreal, Unity, Godot, Rust will be playing catchup
with productivity from C#/C++ workflows.

For embedded applications, even C++ struggles there, as there is a large
community that won't move beyond C89 + language extensions + Assembly, no
matter what.

C++ is able to get market share there, because some certification standards
now require C++14, e.g. AUTOSAR, and there are OSe like ARM mbed, fully
written in C++. So those devs have no choice when landing in such projects,
either accept the language or move to somewhere else.

For general app development, Rust lacks the integration that C and C++ enjoy
across XCode, Android Studio and Visual Studio for mixed mode debugging,
integration into the official toolchain and GUI tooling.

For example, creating UWP/COM controls on Windows to be used from .NET
applications and stepping through them with a debugger, or creating a native
library on Android to be called from Java/Kotlin, while being able to debug it
on device and track down a performance problem via the Android Studio
monitoring tools.

Surely you can make it work, but right now, it makes what is already sometimes
a hard task, even more complex.

~~~
solarkraft
> So those devs have no choice when landing in such projects, either accept
> the language or move to somewhere else

Doesn't it supposedly have great interop capabilities?

------
axilmar
C++ programmer here.

I've been tempted to use Rust in my personal projects, but I have yet to find
a reason. Even in complicated stuff, I usually write C++ code (not C) that
needs few iterations to be without errors.

But I have good experience with C++ and concurrency...I haven't used raw
pointers for example from 2006...I wrote my own smart pointer library which I
used until all major compilers supported smart pointers (boost was always
there as a back up).

That, and the lack of OOP in Rust, has made me avoid it so far.

I think Rust will shine in projects with a varying degree of experience in C++
development. It can certainly improve safety over the large programs written
by large groups, because it's impossible that those large groups will be
filled with extremely experienced programmers.

------
ramtatatam
I used Rust for my toy project and I liked the concept of borrowing. For me
personally it felt a little bit like crossing of C++ and Python - all static
typing and, curly brackets and semicolons (I honestly like it) and growing
number of packages available through cargo (which seems somewhat similar to
pip, however still not very popular). All in all my toy project is not super
complicated (although I think domain problem is quite interesting) but I found
Rust fit for the purpose and quite enjoyable to use. I'm running on Linux only
so I had no problems with cross-compilation (as some mentioned they had).

------
orcy
I am considering starting a project, and I am finding myself to be more likely
choosing C++ over Rust. Lot of libraries like platform SDK, libs like skia,
openssl, etc are c++ based. So by choosing the C++ I am having the consistent
source code environment, that makes benefits in things like building, code
editing and debugging.

------
mbrodersen
A programming language exists within an ecosystem of
libraries/developers/companies/jobs/... It will take a looooooooong time for
Rust to match the huge size and breath of the C/C++ ecosystems. It might
actually never happen.

------
adamnemecek
Yes, some people will switch however I believe that they will exist in
parallel. It's funny how there is so much overlap between languages (say
Python & Ruby) yet both are still very popular.

------
bhengaij
Rust needs an IDE

~~~
jbit
Rust has a lot of good IDE options these days:
[https://areweideyet.com/](https://areweideyet.com/) They decided to focus on
the "Rust Language Server", which many IDEs use, rather than on one specific
IDE.

~~~
geezerjay
That list counts vim and emacs as IDEs, and also includes in the list sublime
text and vscode.

In the end the only minimum working product IDEs they list (no debugging, no
IDE) are vscode, eclipse, visual studio, and intelij.

AFAIK Eclipse does not support rust. At best there's a plugin that adds some
support, but last time I've checked it failed to work on my setup. That
doesn't leave many viable options on the table.

~~~
steveklabnik
> AFAIK Eclipse does not support rust. At best there's a plugin...

I'm not an Eclipse user, but in my understanding, it's grown quite a bit since
then.

[https://www.eclipse.org/org/press-release/20180627_new-
photo...](https://www.eclipse.org/org/press-release/20180627_new-photon-
release-of-eclipse-ide-ships-with-full-rust-support.php)

[https://projects.eclipse.org/projects/tools.corrosion](https://projects.eclipse.org/projects/tools.corrosion)

