
Rust is not a good C replacement - ddevault
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
======
steveklabnik
There's a lot of stuff I could say here, but I'll stick to

> Attempts to integrate it with other build systems have been met with
> hostility from the Rust & Cargo teams.

This is _very_ much not true. We've put in a ton of work to support this.
Arguably, we've put in too much design work and not enough implementation
work; we've had a few different attempts at making this work even better than
it does today, and we haven't finished them up. But this is very much
something that is cared about and desired by the team.

It was literally on the 2017 roadmap: [https://blog.rust-
lang.org/2017/02/06/roadmap.html](https://blog.rust-
lang.org/2017/02/06/roadmap.html)

> Rust should integrate easily into large build systems. Plans include working
> with large companies incorporating Rust to understand how best to equip
> Cargo to smooth the process.

I don't know how this is framed as "hostility".

As one example of the work done here: [https://github.com/rust-
lang/cargo/issues/5579](https://github.com/rust-lang/cargo/issues/5579)

~~~
ddevault
Thanks for sharing your perspective. My comment was largely based on this
discussion:

[https://github.com/mesonbuild/meson/issues/2173](https://github.com/mesonbuild/meson/issues/2173)

If you'd like to share a short summary of your thoughts, I'll update the
article with your commentary.

~~~
bluejekyll
I didn’t read the entire thread, but if I understood the gist of it, it seems
like an anti-pattern is being asked for, and it would be an anti-pattern when
mixing any languages. What it seems they want is the ability to mix Rust and C
in the same build chain, not treat each as a separate build artifact and link
at the end.

I’ve never had a problem modeling things with Makefiles, having the Rust
artifact target be built by Cargo and then linking with the standard toolchain
for C in the Makefile.

I’m clearly missing some context, as this works really well.

~~~
steveklabnik
Yes, there's a ton of ways that you can do this. Most successful integrations
thus far have done exactly that: you have a target for your Rust code, it
calls out to Cargo and does its thing, and then links it in. I believe that
you're right that the Meson folks want to use rustc like they use cc, and use
Meson for all of the stuff that's not "compile this, please."

This can work well as long as you're writing all of your own code. The issue
is that most people like Cargo, and like using Cargo, and so virtually all
open-source projects are built around Cargo. This is not unlike if you're a
Meson fan, but you want to use an open source project that uses CMake for its
build, and so it's only really set up to use CMake. (At least, in my
understanding.)

~~~
bluejekyll
Well, then the comment they made about essentially rewriting Cargo is probably
accurate.

Doesn’t seem like it’s a valuable contribution to their end goal though.

I do want to point out (for others, you know this) that Cargo has a lot of
environment variables that can be used to improve its usage inside other build
systems, e.g. using a shared target directory for reusing compilation of
dependencies: [https://doc.rust-lang.org/cargo/reference/environment-
variab...](https://doc.rust-lang.org/cargo/reference/environment-
variables.html)

~~~
steveklabnik
Right, that's why we introduced the build plan feature, so that you don't have
to re-implement Cargo, you can use Cargo to spit out the stuff you need
instead. :)

------
beders
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of
> these problems, I’ll take my segfaults and buffer overflows. I especially
> refuse to “rewrite it in Rust” - because no matter what, rewriting an entire
> program from scratch is always going to introduce more bugs than maintaining
> the C program ever would.

And that is why we can't have nice things.

"I don't really care" if someone overflows my buffer to execute code...

And: "going to introduce more bugs" \- false. Empirically complete bollocks...

~~~
jimmy1
I would say if you rewrite it and have _more_ bugs, you must have no
understanding of the existing codebase, or understand so little of it you
shouldn't be the one rewriting it regardless.

All the rewrites I have done have resulted in leaner codebases with fewer
potentials for bugs. I think people take some article one software developer
wrote almost two decades ago as gospel, but "second system syndrome" doesn't
have to be a syndrome.

This "rewrite" fear is exactly why our banks are stuck on 1970s and 80s code
with an almost 60 year old programming language and no one left to take over
maintenance. Eventually we need to get over this fear.

~~~
michaelt
I guess you disagree with the likes of [1] then. Presumably it depends on the
age and complexity of your project.

