
Ask HN: What is the state of C++ vs. Rust? - manaskarekar
I would love to hear the thoughts of people who have kept up with the developments in both these languages.<p>Some of the stuff I&#x27;m wondering along is features, safety, performance, simplifying the language and so on.<p>C++11&#x2F;14 brought good things to the table, perhaps C++17 will bring more improvements?<p>I havent gone through the proposals for upcoming features in either language but seems like the pace of Rust development is really good.<p>But then there is the idea of ignoring legacy C++ and treating Modern C++ as a new language altogether.<p>Just curious to hear anyone&#x27;s thoughts on the state of these two languages.
======
vvanders
Long time C++ dev here(~15 years) currently loving Rust. Someone can probably
put together a more eloquent comment however here's my top marks.

1\. No memory corruptions/null pointers. Legit holds up to the promises here.

2\. The path of least resistance is single-ownership which is far and away the
best way I've seen to structure C/C++ applications.

3\. Cargo: Pure awesome. Simply one of the best dependency management/build
tools I've used.

4\. Dead simple x-platform support. Windows, Linux, all just works. Heck I
just built an android arm-eabi target yesterday on windows with no NDK/etc.

5\. Tagged unions, pattern matching. The best effing iterator class I've seen
bar none. Once you've used these you don't want to go back.

6\. Great built-in unit testing support(combines with Cargo above).

7\. Amazing community, no ego and tons of people happy to help.

I still work regularly on C++0x11 codebases but any greenfield stuff I've
moved over to Rust fulltime.

I still like C++ but it's so much more painful to use. Heck just earlier today
I got bit by <locale> not compiling on OSX due to some obscure compiler
differences that worked on MSVC and GCC. There's certainly good improvements
coming to C++ but they have to support so much legacy code that I don't think
they could ever make the large breaking changes that Rust has to produce a
better experience.

~~~
StavrosK
I've only used Rust lightly, but can someone explain what Cargo does
differently from pip-tools?

As far as I can tell, you have two files in both systems: One with the
dependencies you'd _ideally_ like to use, and one with the ones you _actually_
used (and tested with). That way, you can update when convenient, but people
who get your software have an exact known good environment.

What makes Cargo that much better than pip-tools?

~~~
vvanders
I'm not super-familiar with pip-tools however I'll try and explain what I like
about Cargo.

You're right on the dependencies, there's a lock file to make sure you get the
_exact_ build environment. So from a dependency management perspective it
sounds similar.

What I like about Cargo is it's just _slightly_ opinionated about how you want
to build a Rust project. Creating a new project is as simple as "cargo new
myproject" and boom, away you go. Same thing with unit testing, running all
tests in a Rust project is as simple as "cargo test".

If you've worked on a moderately large C/C++ codebase you'll know that those
two things alone can be a huge source of annoyance.

It also makes it really easy to install Rust-based tools like
racer/rustfmt/etc with "cargo install <tool>" which pulls the source, builds
and puts the executable on your path.

In short, all the annoying stuff around project management that in C/C++ is
neatly handled into a few short commands. In my mind it's a huge productivity
win.

~~~
StavrosK
Ah, I see. The main difference I can see is that it's opinionated, because
everything else can be done by pip too (you can install utilities right in
your path with it).

I agree that being opinionated is a big help. Everyone in Python-land uses
virtualenv and pip, but it would be great if (as is actually happening now),
they were bundled with the language and were the One Blessed way of creating a
new project:

virtualenv myenv

source env/bin/activate

pip-compile requirements.in

pip-sync requirements.txt

Rust does get a few benefits from being statically linked, but yes, I see now
that people compare cargo to mostly C/C++ tooling, and not to something like
Python, thank you.

~~~
dpc_pw
So you want to say that some arcane chain of commands that I have to remember
is as good as `cargo run` to run `cargo install name` to install?