[1] [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

------
wyldfire
> C is the most portable programming language.

This is a function of popularity and time.

> C has a spec. No spec means there’s nothing keeping rustc honest.

Agreed, language specification is critical. The language reference [1] is very
detailed, though. I'm not sure what it would take to promote this to a
"specification."

> That really cool feature $other_language has? Not interested. It’ll be more
> trouble than it’s worth

Binding to "editions" is a reasonable way to get stability, IMO. It's a shame
that this wasn't adopted earlier.

> Concurrency is generally a bad thing.

So don't leverage it. Don't use fork() or clone() either and we'll all agree
to ignore this point.

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of
> these problems, I’ll take my segfaults and buffer overflows.

Here underlies the crux, you should have led with this. This is a sizable
portion of rust's value proposition. If you don't value it then it's likely
not to measure up well.

> Rust will eventually fail to the “jack of all trades, master of none”
> problem that C++ has.

We have to take the good with the bad in everything, right? If Rust's future
is "spectacular failure like C++" then it's probably going to be a wild
success.

[1] [https://doc.rust-lang.org/1.0.0/reference.html](https://doc.rust-
lang.org/1.0.0/reference.html)

~~~
ddevault
>This is a function of popularity and time.

Correct, both of which you have to take into account when picking a
programming language _today_.

>We have to take the good with the bad in everything, right? If Rust's future
is "spectacular failure like C++" then it's probably going to be a wild
success.

I wouldn't call C++ a wild success. It's failed to supplant C for its entire
life, and thrives only in a few niches.

~~~
jhasse
> I wouldn't call C++ a wild success. It's failed to supplant C for its entire
> life, and thrives only in a few niches.

Aren't web browsers one of the most used consumer software today? I wouldn't
call them niche.

~~~
ddevault
I was measuring by number of projects. Consider that most web browsers also
depend on a dozen or more C libraries.

~~~
jhasse
> I was measuring by number of projects.

I think even going by that metric C++ does pretty good.

Not exactly "number of projects", but here are some numbers:

GitHub statistic:
[https://octoverse.github.com/projects.html](https://octoverse.github.com/projects.html)
C++: 5th place C: 9th place

StackOverflow survey:
[https://insights.stackoverflow.com/survey/2018/](https://insights.stackoverflow.com/survey/2018/)
C++: 10th place C: 11th place

> Consider that most web browsers also depend on a dozen or more C libraries.

That just shows that C is a wild success, too ;)

~~~
Sir_Cmpwn
I don't think that metric is fair, either. A large number of C users don't use
Github nor SO.

~~~
jhasse
True. Still it's enough data to show that C++ is a wild success and is used
more than just in a few niches.

Has it supplanted C? Definitely not. But in some areas it did (e.g. game
development).

------
clouddrover
> _But now you know why we are still writing C, and hopefully you’ll stop
> bloody bothering us about it._

I don't think anyone will stop bothering them about it until C software
security improves. Microsoft found that 70% of security bugs in their software
were memory safety issues:

[https://www.zdnet.com/article/microsoft-70-percent-of-all-
se...](https://www.zdnet.com/article/microsoft-70-percent-of-all-security-
bugs-are-memory-safety-issues/)

Languages like Rust are making an effort to address these issues. What's the
roadmap for reducing the number of security flaws in C software?

~~~
jabl
> What's the roadmap for reducing the number of security flaws in C software?

Thoughts and prayers.

~~~
sseagull
A little controversial, but I would have liked the larger programming
community to address this rather than write completely new languages.

Think of all the effort that has gone into rust. Compilers, package managers,
libraries, etc. What would have happened if that same effort went into better
analyzers, linters, compilers, etc, for C/C++? Rather than rewriting
everything to be made "perfect" (which will never happen), this would be
applied to the metric shit ton of existing code, making it better. Not
perfect, but better.

Of course that work is dirty and necessarily political, and making a new
language is sexy...

~~~
steveklabnik
The reason that this wasn't done is that we believed (and it still seems to be
true) that you cannot make C or C++ be memory safe at compile time. Or rather,
you cannot do it without introducing backwards incompatibility, which means
you're effectively making a new language anyway, and something that's a non-
starter for those languages. (as it should be, IMHO.)

It had nothing to do with "sexy" and everything to do with engineering goals.
I assure you, a lot of work in Rust is dirty, political, and not sexy too :)

------
bhaak
The main fallacy of this blog post is that he wants it to be one single
programming language that replaces C.

C has actually been already replaced mostly. C++, Java, C#, Python, Ruby, Go,
Rust, etc. have been chipping away for more than 20 years now at C's market
share.

What kind of project can you seriously start today in C because there are no
better options available?

My guess is embedded programming and kernel programming and for both of these
usecases we feel the pain and would actually want something else.

> _Yes, Rust is more safe. I don’t really care. In light of all of these
> problems, I’ll take my segfaults and buffer overflows._

Old C programmer yelling at clouds?

> _Consider Go, which has had a lot of success in supplanting C for many
> problems. It does this by specializing on certain classes of programs and
> addressing them with the simplest solution possible. It hasn’t completely
> replaced C, but it has made a substantial dent in its problem space - more
> than I can really say for Rust_

Go is IMHO a nice language and I would have been delighted to have it in the
90s. But nowadays it already feels outdated on arrival.

Lately I've been noticing more and more tools being developed with Rust. Some
things take time, I wouldn't already write off Rust yet.

~~~
Sir_Cmpwn
Author here.

>The main fallacy of this blog post is that he wants it to be one single
programming language that replaces C.

That's not at all what I'm suggesting. In fact I thought this part of the
article makes it clear that I feel the opposite way:

>C is far from the perfect language - it has many flaws. However, its
replacement will be simpler - not more complex. Consider Go, which has had a
lot of success in supplanting C for many problems. It does this by
specializing on certain classes of programs and addressing them with the
simplest solution possible. It hasn’t completely replaced C, but it has made a
substantial dent in its problem space - more than I can really say for Rust
(which has made similar strides for C++, but definitely not for C).

~~~
bhaak
> _It hasn’t completely replaced C_

The keyword here is _completely_. Rust doesn't need to completely replace C,
it only needs to cover those usecases other languages haven't already covered.
Or maybe just some and a completely different language takes what is left.

You don't care that Rust is much more safe than C due to all the features it
has that are unlike C. But the safety aspect is Rust's main raison d'être.

If you dismiss this outright, you could have written a much shorter article or
at least written a much more interesting article by starting with this
admission and from that working your way through Rust's feature and explaining
how this doesn't alleviate the warts of Rust.

> _But now you know why we are still writing C_

I wonder who this "we" is?

I'm also still writing C but for quite different reasons. Mostly because of
legacy code and to some degree even just to be able to claim that I'm working
on 35 year old code.

~~~
bb88
> You don't care that Rust is much more safe than C due to all the features it
> has that are unlike C. But the safety aspect is Rust's main raison d'être.

Rust is still young. I think it's a bit naive to proclaim the language of the
future is here. Why?

That was also the point of Ada until people realized that unhandled Constraint
Errors could still crash missiles.

[https://itsfoss.com/a-floating-point-error-that-caused-a-
dam...](https://itsfoss.com/a-floating-point-error-that-caused-a-damage-worth-
half-a-billion/)

That was the point of Java until people realized that JRE's were full of
security holes.

[https://www.cvedetails.com/vulnerability-
list/vendor_id-93/p...](https://www.cvedetails.com/vulnerability-
list/vendor_id-93/product_id-19117/Oracle-JRE.html)

So, what's the point of Rust again? To protect us from all these security
holes? Wasn't that also the goal of other languages?

> I wonder who this "we" is?

TIOBE says C is second most popular language after Java even with all the
security holes. So there's a lot of "we" (though I don't code in C).

[https://www.tiobe.com/tiobe-index/](https://www.tiobe.com/tiobe-index/)

~~~
bhaak
> _Rust is still young. I think it 's a bit naive to proclaim the language of
> the future is here._

I never claimed that Rust is the language of the future. I didn't say it
directly but I think you can deduce it from my comments that I consider a
multi language approach more sensible than using the same programming language
for everything.

Using Rust is more safe than using C. That's valuable.

> _So, what 's the point of Rust again? To protect us from all these security
> holes? Wasn't that also the goal of other languages?_

Are you saying that just because Rust doesn't solve all problems it isn't
worth having? You're also conflating stuff.

The Ariane 5 explosion was not a programming error, it was a testing and
specification error. The code worked exactly to the spec but the spec was for
another piece of hardware. You can't use a fork and complain that it's not a
good spoon.

How about quantifying the bugs in the JRE against all the buffer overflows in
similar C code? 600 CVE worthy bugs in 10 years doesn't sound like that much
if you put it that way.

[https://www.cvedetails.com/product/19117/Oracle-
JRE.html?ven...](https://www.cvedetails.com/product/19117/Oracle-
JRE.html?vendor_id=93)

> _TIOBE says C is second most popular language after Java even with all the
> security holes. So there 's a lot of "we" (though I don't code in C)._

The TIOBE index has some issues. It is essentially counting hits for a search
engine query for a specific language. I would rephrase it as "C has the second
most webpages on the internet."

On PYPL it is only the 6th popular language, although coupled with C++.

Nevertheless there is still demand for C. Otherwise we wouldn't even have this
discussion at all. But most people would rather see this demand decrease as we
haven't been able to fix the language in the last 30 years.

~~~
bb88
> The Ariane 5 explosion was not a programming error, it was a testing and
> specification error.

What happens when you stick a 32bit float into a 16bit float type in Ada?
CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was
Ada's inability to deal with unknown/incorrect inputs and deal with them in an
effective way without crashing. This is not that much different than buffer
overflows from unknown inputs in C, btw.

It's worth noting that this was one of the primary reasons that Ada got less
and less traction in the US government, as Ada was supposed to prevent things
like this from ever happening.

~~~
Raphael_Amiard
> What happens when you stick a 32bit float into a 16bit float type in Ada?
> CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was
> Ada's inability to deal with unknown/incorrect inputs and deal with them in
> an effective way without crashing. This is not that much different than
> buffer overflows from unknown inputs in C, btw.

That's immensely different actually ... One is undefined behavior, the other
is defined but crash. In the first case the problem can stay unnoticed almost
forever until somebody exploits it. In the second case, if you actually test
and _cover_ your code, you will catch the problem.