`pip` and Python are riddled with problems. Native modules fail to compile all
the time and since Python is so slow, it requires a lot of native code.
python2 vs python3 share `PYTHONPATH` and `virtualenv` is inheriting it:
[http://stackoverflow.com/questions/24583777/why-does-
virtual...](http://stackoverflow.com/questions/24583777/why-does-virtualenv-
inherit-pythonpath-from-my-shell) which leads to many weird problems.

Not to mention some python stuff is not available on `pip` (like PyQt, last
time I tried).

Third, how (as a user) am I supposed to reliably install and start a Python
software system-wide? With a whole `virtualenv`, or with a script that
activates it every time? And what if you want to use one python program to run
another python program and one is using python2 and other python3 etc? :D

Python software really works only in it's developer sandbox, or when very
carefully prepared by Linux-distribution maintainers. Otherwise it's a mess.

Part of the reason why Docker got so popular was because it solved an
impossible task of running several separate programs written in Python
reliably side by side, on many boxes. Since it works reliably only in
developer's sandbox, we now ship the whole sandbox and call it "application
container".

I've gave up on using any software written in Python on my boxes. I just avoid
it. Not to mention that Python software rarely works reliably...

~~~
dom0
I won't bother replying to most of what you said (bit tired), just this one
here:

> Third, how (as a user) am I supposed to reliably install and start a Python
> software system-wide? With a whole `virtualenv`, or with a script that
> activates it every time? And what if you want to use one python program to
> run another python program and one is using python2 and other python3 etc?
> :D

You don't need to activate a virtualenv to run an application from it. Eg.
some_virtualenv/bin/some_binary just works, regardless of other active
virtualenvs or what Python/Java/C program invokes that.

And maybe this bit here:

> So you want to say that some arcane chain of commands that I have to
> remember is as good as `cargo run` to run `cargo install name` to install?

The commands he mentioned would be used to _create_ a new project, not to
install anything.

------
blub
Wrong place to ask the question. HN has a high proportion of people with an
unusual interest in trying out programming languages and I would say the
average visitor doesn't particularly like C++.

From my point of view, Rust doesn't offer any benefits that would justify a
switch. I would lose a lot of experience, libraries, a mature stable platform
and job opportunities in exchange for more memory safety - something that's
not a particularly pressing issue for me.

Furthermore, I think many developers obsess about languages and keep searching
for a perfect language that doesn't exist and even if it did wouldn't have a
big impact on productivity and the business anyway. The major challenges in
organisations are of a social or process nature.

They're also biased in a surprising way by social factors such as who created
a PL or the community. Meanwhile PHP, Java, C++ and C# and C make the world go
round.

Key questions for me when evaluating whether to learn Rust (or any language):

* can I get a good job programming in this? Without moving to another country or continent.

* is my industry showing interest in it?

* is any industry showing interest?

The answer to all these questions seems to be "no".

~~~
MichaelMoser123
> I would lose a lot of experience, libraries, a mature stable platform and
> job opportunities in exchange for more memory safety - something that's not
> a particularly pressing issue for me.

May i ask why memory issues are not a pressing issue for you? having to hunt
down memory corruptions / access to dangling pointer / memory leaks is a
pretty frequent occupation for me (as a C/C++ developer). There are tools like
valgrind that help, but well, it is a pain to deal with these issues.

~~~
blub
I tend to think carefully about lifetimes, resource ownership and writing
secure code. I am careful with threading, use language idioms to enforce
safety and also use tools (such as valgrind, but also static analysis) to
check the code.

This is not as reliable as Rust's compile-time safety checks, but in practice
it works well enough for me. I don't think this is typical for all C++
projects or programmers e.g. I am not particularly impressed by the (little)
Firefox code I've seen.

I hope C++ continues to evolve safety features and get closer to Rust's
guarantees. I don't think automotive or aviation will switch too soon.

~~~
Yoric
Out of curiosity, do you have (open-source) examples of C++ projects that do
it right?