Short for using a proof technology (which Ada enables and makes easy because
of the large palette of constraints you can add on types), there is NO
language that can statically guarantee that your program won't crash at
runtime. Yes, Ada is not special in that regard. What Ada guarantees is that
it will crash, so you can actually catch those kind of bugs in testing. Also
nowadays you can use SPARK Ada to formally prove your code correct.
[https://en.wikipedia.org/wiki/SPARK_(programming_language)](https://en.wikipedia.org/wiki/SPARK_\(programming_language\))

Blaming on the language what is actually bad testing/architecture is pretty
unfair.

> It's worth noting that this was one of the primary reasons that Ada got less
> and less traction in the US government, as Ada was supposed to prevent
> things like this from ever happening.

Do you have any source for that ? From my sources, Ada got less and less
traction because of various reasons, one of them being the price of compilers
at the time. I have never seen anybody saying that it was because Ada was "not
safe enough", and even today it stays one of the safest languages out there in
many aspects.

~~~
bb88
> Blaming on the language what is actually bad testing/architecture is pretty
> unfair.

I think we can both agree that a SEGFAULT and an unhandled CONSTRAINT_ERROR
lead to program termination.

Your right in that at least Ada raised a CONSTRAINT_ERROR. But -- the cause
for a CONSTRAINT_ERROR and a SEGFAULT in this case are the same: bad handling
of inputs to a function.

So in this case the results would have been the same as well. In either case
it comes down to design and proper handling of inputs.

So I don't buy your argument that it is different because of undefined
behavior vs. defined behavior. Ada 83 had undefined behavior, too. It's just
that Ada coders (well the good ones) knew to avoid it.

> Do you have any source for that ? From my sources, Ada got less and less
> traction because of various reasons, one of them being the price of
> compilers at the time.

Having worked in a Large Defense Corp(TM) during the height of the Ada
popularity, it became pretty clear that the cost of a compiler for a $100mm
program wasn't really the issue.

The GNAT Ada compiler came out in 1995, and I know smaller defense contracts
used that as a viable solution to write software.

The primary issues with Ada were:

1\. Ada was oversold and underperformed. The Arianne-5 was the kind of tragedy
that Ada was supposed to prevent. Interfacing with external systems was a
pain. Tooling was a pain. The resulting executables were HUGE at the time.

And then the development itself was expensive. Towards the end of my time
writing Ada, our group was coding at the rate of 2 lines of Ada code /
developer hour. Compiling took hours, running and testing took hours, etc. So
a 20 line code change might easily result in 10 hours of a compiling/testing
cycle.

2\. No code reuse across defense contractors. Ada didn't have a package
manager at the time, and while there were software libraries, there weren't a
lot of them. Not like the C/C++ or later the Java world would have. So if you
needed something, most likely you had to write it from scratch.

3\. Java got popular around 2000ish and showed what a great software ecosystem
looked like. Around 2005ish most new successful defense development was on
java.

------
nicoburns
I agree with the overall conclusion. Zig is aiming at being a C replacement.
Rust is very much more in the C++ space. But a lot of the individual points
seem off the mark.

> Concurrency is generally a bad thing. A program which uses poll effectively
> is going to be simpler, reasonably performant, and have orders of magnitude
> fewer bugs.

One of the benefits of Rust is that provides a lot of checks on concurrent
code to prevent you doing stupid things, so you get the benefits without these
costs. It's not perfect, but I've personally had zero issues with concurrent
code in Rust. This is actually a benefit Rust provides even over other memory
safe languages like Java.

> C has a spec.

Yes, C has a spec. But a ridiculous number of things (in a modern context) are
left as undefined behaviour in that spec, meaning that it is very easy to
accidentally violate the spec. Rust doesn't have a spec yet, but it has far
more safeguards which make it much easier to avoid weird unexpected behaviours
in practice. A full spec will come eventually.

~~~
cogman10
> One of the benefits of Rust is that provides a lot of checks on concurrent
> code to prevent you doing stupid things

Well, here's the kicker. Nothing about rust forces you to use concurrency.
Saying "Concurrency is bad, therefore rust is bad" makes no sense. There is
nothing that forces you to spin off new threads in rust, just as there is
nothing that forces you to spin off new threads in C.

In fact, it is pretty rich complaining about Rust's concurrency story while
praising Go. A HUGE selling point to go was/is goroutines! The language was
even given keywords for making concurrent actions!

------
joshdover
Most of the author's points here derive from the fact that C has been around
for nearly 50 years and Rust a mere 8. This post should really be titled "Rust
is not a good C replacement _right now_".

Yes, Rust still has a long way to go to be the right tool for all the things
you can do with C today, but that doesn't make it less. It clearly has
benefits when writing concurrent and safe code. You pay for this with a
learning curve, but the Rust team has been shaving this curve down through
better tooling and documentation for the past few years.

> Yes, Rust is more safe. I don’t really care. In light of all of these
> problems, I’ll take my segfaults and buffer overflows.

I suspect that for the author's work, these things may not matter much. But to
a programmer working on any software where security is paramount (many web
infrastructure pieces), this feature is golden.

I expect that as Rust matures, we'll see a solidified spec, competing
implementations, and expanded build tooling. C has a long head-start, not to
acknowledge that is just wrong.

~~~
skybrian
On the other hand, Go has a very readable specification that was written early
and is maintained to always be up to date.

Why couldn't the Rust team maintain a spec and keep it up to date by changing
it in the same pull request that changes a language feature in the compiler?
This seems like mostly a matter of discipline.

~~~
steveklabnik
> Why couldn't the Rust team maintain a spec and keep it up to date by
> changing it in the same pull request that changes a language feature in the
> compiler? This seems like mostly a matter of discipline.

It's not that, it's that we take the idea of a spec very seriously. We want to
have a spec that's extremely solid, and so there's a lot of foundational work
that needs to be done first. That work has been ongoing. Not all specs are
created equal, and good ones take a lot of time.

For comparison, C was created in 1972, and the first specification happened in
1989.

~~~
skybrian
Okay, but this seems like letting the perfect get in the way of the good? A
maintained, readable, informal spec should be quite useful as a starting point
for writing a more formal spec later.

It need not be definitive. It would be quite reasonable to point out areas
that aren't nailed down yet - this is also useful for the reader.

~~~
TheCoelacanth
What do you want out of an informal spec that isn't provided by "The Rust
Reference"[1]?

[1] [https://doc.rust-lang.org/reference/index.html](https://doc.rust-
lang.org/reference/index.html)

~~~
skybrian
It's useful but I'd like to see a bit more top-level completeness. Every
feature should be listed and have at least a cursory description, even if it's
not entirely nailed down.

(Maybe it already is like that, but the disclaimers say it's not.)

~~~
steveklabnik
The vast, vast majority does, but there may be some missing bits. Printed out,
it's about 170 sheets of paper, so there's a _lot_ there.

------
phaazon_
I read through the article and I recognized the pattern of an old C cave bear
that refuses to learn new things and understand why safety and type theory
matters. Lots of arguments made in that post are either unfair (i.e. the Cargo
team stuff) or completely wrong.

Also, if you think Go is a replacement of C, I think you are not a real
systems programmer. Go has a GC, in the first place: how can you seriously
state it’s a replacement of C? Also, you didn’t mention it (voluntary I
guess), but Rust does have a community-based mechanism to make the language
evolve (RFCs).

About the number of features, those are mostly non-breaking changes additions.
Rust has editions now. Just… do your homework?

C++ is mostly used as a OOPL. Rust has no concept of OOP.

> Yes, Rust is more safe. I don’t really care. In light of all of these
> problems, I’ll take my segfaults and buffer overflows.

Sorry For Your Loss.

------
xiphias2
,,Concurrency is generally a bad thing''

Easy speedup of processors ended. Not using system resources efficiently is
not sustainable long term. Mozilla created Rust to be able to use the multi-
core hardware (especially on mobile phones), thereby improving battery usage
as well for rendering web pages.

Rust has it's C++ style problems (compiling time, not good enough IDE
support), but the dev team knows about them, and hopefully improve them in the
next years.

~~~
jhasse
> Rust has it's C++ style problems (compiling time, not good enough IDE
> support), [...]

Actually, since language servers like clangd, cquery and ccls, IDE support is
not a C++ style problem anymore.

~~~
Rusky
There have been improvements for sure, but have you used a good Java or C#
IDE? C++ support is still far behind in terms of performance and accuracy.

(I work on a C++ IDE.)

~~~
jhasse
Yes, I have used Eclipse and IntelliJ.