In my numerous-though-irregular years as a C++ programmers, I haven't seen any
project producing code that's convincingly safe. I won't list all the pitfalls
of C++ here, but, well, who doesn't have war stories of bugs-because-of-
aliasing, bugs-because-of-const-doesn't-actually-mean-constant, bugs-because-
pointer-is-still-being-used-after-its-mutex-has-been-released, bugs-because-
collection-has-somehow-been-mutated-during-traversal, etc? I have reached the
point where I feel I can't trust any non-trivial C++ code, so I gladly
switched to Rust for all my new non-webdev projects.

But back to the question, I would be really happy to see convincingly safe C++
subsets in action. I certainly hope that this would improve my life as a C++
developer, at least for future projects. As a side question, I wonder how many
C++ developers actually produce such code.

~~~
blub
Don't have a link to such a project, I didn't really look. I am seriously
considering starting one though, perhaps it's necessary.

~~~
Yoric
I am genuinely interested.

Also, I just realized that doing this right might require dropping lots of
legacy C++ code, more or less as would starting in Rust.

------
JoshTriplett
I find this comparison much easier than comparing C and Rust. C has an
extensive and still unparalleled set of libraries available using the C
calling conventions; both C++ and Rust can call those libraries but often want
a translation layer that adapts to the conventions of the language. C++ and
Rust both have extensive libraries of their own; while C++ has been around
longer, you'll still often find yourself needing to use a C library because a
native C++ library doesn't exist. (It doesn't help that C++ has gone through
several ABI changes, and still doesn't reliably have a cross-compiler
compatible ABI the way C does; even clang++ and g++ have had various
incompatibilities, and still prefer separate C++ standard libraries. C remains
the reliable ABI for libraries.)

While I'm impressed with the changes in modern C++11/14/17, it has both the
feature and problem of still including classic C and C++. There's a reasonable
subset of C++ to program in, but nobody can quite agree on what that is, and a
codebase can't easily enforce that. And C++ is still a very large language,
with quite a bit of surface area in the language itself; I prefer a smaller
language with a large library ecosystem.

Rust is still quite young. It's incredibly fun to program in, has the most
welcoming community I've ever seen, and can help you write safe, expressive,
high-performance code. (Tip: check out the "rayon" crate for incredibly easy
parallelism.) It has an extensive library ecosystem, and a robust FFI to call
(or be called by) C code. However, depending on what you're doing and and how
many boundaries you're pushing, you may find some corners of the language
still under active development; for instance, if you want to embed some Rust
code into a broader build system that builds various other components under
other languages, support for that _just_ went into Cargo.

If you're writing pure Rust code, or Rust code that calls out to C, you should
find the language and ecosystem ready now. If you're trying to embed Rust into
an existing project, expect to play with various experimental bits for a
while.

~~~
pritambarhate
>> I prefer a smaller language with a large library ecosystem

I think this is the reason why Java is so popular and Go is becoming
increasingly popular. The average programmer can succeed with combination and
become productive faster.

------
agentgt
This is all personal opinion so take it with a grain of salt.

I think Rust could do some serious C++ competition if it could dethrone C++
from some platform or have a worthy alternative.

That is I think Rust really needs a killer app/platform/problem similar to how
Swift has Apple devices and DevOps now have Go.

If Rust could get into a gaming platform or have a really good gaming library
like Unity it could have a good starting point to move over mind share.

Alternatively I think Rust could compete heavily with Go since the whole
microservices space is still sort of up for grabs (or atleast is so massive
that there is plenty of pie to be had).

Rust's current niche (ie users) is language aficionados which historically
hasn't been a good niche (ie Haskell) for language propagation. That is I
think Rust could get more popular if it can get heavily used by a set of niche
users at first.

Besides mircoservices and games an interesting niche might be Arduino and IOT
[1]. That might be a good niche/platform to dethrone C++.

[1]: [http://jakegoulding.com/blog/2016/01/02/rust-on-an-
arduino-u...](http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-uno/)

~~~
mi100hael
> Alternatively I think Rust could compete heavily with Go since the whole
> microservices space is still sort of up for grabs (or atleast is so massive
> that there is plenty of pie to be had).