Have you used cquery for example ([https://github.com/cquery-
project/cquery](https://github.com/cquery-project/cquery))? In my experience
performance is excellent and it can even be used with large code bases like
Chromium. Accuracy is perfect since it uses the same information the compiler
has.

~~~
Rusky
Yes, as cquery's README states it has a huge memory overhead because it
basically just builds the project and keeps the info around. This is rather
like how Visual Studio's C++ IDE support _used_ to work, and it was not fun to
wait for re-indexing after making edits.

Alternative Clang-based solutions reduce the memory overhead by doing more on-
demand computation, more in line with how C# or Java IDEs work, at the cost of
much higher latency because Clang is not designed for anything but batch
compilation.

This also isn't a complete solution for accuracy, as it only really works if
you're also building with Clang (or something close enough that Clang can
emulate it).

Like I said, things have improved for C++, but it's nowhere near what other,
more IDE-friendly, languages can do.

~~~
jhasse
My guess would be that in C# and Java, re-indexing is faster, because those
languages have faster compile times in general. Therefore I would put this as
a compile time problem.

> This also isn't a complete solution for accuracy, as it only really works if
> you're also building with Clang (or something close enough that Clang can
> emulate it).

Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC
extension to the language. And if there's some other compiler that isn't
standard comformant, I wouldn't put this as a IDE support problem.

Of course there are cases were Clang fails to compile standard C++ code, but
those are very rare.

~~~
Rusky
Yes- but not only are C# and Java faster to compile in general, they're easier
to process small pieces of in isolation. C++ requires everything referenced to
be declared previously even just to _parse_. (Modules should help here, at
least, eventually.)

But even then, parsing is often required to do complex Turing-complete
processing of templates and constexpr, since that determines something's role
in the grammar. This forces an accuracy vs performance tradeoff that modules
don't help with at all.

So it's not just a compile time problem that _happens_ to affect IDEs, but
also an IDE problem, because they can't take nearly as much advantage of the
fact that they're only trying to analyze the code, not build it.

And language extensions are hardly unfair. In practice they're used all over
the place, and people expect them to work in their IDEs, especially when
they're off in some header they didn't write. (Attributes help here, somewhat,
when compiler vendors can move extensions into them.)

~~~
jhasse
Makes sense, thanks for the explanation.

> And language extensions are hardly unfair. In practice they're used all over
> the place, and people expect them to work in their IDEs, especially when
> they're off in some header they didn't write. (Attributes help here,
> somewhat, when compiler vendors can move extensions into them.)

It's a C++-as-it-is-used-in-the-wild problem then, not a (ISO) C++ one ;)

Anyway: I myself never had any problems, but all my programs build fine with
Clang (as all C++ programs should IMHO).

------
calibas
>Rust will eventually fail to the “jack of all trades, master of none” problem
that C++ has.

He's talking about C++ like it's some kind of failure and not one of the most
widely used languages in the world. Sounds like the author just doesn't like
C++, so it's no surprise he doesn't like Rust either.

>Yes, Rust is more safe. I don’t really care. In light of all of these
problems, I’ll take my segfaults and buffer overflows.

"I don't really care" isn't a good reason for ignoring one of Rust's strongest
points. If you're not an expert in C like the author, then this would be one
of the biggest reasons for choosing Rust over C.

That being said, I agree than Rust isn't a good C replacement, mainly because
it's more similar to C++.

------
gvx
This reads like a rant about screwdrivers being terrible hammers.

By the way, there is a lot of polyglot library code out there that is both
valid C and C++, which is the reason for using "C/C++" much of the time.

------
jszymborski
I think a better title for this post would be "Rust is not C".

I'm also not sure how stating the number of features recently added to a 47yo
language is very small and the number of features added to a 8yo language is
very large proves any point.

That you don't care about safety or concurrency has nothing to do with the
title, and frankly betrays that this article is more about Rust not being last
decade's systems language as opposed to Rust being a good candidate for future
projects that would otherwise have chosen C.

------
Tomte
I've been waiting so much for a way to use rustup (and Cargo, but that's
beyond the pull request a bit further down) behind a MITM proxy.

And since Rust has always been Windows-friendly, I had high hopes when someone
actually started to implement this support (basically pass "-k" to curl).

Because I had fought with all kinds of git and curl configuration files, until
I realized that those don't mean anything to rustup.

The implementation was critiqued in a very civil way. The author fixed the
issues. Everything was ready to merge and... in walk some busybodies who under
the pretense of caring about security (having no clue about the issue or
modern Windows workplaces, and despite clear refutations of their concerns)
have seemingly been able to kill this patch: [https://github.com/rust-
lang/rustup.rs/pull/1624/](https://github.com/rust-lang/rustup.rs/pull/1624/)

"We need to discuss this with experts". I don't know where, I briefly searched
for any such discussion. I guess there was none.

So a drive-by shooting killed a very useful feature. The saboteurs can revel
in the knowledge that they drove away a new contributor (I haben't seen any
more activity on that GitHub issue). And users suffer.

Thanks a lot! Sabotaging corporate users must feel very good.

~~~
steveklabnik
Part of the issue here is that rustup has not had a dedicated maintainer in a
while; we’re working on it.

~~~
jolhoeft
Is there a link to the maintainer discussion?

~~~
steveklabnik
I am not 100% sure; I’m not on the tools team, but it’s undergoing a big re-
org at the moment. I’d get in touch with them: [https://www.rust-
lang.org/governance/teams/dev-tools](https://www.rust-
lang.org/governance/teams/dev-tools)

------
notacoward
> A program which uses poll effectively is going to be simpler, reasonably
> performant,

Only for newbie values of "performant". I work on data-storage servers. It has
been quite a few years since I've worked on one that didn't absolutely need to
take advantage of multiple cores to get competitive performance, and I'm very
far from being alone in this need. Splitting one server into many separate
processes is _not_ a solution in these cases, as it just moves complexity from
the in-process domain to the between-process domain where it's even harder to
maintain good performance (or even validate correctness). As soon as I read
"concurrency is generally a bad thing" the author lost all credibility.

------
zaarn
> "measured by the number of bullet points [...] on Wikipedia"

> "measured by the number of headers in the release notes of major [...]
> versions"

I don't think it's a fair comparison to pull from these two types of sources,
compare the numbers and expect a reasonable result.

The entire rest of this blog reads more like a rant about screws not being
nails than an actual complain about the languages itself.

------
marricks
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of
> these problems, I’ll take my segfaults and buffer overflows. I especially
> refuse to “rewrite it in Rust” - because no matter what, rewriting an entire
> program from scratch is always going to introduce more bugs than maintaining
> the C program ever would.

Are they advocating for never rewriting anything? Like, programming language
advancement should have stopped at C cause someone would have had to rewrite
something and that would mean more bugs??

~~~
jhasse
Most programming languages can call C code, so you don't have to rewrite
something when switching to them.

~~~
steveklabnik
Rust can as well, and it can also expose the C ABI too, so it can work both
ways.

------
WallWextra
You don't have to care about memory safety, but if you don't you probably
shouldn't speak for "systems programmers" as a whole. Systems need to be safe.

~~~
notacoward
Thank you for that. Now that you've stated it so concisely, I can see how this
is the thing that bothered me about the post. The author is implicitly trying
to represent the C user base but doesn't seem to share that user base's
concerns, priorities, or practices.

------
adamnemecek
OK looking Just at the number of features seems disingenuous. Cpp features
tend to idk, increase the level of complexity as there tends to be quite a bit
of friction between them. Rust features definitely “work together”.

This post seems to have started with a conclusion and worked backwards.

Rust is such a breath of fresh air. Cargo is nuts. The community is nuts. I’ve
been writing rust full time for a couple of months now and I’m not going back.

~~~
xiphias2
The main problem with C++ are not the new features, but the old obsolate ones.
It's too late to fix the language.

~~~
adamnemecek
Also their development process is too slow. Like it would be impossible for me
to pitch a new feature to cpp. I can imagine adding a new feature to rust (not
that I would but I like that there’s the option).

~~~
glangdale
I'm appreciating the irony of you complaining that "C++ features don't work
together" but also saying that the process of putting new features into C++
should be _faster_. :-)

~~~
adamnemecek
There's nothing ironic about that. If they had a shorter feedback loop, things
could be getting fixed faster.

------
solarkraft
Sir_Cmpwn has lost a bit of credibility in my eyes after this article and
their behavior in the comments.

------
rwj
The current pace of development of C++ is questionable, but Rust is still a
fairly young language, so the comparison to C seems unfair. Presumably, the
rate of change in Rust will slow down. Although, if you are looking for
stability today, the point does stand.

------
crankylinuxuser
The converse is what I've heard with people at REN-ISAC and whom write and
coauthor RFCs. (I'm not one, but trust the comments they've made to me
regarding this.)

For a new dev to start writing internet-quality code, with C/C++ takes 10
years before they can make reliable code. The procedure takes what amounts to
a journeyman style one-on-one until proficiency, 10k / 10 years later.

With Rust, it takes 2 years for a new developer to attain proficiency.

To me, those numbers are the ones that matter. Rust is stable and good, and
gets out of the way of the developer... and gets in the way of the developer
when coding anti-patterns.

------
jdright
"...I’ll take my segfaults and buffer overflows"

Well, this speaks volumes. Nothing more need to be said.

------
kristaps
Age of the langs absolutely needs to be taken into account if comparing
stability and feature addition rate.

According to Wikipedia it's 47 years for C vs 8 years for Rust (as of 2019) -
it's not that surprising that a 6x older language is much more stable.

------
IshKebab
> Concurrency is generally a bad thing

Erm...

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of
> these problems, I’ll take my segfaults and buffer overflows.

Ok this is nonsense.

------
Symmetry
Concurrency might be a dangerous thing but in microcontroller land, where I do
my C programming, interrupts are a fact of life and just polling really isn't
a practical solution.

~~~
MuffinFlavored
Is that how Rust concurrency works under the hood? Polling?

~~~
steveklabnik
Rust has no particular built-in model for concurrency or threading. The
standard library currently exposes system threads, and we’re working on
providing an API for pluggable concurrency models. The most popular of which
is a wrapper around epoll/kqueue/iocp.

~~~
MuffinFlavored
Rust has no particular built-in model for concurrency, but as soon as you want
to do anything important with Rust (given the current ecosystem) you're going
to run into Tokio, no? It seems to be the community-agreed-upon way to handle
concurrency.

Does Tokio use polling under the hood?

~~~
steveklabnik
There are a number of different options. And today, yes, code is tied to one
of them. But, and it’s not stable yet, futures and executors, the two traits,
are being added to the standard library. This lets your code be generic over
executors, and there are already more than just tokio. Including an embedded
one, for example.

Tokio wraps epoll/kqueue/iocp.

~~~
MuffinFlavored
> But, and it’s not stable yet, futures and executors, the two traits, are
> being added to the standard library.

Is this implementation going to wrap epoll/kqueue/iocp?

Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of?

What are the popular choices other than Tokio?

~~~
steveklabnik
Traits are not implementations, just interfaces. There won't be an
implementation of one in std, just the interface, so that the ecosystem can
interoperate.

At the moment, I think Tokio is pretty great. I wish that there was more
development bandwidth to help test out some cutting-edge stuff, but I think
the design is sound.

It really depends, Tokio is the most popular at the moment. This is because
most of the new ecosystem is built around these new, unstable interfaces.
Tokio currently runs on the older, not in the standard library one. It's all a
bit confusing at the moment, to be honest.

------
m0meni
This just reads like the author was told to rewrite his code in rust one too
many times, and he felt compelled to justify his own choices by bashing rust.
Just say you like the simplicity and subtle bugs of C more than having to deal
with the upfront complexity of low-level code at all times

------
bitwize
Of course C programmers are going to think Rust is a poor C replacement. Rust
wasn't made for C programmers -- it was made for their replacements.

~~~
z3phyr
Zig is a better replacement for C and Rust. C programmers no this, but Rust
programmers can't comprehend simplicity. They won't know

------
monster2control
Why do people up vote your flame war post?

Ah, exploiting the human urge to argue about literally anything. Especially
when your argument is full of flaws and straw men statements.