I think you're wrong about this one. Go has a ton of HTTP libraries that make
it dead simple to get a web service up and running with all the features you'd
expect like pattern-matching URL routing, database backends, sessions, etc.
Building something in Rust would be much more painful.

~~~
kornholi
Surprisingly, it's already not that painful. I recently wrote a tiny JSON
service with Iron and Diesel and it wasn't that much longer or complex
compared to Go. The biggest headache was figuring out how Diesel works, and it
would have been a lot easier using raw queries with something like rust-
postgres (which would be the way to go in Go or Node). Once the ecosystem
matures a little bit more I don't see why Rust would be a bad choice.

~~~
tmzt
Macros 1.1 should make working with Diesel easier for the programmer, compared
to the incompatible compiler plugin APIs.

I think the sweet spot with rust might leveraging metaprogramming, for
instance, generating a REST database API from a schema and having the
resulting code compile to something faster the most languages like python or
ruby, and at least on par with Go, Java, or swift.

------
peterhj
Rust has been pretty critical to me for getting my work up and running with
minimal debugging (I'm in CS grad school, working on deep learning and
optimization). I'm super productive programming in Rust, which is also
generally a pleasure to write in.

Just last week I had to land a pretty major refactoring (swapping out a single
wrapper type for a differentiable "operator" with an implicit operator graph
instead). It basically just worked out of the box as soon as I got it to
compile. Definitely something to be said for working _with_ the compiler and
its messages on moving, borrowing, mutability etc. (Incidentally, if I had to
program exclusively in C++11/14, thanks to Rust I'd have become much better at
programming in C++.)

~~~
thecity2
Curious since you say you work on deep learning/optimization. I'm a data
scientist who does most everything in Python, but I've been interested in
learning Rust. What is the state of "data science" toolkit for Rust at this
point? For reference, I regularly use sklearn, Pandas, and Spark and would be
looking for similar tools.

~~~
peterhj
I'm not sure that there's a mature Rust alternative to "all of the above"
quite yet. Some things that I've had to build for my own work (not always
"built," sometimes I just wrote FFI bindings) include:

* N-D dense arrays, fashionably simply called tensors these days ;) (this I wrote from scratch to suit my own needs, but there are several implementations of this in Rust, as well as in C++)

* linear algebra (bindings to BLAS, LAPACK etc.)

* numerical integration (bindings to GSL or QUADPACK)

* optimization and machine learning (this I work on day-to-day)

* neural networks (I also work on this)

* multicore/manycore/GPU/distributed support (and this)

There's also the more practical aspects of using Pandas/iPython
(Jupyter)/Spark for data science, including ETL, interactive work, and
plotting, which IMO are not quite there yet in the Rust ecosystem. But I think
that a lot of the pieces are there, e.g. bleeding fast CSV parsing libraries
([https://github.com/BurntSushi/rust-csv](https://github.com/BurntSushi/rust-
csv)), and what's left is the important last mile of bringing these things
together in ergonomic libraries or frameworks.

------
dpc_pw
I am/was a embedded dev, been using C/C++ since ... more than 15 years. I do
C++/Go at $dayjob and I'm in love with Rust.