------
sevensor
My biggest quibble with the article is the idea that C will have a
replacement. Many languages have already replaced C, in many domains. And yet
C is still with us. I suspect it will remain indefinitely, shrinking in
relative popularity but growing in the absolute sense. If for no other reason
than that every language benefits from having a way of talking to libraries
written in other languages, and the lingua franca is C. Rather than writing
N^2 foreign function interfaces for N languages, each language can have one
FFI library targeting C interoperability.

------
adrianN
As long as you don't write software for computers that are connected to a
network, it's fine not to care about security. For everybody else though, new
software should probably be written in a safer language. That doesn't have to
be Rust of course.

------
KirinDave
Personally, I think the C community is deeply infatuated with the idea that
"we are in fact simple" mentality even though it's not well justified.

C isn't simple. C isn't simple to use.

On the implementation side, it has a complex calling convention. It relies on
a memory management runtime without spec'd behavior. Tons of hardware
implementation details leak up to the upper levels. C's error handling schemes
are inconsistent, and thus complex to work with and to implement.

Being a C programmer isn't much easier either! C's memory managers tend to
blow up if misused, but they don't blow up WHEN they're misused. They always
cause problems, but it's not clear how or why. You have a bomb in your code
that will go off in a random place. Even good debuggers with great tools can
find it challenging to find the source of a double free. And that's alongside
managing the weakly typed (not to be confused with static/dynamic) world, the
pointer arithmetic, the inconsistent library conventions. Oh yeah, the
libraries...

C's libraries aren't simple. They have to protect themselves from double
inclusion, they can collide with each other, and have wildly different
conventions depending on if they're loaded at runtime or compile time. Despite
a constant derision of OO from the community, they often affect an "OO"
discipline on methods. In reality this asks developers to create the
impression of OO behavior by being very (very!) careful with call sequencing.
And of course, the price of failure on most of these tasks is at runtime, on
someone else's hardware, often with opportunities for remote execution.

When a C programmer says, "C is far from the perfect language - it has many
flaws. However, its replacement will be simpler - not more complex," we have
to read it very carefully and ask, "What does simpler mean?" Because despite
the complexities of being a C programmer and the unstated complexities of the
C runtime (and the large portion of unspec'd behavior so glibly ignored in
this article to dunk on Rust), they still say "C is simple."

In this case, evidently it means: "Consider Go, which has had a lot of success
in supplanting C for many problems. It does this by specializing on certain
classes of programs and addressing them with the simplest solution possible."

Go isn't simpler. Go actually aims for a rather broad category of programs (it
goes way up into the world of abstraction Python covers, and stops short of
the embedded world where C is firmly entrenched because it's well-understood).
Go has a sophisticated (and arguably, hard-to-use) concurrency model (didn't
the author just say, "Concurrency is generally a bad thing?") and
implementation. It has real garbage collection. Its stdlib is expected to have
full SSL and networking support builtin.

But Golang is _familiar_ to C programmers. I think that is why we see all the
dunks on C++ and Rust in this artcile. C++ and Rust are weird. They're
different. Go feels like C, so it's "simpler to learn" even if it requires a
whole lot more core concepts and careful implementation than a C compiler.

Maybe Rust isn't your solution. Okay. Maybe C++ isn't your solution. Okay.
There's still lots of other good languages to try. Languages that don't ask
users to wade among a field of charged rails that the slightest touch can
result in catastrophe. Nim or D maybe? There are others, and you can find
them.

But continuing to use C with the attitude that, and I quote, "I don’t really
care. In light of [the complaints leveled at Rust], I’ll take my segfaults and
buffer overflows" is dangerous. It's unprofessional. It's reckless. It's also
a false dichotomy.

The answer to C's problems is to _stop using C._ Not to start using something
else specifically. This article makes it clear that the actual goal of this
sentiment in the C camp is to _keep using C_. There isn't even a candid
ownership of the problems with that strategy.

------
erotavlas
From performance point of view, Rust is comparable to C++
[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/which-programs-are-fast.html)

------
iheartpotatoes
You can't overstate the importance of a specification. It is the most loathed
thing to write, like unit tests, but in the end is essential. I think the OP
romanticizes a bit: K&R C had a spec, a very very very loose spec. It took
ANSI a decade to put some meat on it. Early C compilers weren't much help:
Sparc had SystemV and AIX had POSIX which are OS specs but still defined C
behavior in their compilers, and it made life so much easier in the early 90's
when they converged on Gnu.

My favorite part of the article is the footnote. We really need to stop
referring to C/C++ as "roughly the same" because they are so so so radically
different.

~~~
wglb
K&R C had no formal spec. It wasn't until 10 years after its invention that it
did, and that was after a lot of real-world experience.

I would argue that early specifications don't work out very well. In fact,
they are often problematic. One example is that standard ANSI C had a proposal
for a while that included an Alias keyword. This was such a bad idea, that
Dennis Ritchie showed up to the meeting personally to help kill it.

Standards committees are not usually staffed with practitioners, who are busy
developing the language and are quite expert in nuance, feasibility, and
utility. Attendees to standards committee meetings are almost always not.

And reality does meet the standardization expectations quite frequently. Look
at the number of "undefined" or "implementation choices" in C alone. Therein
lie careers for security folks.

------
7e
Should the HN rules be amended to discourage self-authored submissions? They
seem to circumvent the natural filter that comes with peer-nomination, and
suggests they were written with promotion in mind.

~~~
nickez
I thought you had to write "Show HN:" when you were publishing your own
content..

~~~
grzm
> _”Blog posts, sign-up pages, and fundraisers can 't be tried out, so they
> can't be Show HNs.”_

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

------
jonathanstrange
Lack of a formal specification and/or an international standard is the real
bummer. That's the biggest disadvantage in comparison to languages like Ada
and C.

~~~
mjw1007
At this stage I'd settle for an informal language description, as long as it
was a serious attempt to be basically complete and correct.