I've written quite a bit of comments before on Rust, since it's not the first
time someone asks similar question. You can read my past comments:
[https://news.ycombinator.com/threads?id=dpc_pw](https://news.ycombinator.com/threads?id=dpc_pw)

Just to sum up, IMO: Rust blows C++ out of the water on almost everything.
It's not established enough so there are almost no jobs, and there's a
learning curve, lack of tools, slow compilation, business reasons, etc. so you
can't just blindly use Rust over C++, but when you can and have time to learn:
go for it. The existing tooling is amazing, community is awesome, you will
learn really interesting stuff, save time on debugging.

As for C++17 features... I don't really care anymore. C++ is death by
thousands little cuts (undefined behavior is my "favorite") it's not going to
change much anyway.

------
pjmlp
My favourite languages are from the Wirth and ML family of languages, so I
really like Rust.

On my daily work I get to use JVM, .NET and C++.

Although my C++ usage is restricted to giving a little help to JVM or .NET
applications, if at all required, which happens very seldom.

Here is where I still see Rust lacking, due to the language being young.

On those platforms the vendor's tooling supports mixed debugging, out of box
integration with their platform libraries and a few other goodies.

For example, for UWP applications Rust tooling is still catching up with
C++/CX and C++/WinRT.

Modern C++ does feel like a rejuvenated language, but the problem is that you
require a team that is willing, or able, to force it across their code.

Otherwise you just get a mix of C++98, C++03, C++11, C++14, C++17, depending
on which library you are looking at. Not to mention having to get your head
around meta-programming tricks like SFINAE, as workaround for many of the
C++17 features.

So although Modern C++ feels good, there is the question when one takes a C++
at random company X, how much they are allowed to actually use from it.

So I think a reboot into new systems programming languages is required, and
Rust is one of the possible candidates.

Which will surely get its place.

------
throwsincenotpc
> But then there is the idea of ignoring legacy C++ and treating Modern C++ as
> a new language altogether.

There is no "ignoring legacy C++", when you will have to deal with this or
that library written 10/15 years ago. C++ is a language where you can't just
ignore some parts of it just because they are inconvenient.

As for C++ vs Rust, Rust is memory safe, C++ is not and will never be despite
all the bells and whistles it gets.

~~~
ar15saveslives
What is "memory safe" for you? If you use C arrays and raw pointers in your
C++17 code, it's definitely not memory safe, but the main problem is that it's
not modern C++.

~~~
steveklabnik
Even modern C++ isn't memory safe. Most straightforward example is to move a
uniq_ptr, which makes it a nullptr, ready to be dereferenced and cause UB.

~~~
ar15saveslives
How does it happen? Non-const unique_ptr& used as a function parameter?

~~~
steveklabnik
[http://www.steveklabnik.com/uniq_ptr_problem/](http://www.steveklabnik.com/uniq_ptr_problem/)

~~~
ar15saveslives
I can simplify your example:

    
    
      unique_ptr<int> p;
      auto n = *p; // C++ kills!

------
rlnunes
I have a big C++ legacy code, and it gives me a lot of headhaches. I'm using
Rust in some small projects and it's great, no problens with null pointers :).
I think a great feature of Rust is that it is easy to use inside C/C++
projects, so u can upgrade your current legacy code without rewrite it :)

~~~
xjia
Do you mean C/C++ and Rust interop? Maybe link them together to form the final
executable binary? Can you share more experience on how do you do that?

~~~
bluejekyll
Rust produces standard linkable system libraries. You can produce dynamic
libraries or static libraries on all supported platforms.

For actual examples of using Rust with other languages through these libraries
this site is great: [http://jakegoulding.com/rust-ffi-
omnibus/](http://jakegoulding.com/rust-ffi-omnibus/)

~~~
computerphage
More information about platform support can be found here: [https://doc.rust-
lang.org/book/getting-started.html](https://doc.rust-lang.org/book/getting-
started.html)

------
seren
Rust is promising but C++ is here to stay.

If you have a legacy C++ code base, it is much easier to sell that you are
just upgrading the compiler to get new language features, that you are
rewriting everything from scratch.

Now we'll have to see in the next few years if, for new projects, Rust is
chosen over C++ wherever it was used traditionally and in which proportion.

~~~
bluejekyll
Like all legacy code, it will not be replaced. Now if people wanted to
bifurcate their codebase they can easily add Rust libraries to existing C++
codebases.

In my experience I find Rust to be more productive than C++ and easier to
write. Obviously that's a pure opinion.

~~~
Someone
_" they can easily add Rust libraries to existing C++ codebases."_

Is that truly easy? I would expect all kinds of incompatibilities that would
require going through a C layer (object layout, difference in virtual method
calling, object ownership, etc). For example, calling a C++ function that
takes a pair of iterators from Rust and returns a std::map, passing iterators
pointing into a Rust hash table, is that _easily_ done?

~~~
bluejekyll
Well, it depends on the strategy you use, but yes, you're right that it's hard
to share strict/objects. But if the API boundary between the two is kept
simple and small, then it's simple.

Take a look at the rust ffi omnibus that I posted in this thread. It's object
examples show some decent strategies.

------
AshleysBrain
I have a large existing C++ codebase but haven't worked in Rust yet. But from
what I've seen, Rust looks like a very well designed language that has the
low-level and performance aspects of C++, with similar flexibility. IMO the
killer feature is the borrowing mechanism which provides provably-safe memory
access, eliminating whole classes of memory/security bugs, with minimal
performance impact. I don't think C++ will ever expand to encompass that. I
haven't got much experience with the Rust toolchain but I think that's a
strong reason to seriously consider Rust for any new projects.

------
jdc2172
Hope I don't get burned for saying it, but lack of real IDE support in rust is
pretty annoying. With tools like racer you can still be productive, but things
like rename refactoring or searching for uses of functions are things I miss
most from languages like Java or go, which have good support.

There's been some talk for a long time of a rust oracle for code indexing (to
support ide use), but there hasn't been much progress (or interest?).

~~~
steveklabnik
There was just a huge announcement yesterday:
[https://news.ycombinator.com/item?id=12739015](https://news.ycombinator.com/item?id=12739015)

------
fiedzia
Features and libraries aside, Rust (compiler and language) has 6-week release
schedule, open and well-working update process and 0 decades of backward
compatibility to satisfy. I don't see C++ improving on that anytime soon.

~~~
sitkack
Rust has 0.1 decades of backward compatibility to satisfy.

------
bjourne
C is still significantly faster than Rust which follows that C++ is too. So
unless Rust is able to produce binaries on all major platforms that are as
fast as C++, people who need to squeeze out as much performance as possible
are not going to drop the language.

~~~
dpc_pw
Rust will be if is not already faster than C. Especially in real-life
projects. One example would be
[https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)

Aliasing rules in C make some optimizations not possible in C. Good luck
putting that `restrict` everywhere to compensate. Generics with static
dispatch makes it possible to get a code that is way better than what a sane
person can write with C's preprocessor. Practical developer will very often
sacrifice performance for sanity in C codebase. Memory safety makes it easy to
write correct, reliable multithreaded programs in Rust and actual package
manager makes it practical to reuse well-written and optimized code.

Even if there are some microbenchmarks where C gives better results, it's
because Rust version doesn't "cheat" by using `unsafe` constructs. Essentially
in Rust one can write functionally exactly same code that C uses, including
inline asm etc. which is useful for performance-critical libraries that wrap
it in safe abstractions, but would be frowned upon in a tiny synthetic
benchmark program that is supposed to benchmark idiomatic code.

~~~
bjourne
It is not already faster and there are benchmarks that proves that. Check out
of the The Computer Language Benchmarks Game, for example. Lots of language
communities make the claim that "their" language either is or will eventually
be faster than C. Haskell, Julia, Go, Java, Swift... But the proof of the
pudding is in the eating and so far none of these safer languages has beaten
C.

~~~
steveklabnik
There's been a lot of variance on the benchmark game lately since things are
so close; a couple of months ago, Rust was #2 overall, beating out C++ and
just a tad slower than C. The areas where Rust lost the most were because
explicit SIMD isn't stable yet. We also upgrade LLVM regularly, and that can
cause some fluctuations from time to time.

(Rust is currently beating C on one benchmark, within a few tenths of a second
on a few more, and then way slower on the SIMD-reliant ones)

~~~
bjourne
But the OP asked "What is the state of C++ vs. Rust?" and I answered "C is
still significantly faster than Rust which follows that C++ is too" That is
still true because we are discussing the _current_ state of the languages and
what you wrote does not affect that.

Btw, the last time this topic was discussed we measured the performance using
a microbenchmark. Here is the C version:
[https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9...](https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9e5b7)
None of the Rust aficionados were able to produce a Rust program (using the
nightly build of Rust even) that came close.

~~~
steveklabnik
Yes, but you then also went on to say that no language will ever do it. Rust
_has_ consistently beaten C on many of these benchmarks in the past, and
continues to remain very close in the ones that it's not.

I actually don't think microbenchmarks are a good way to think about
performance anyway. There's two reasons:

First, Rust's safety guarantees let you get away with more dangerous things.
Consider scoped threads, or non-atomic reference counting.[1] You _could_
write this in C, and you'd do so for a microbenchmark, but not for a real
codebase, as it's far too dangerous. Or, you might do it, but end up with bugs
that you don't detect, that aren't there in the Rust version.

1: [http://blog.faraday.io/saved-by-the-compiler-
parallelizing-a...](http://blog.faraday.io/saved-by-the-compiler-
parallelizing-a-loop-with-rust-and-rayon/)

Secondly, microbenchmarks are often "can the best person at language X write
something faster than the best person at language Y"? I don't think that's
nearly as interesting as "When an average programmer of languages X and Y
write a program, which is faster?" Rust's default patterns and style is
already extremely fast. It's not a guarantee, mind you, but for real-world
usage, it's the average case that matters more.

~~~
bjourne
No, I didn't say that no language will ever beat C. I can't predict the
future. Rust has not beaten any highly optimized microbenchmarks that I know
of. Like it beats C on the mandelbrot benchmark, but is then beaten by Swift,
suggesting that the C implementation isn't very good
([http://benchmarksgame.alioth.debian.org/u64q/performance.php...](http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot)).

The reason we have micro benchmarks is because it is so hard to reason about
the average case. Yes, code written in Rust could on average be faster than C
due to its safety features. But so could Python, Java or Haskell so we're back
were we started and can't say anything about relative language performance.

It's a small niche, yes, but some people absolutely need to squeeze out every
gram of performance, and they should continue to prefer C over Rust.

~~~
igouy
(The C Mandelbrot program is considerably less extreme.)

------
alexnewman
They are both great languages but rust is clearly the one that experts in both
generally prefer. I have some friends who make some strange arguments for c++
but I continue to be interested why people don't want to make the switch. That
being said LEGACY

~~~
sidlls
I have just a couple of points.

First, please be careful with the "experts" broad brush. Not all, and possibly
not most, experts will agree on many things. Moreover, actual experts will
understand that there are pros and cons that are context dependent. I would
hesitate to label as "expert" anybody who categorically prefers one over the
other for all cases. That's more like zealotry than expertise.

Second, for my part the biggest hurtles are in two parts. One is that at the
boundaries of speed versus provable safety. At some point I don't need and
can't afford the cycles added by boundary checks and other Rust guarantees,
and the mechanisms provided to mitigate them are as cumbersome as writing
(unprovably) safe C++ code (e.g. "const&", "std::move" and other similar
constructs) compared with the equivalent Rust. The other is a more a branding
problem: gratuitous maligning of C++ is problematic, and projects a sort of
arrogance that I find subjectively distasteful.

~~~
dbaupp
The Rust team puts a lot of effort into _not_ gratuitously maligning anything,
including a "competitor" language like C++: discussions of other languages try
to be as factual as possible, and, Rust is very happy to adopt the good ideas
of them (and of course acknowledge this), e.g. Rust's closures are modeled
after C++11's lambdas.

As with anything, some people who like Rust might get a bit enthusiastic about
discussing its benefits compared to other languages, but this is frowned upon
and IME usually called out, especially in spaces with some sort of "official"
Rust moderation presence.

~~~
shermanyo
> The Rust team puts a lot of effort into not gratuitously maligning anything

Anecdotally, Rust developers are the only group I've interacted with that
consistently focus on the positives of other languages when discussing
different features or concepts, while acknowledging the tradeoffs and clearly
outlining the reasoning behind Rust's choice.