It's nearly four years since Rust 1.0 and the reference manual is still
calling itself a best-effort document. It's surprising that a project which
generally holds itself to high engineering standards is so sloppy in this one
area.

~~~
kibwen
_> It's nearly four years since Rust 1.0 and the reference manual is still
calling itself a best-effort document._

I'm curious what standard this is holding Rust to; C was 17 years old when a
comprehensive reference emerged, and C++ was 13 years old for the same. If
Rust manages to have a reference by 2030 (and I certainly hope it does) then
it will be on track.

~~~
mjw1007
I think Go and Swift are natural languages to compare Rust to in this respect.
Both of them seem to be doing a much better job of reference-level
documentation.

In other circumstances the Rust people generally aim for higher standards than
"no worse than C or C++", let alone "no worse than C or C++ in the 1980s".

(I mean, you don't see Rust people saying "It took 30 years for C++ to get any
form of type inference, so as long as we have something by 2040 we'll be on
track.)

------
mjw1007
I think there is a gap in the market for small language which is just a
"better C", but developing a new language is a great deal of work, and it
would be hard to compete against the alternative of using a small subset of
{Ada, Rust, whatever}.

Maybe the large languages should look at defining official subsets, to make
life simpler both for programmers and validation. Ada used to have something
of the sort (and still does for all I know).

~~~
chessturk
I'm curious if you consider Nim or Golang to be a small language that is a
"better C". If not, why?

~~~
mjw1007
I don't think they count as a "better C" for this purpose. I'm thinking of
something aiming at the niche that C currently fills.

Having a garbage collector doesn't fit that, and Nim doesn't look small
(anything with both destructors and exceptions is getting into complications
rather beyond C).

~~~
nimmer
Regardless, I use Nim when I need the performance and memory footprint of C.
GC is optional.

~~~
jefftime
Can you use the standard library without GC?

~~~
nimmer
Most of it.

------
_nalply
It seems that the Rust community is already slowing down with new features.
Have a look at "This Week in Rust" updates: the section "Approved RFCs" has
the text "No RFCs were approved this week" almost every week now. There also
was a discussion of designing 2019 as the fallow year and going more slow than
before.

~~~
burntsushi
That's true, and personally, I hope it continues. However, there are some
significant new features that have already been approved that are being worked
on right now. e.g., Specialization, const generics and generic associated
types. Each of these is somewhat significant in that they might alter how one
might write some kinds of code today. But generally, they open new doors by
adding more expressiveness to the type system.

------
picacho
from compiler's point of view, C++ doesn't really added that much features,
and quite stable. imho i believe the C++ ISO committee does consider the
possibilities compiler writers are able to implement these features. e.g
lambda expression, there's always operator() overloaded available in C++98;
Variable template, only allowed in namespace, aka. static member data member
in template type; CTAD, take template function argument deduce mechanism and
wrap-up for ya; auto, same as template argument, and C++'s template argument
is the same as C's typedef, etc. that is to say, to some extend, C++'s
features are also written in C++. The new idea could think of is the r-value
type, which invented to trigger move constructor, again, using the existing
function overloading mechanism to do the job. This maybe not engineering
friendly which the writer has to manually nullify the moved object's internal
pointers as for Rust just using type system to prevent you from using it.

------
chessturk
Sincere question, I didn't realize that Rust didn't have a specification. How
can folk say Rust guarantees safety when it doesn't guarantee an
implementation? I don't see how you could have one without the other.

Now, admittedly, the lowest level language I've used is Go!, so fairly
abstracted (and no memory management), so I might be mistaken, but it doesn't
seem like you can have safety without a specification.

~~~
steveklabnik
> How can folk say Rust guarantees safety when it doesn't guarantee an
> implementation?

Just because there isn't a formal spec, doesn't mean that the underlying
systems aren't built with some rules, grounded in computer science and math.
We believe that the systems we've set up do guarantee those properties, even
if they haven't yet been formally verified. And a subset of them _have_ been
formally verified, which also increases confidence.

Adding to that confidence level is empirical results: while people have found
implementation bugs, which will always exist in any implementation, nobody has
managed to demonstrate that the model is fundamentally broken. That it's been
years, and many people have tried, also leads us to suspect that our
conclusions are correct here.

Put another way: not all specs are equal. Some are formal, some are informal.
Just having a spec doesn't actually guarantee anything either. Most languages
don't have a specification at all.

~~~
chessturk
> Put another way: not all specs are equal. Some are formal, some are
> informal.

So is the argument that the language reference is as good as many existing
language specifications, and my complaint is only one of semantics?

~~~
steveklabnik
Yes, it's basically about what you mean by "guarantee". Very few things are
formally guaranteed. People tend to use "guarantee" to mean "I believe this is
true with a very high level of confidence."

------
StreamBright
Totally agree with his observations but I disagree with the conclusion. C is a
ok programming language. The first language that realises that simplicity
above all is the most important feature of any language and uses the same
safety measures like Rust is going to win over a huge user base.

~~~
rhn_mk1
Low level programming in a safe way is a complicated endaevor. The assembly
language with a few instructions can be the ultimately simple language, but it
doesn't offer the same features that Rust does.

While I am all for simplicity, I just don't think it's all that obvious that a
language could possibly be simple, fast, and safe at the same time.

~~~
StreamBright
Sorry when I mean simplicity I do not mean it in the ASM sense but more like
LISP. Very simple basics, very powerful concepts.

------
fxfan
If OP thinks Firefox is one of the largest C++ codebases in the world then OP
has a very limited worldview.

~~~
GhotVeren
That's true though, as far as the open source projects go.

Only bigger C++ open source codebase I can think of is LLVM. What else did you
have in mind?

~~~
wglb
Er, firefox is reported to have 12 million, while llvm has 2 million. gcc is 7
million.

------
estomagordo
I keep trying to make up my mind whether this author is a C programmer. Hmmm.

