
The Internet Has a Huge C/C++ Problem and Developers Don't Want to Deal with It - littlestymaar
https://motherboard.vice.com/en_us/article/a3mgxb/the-internet-has-a-huge-cc-problem-and-developers-dont-want-to-deal-with-it
======
steveklabnik
As I said on Reddit yesterday when this was posted:

Hi folks,

I'd just like to mention that this is the first time I'm seeing or hearing
about this article; same as the rest of the Rust team. This is one person's
opinion, who notably is a Rust user, not someone who works on Rust itself. We
generally try to not frame things like this, because we don't think that it's
a particularly constructive approach.

------
nathanaldensr
It's not fair to pin this on the ambiguous collective "developers." The real
issue is likely that there is simply too much inertia behind C and C++ for
systems and performance-critical programming. There are other languages like
Rust that provide a _technical_ alternative but not necessarily a _cultural_
one. Obviously, the pain of severe software defects is not yet high enough to
warrant switching to memory-safe systems programming languages.

~~~
mamcx
> It's not fair to pin this on the ambiguous collective "developers."

Why not? Is not as if the majority of us are much into fix things, instead of
continue along. Developers are very much the main problem here.

Neither is a problem of resources, suposely developers earn well and some of
the biggest corporations of the world work on software.

But each time is even hinted "why not ACTUALLY fix things?" the answers is
"nope, too much work", but for create chat apps and more tools for surveilance
and privacy invasion the money pit is bottomless.

~~~
weberc2
> Developers are very much the main problem here.

> But each time is even hinted "why not ACTUALLY fix things?" the answers is
> "nope, too much work", but for create chat apps and more tools for
> surveilance and privacy invasion the money pit is bottomless.

You're blaming developers but citing product/economic/business decisions. In
all likelihood, the problem is as much organizational/economic as it is
technical. For example, consider the manager who was warned about the security
risks by the engineering team, but decides to ship the product on schedule and
get promoted long before any serious vulns are discovered. Or the case where
engineering raises the issue, but fails to effectively communicate the
severity of the concern. Or the case where engineering _assumes_ management
understands the risks.

I'm sure there are lots of developers who do think they should just use C
because it's what they've used forever and _lesser developers_ might make
mistakes but _they_ don't, but I'd be surprised if these folks are the primary
driver of the situation.

~~~
mamcx
> You're blaming developers but citing product/economic/business decisions

This is a big part of it. But here, the kind of "developers" that could cause
the big impact come from MS, Google, Apple and a few others. That certainly
how normal people will look at this, IMHO.

But also, open source developers. Here is where is weird... what could be the
reason to not build better tools?

------
stargrazer
This reminds me of the story about the elephant in the room.

The article, like most rust articles (in my perception), attacks the 'memory
unsafety' issue, and therefore 'everything needs to be converted to rust'.

But ... does rust have the multi-paradigm programming mechanisms which are
available in C++?

The article also ignores the issue that the recent releases of C++ are
including programming methods for reducing/eliminating the memory issues:
RAII, for instance, is a fundamental mechanism for ensuring memory is released
at the correct time. Range operators work to eliminate the indexing issues.

'with great power comes great responsibility'. does rust offer the programming
tools available in C++? templating, meta-programming, functional coding,
procedural programming, object oriented constructs, ....

So, I think the title '.... and Developers Don't Want to Deal with It' is
incorrect and click baity. C++ is in active development and evolution, and
constructs are coming into place which help to alleviate the issues mentioned
in the article.

~~~
steveklabnik
> does rust have the multi-paradigm programming mechanisms which are available
> in C++?

Some, but not all. Or some that work differently. The one thing that's truly
missing is objects. Our metaprogramming is _slightly_ more limited, but also
more advanced, in different ways. That will catch up. We're not adding
objects, though.

------
Tehchops
How many developers are actually versed enough in C/C++ to deal with it?

Is re-writing everything in Rust really the answer?

~~~
matis140
I wonder about analysis tools for c/c++. I know those tools have come a long
way. Is the problem the decades of time where those tools were proprietary or
expensive or free/open and poor in quality where most of this code was
written? Or do these tools actually fall short of their claims of memory
safety and the only solution is a rewrite? Or I guess it can be like opening
an old solution in visual studio seeing it has 100+ warnings or doesn't even
build anymore with current tooling so changes go on the back burner because
that small change turns into a few days of work because nobody has built it in
the last 10 year's...

~~~
steveklabnik
If the tools were able to get you the equivalent of Rust's safety, we wouldn't
have bothered making Rust.

These tools are great, and I welcome anything that makes software more safe.
But you can't truly retrofit safety onto C or C++. You can improve it, but
it's an improvement, not a solution.

------
lerno
The Rust Community has a Huge Crackpot Evangelist Problem and Developers Don’t
Know how to Deal with It

------
ncmncm
Once again, there is no such language as "C/C++". Writing that disqualifies
the writer. Failure modes in C are not the same as the failure modes in modern
C++. The largest area of overlap is integer overflow. The only C++ failure
mode that occurs more frequently than in C is object lifetime mistakes, just
because C objects don't really have lifetimes, as such. (Instead, C coders get
leaks and use-after-free errors.)

When I get a CV that lists "C/C++" as a skill, I know I can discard it without
reading any further.

------
gumby
Writing in so-called "modern" C++ (c++14 and especially c++17) doesn't really
require pointer manipulation at all.

~~~
notacoward
True, but at a cost. As far as I can tell, C++ programmers have stopped caring
about the cost of copying objects at every function/method boundary, every
time containers are used (which is a lot), in lambdas, etc. Memory safety is
easy that way. Yes, _some_ modern C++ code is very careful about this stuff,
but the common idioms all seem to be pulling in the opposite direction.

I still think there's room for a system language that manages to be memory-
safe without all the cruft (std::move my ass) and inefficiency. Is Rust that
language? Not really sure. D and Zig and even Nim all seem closer to my own
ideal, but they don't have anywhere near the mindshare.

~~~
gumby
Quite the opposite: move semantics are pervasive throughout the library and
other idioms; making a lambda without copy is pretty canonical too (though if
you're going to use it with locals after returning from the stack frame you'll
inherently have to copy in _any_ language!).

And it is _very_ easy to write templates that use this behavior so users don't
have to think of it. In C++20 the syntax for this will be very simple (less
garish than the old <> syntax).

~~~
notacoward
Maybe you've been working on different codebases than I have. Whatever might
be in the libraries, what I see among the users of those libraries is a ton of
careless copying. The idiom is what the majority do, not what some authority
says they _should_ do.

------
madmax96
I've slowly built up some personal thoughts about this subject that I think
would be worth writing up more formally. For now, I'll provide a very high-
level critique of this article.

>memory-safe languages that are usable for low-level programming like web
browsers and operating systems, such as Rust and Swift, are only just starting
to achieve popularity.

A web browser is not low-level - it is an application. A software component is
low-level if it is primarily used by other applications. If you consider a web
browser low-level, you must also consider a video games, text editors, audio
players, etc low-level. I'm not saying that these things are easier or harder
to develop, I'm just stating the fact that they are not low-level. Hence, a
language like Rust which may very well be more appropriate to implement a web
browser may not be the right choice for low-level software.

Operating systems, obviously, are low-level. But an OS is composed of many
components working together - init systems, audio managers, application
service buses, package managers, etc. I argue that Rust, Go, Swift, etc. are
not suitable replacements for C and C++ in these areas.

The fundamental problem with these new languages is that it is difficult to
expose system functionality as an external library. Notice - I state
difficult, I am fully aware that in some languages it is technically possible.
This has led to the implementation of primitive functionality through system
daemons. For example, Ubuntu's Snap package management system now exposes its
behavior through a daemon. These daemons use more energy than traditional
libraries, more computational resources, and have a larger attack area.

My argument is that, even though some of these new languages may be
appropriate for some applications, there is still a large class of software
where C/C++ is the only practical choice.

I'm interested in looking at the impact of this effect on system reliability
and performance for a more scientific analysis of this situation. To my
knowledge, such a study has not been done.

~~~
steveklabnik
> A web browser is not low-level - it is an application. A software component
> is low-level if it is primarily used by other applications.

[https://en.wikipedia.org/wiki/Single-
page_application](https://en.wikipedia.org/wiki/Single-page_application)

Web Browsers are a platform that implements processes and process isolation,
threading, networking, graphics, audio, all for other applications to use.

~~~
madmax96
That’s a very good point. The modern web browser must be a low-level
application.

Still, a web browser somehow seems different from other pieces of software on
your system. This is because everything you just described is traditionally
provided by the operating system. Hence, the browser has replaced the role of
the operating system.

I believe my original critique still applies, but with some modifications. It
may be appropriate to implement a particular low-level component (like a web
browser) in one of these new languages. But that does not imply that all uses
of C are inappropriate.

An interesting question is which complements are suitable for implementation
in these languages?

To clarify: I’m reacting to what seems to be an umbrella recommendation by
certain people to replace _all_ software written in C with software in some
other language, or that it’s inappropriate to use C for _any_ new system
components.

~~~
steveklabnik
> Hence, the browser has replaced the role of the operating system.

Yup, I think this is becoming both metaphorically and literally true (I'm an
ex-Chromebook user)

> I believe my original critique still applies, but with some modifications.
> It may be appropriate to implement a particular low-level component (like a
> web browser) in one of these new languages. But that does not imply that all
> uses of C are inappropriate.

Sure. I don't think one implies the other, personally.

> An interesting question is which complements are suitable for implementation
> in these languages?

Rust can be used to do anything C can do, with some small exceptions like
"support 1970s hardware" or some practical exceptions like "this proprietary
chip comes with a c compiler only" or "there's no port to my platform yet even
if there could be."

------
purplezooey
Rust ain't ever going to replace C or C++, sorry. The article doesn't mention
the great improvements in static analysis and code coverage tools.

~~~
tatersolid
> The article doesn't mention the great improvements in static analysis and
> code coverage tools.

These tools clearly don’t work for solving memory safety issues. The number of
CVEs involving memory safety errors in C/C++ each year continues to increase.

Not that “don’t work” could mean “are unused” because they are too expensive,
difficult, noisy with false positives, whatever. The point is they have _not_
solved the problem, not even close.

------
matis140
On the upside I was pretty sure this was going to be a Rust to the rescue
opinion piece before I clicked on it. On the downside this is a Rust to the
rescue opinion piece though it does also mention swift for memory safety so
that is nice. Nothing against the language, but it has been around a few years
and I would like to see something more concrete than opinions. Give me a write
up about a vulnerability in the wild fixed with the new language.

Something new at any rate I see plenty of opinion piece espousing this or that
new language PR reading points, but most fall into fluff.

~~~
dvfjsdhgfv
But it's a bit difficult to prove, isn't it? I mean, you can just say "We
didn't have a buffer overflow error in our software written in Rust", but
that's basically it. You can't fix this kind of a bug in a project without
rewriting it, and as the author says, it's hard for several reasons. People
simply don't have enough incentives to do it.

~~~
matis140
Not entirely and I know Mozilla is in the process of doing this now. They
could take some small portion of the original bit of the browser they are
rewriting and put something technically interesting together instead of more
opinions like this. One of the things they have to overcome has been stated
above and that is that c and c++ have a lot of inertia. They are also still
cool languages. This will take a lot more than opinion to overcome.

I have written a few small things in rust and explored crates.io and like the
language and ecosystem. I am much less certain about the community surrounding
the language, but it might just be that they are mostly younger people looking
for safe places so they often feel unauthtically welcoming. It is a bit off
putting.

Anyway I would just like to see something like here is a unit of the browser
we replaces with rust servo. It took us 2 week to do this unit. before the
rewrite this unit would crash or leak at some rate after the rewrite these
have been reduced x amount where these would be numbers from the wild based
off their metrics. They could Also throw in a couple bench marks over those
code units for good measure, but i am certain Mozilla captures enough to
probably put together something with interesting real world numbers.

~~~
Narishma
AFAIK, they are not rewriting the browser in Rust. They are instead writing
new components in it, so it wouldn't be an apples-to-apples comparison.

------
sidlls
The software industry has a huge fad-following problem, too. More amusing in
this case is the the proposed solutions are either not nearly performant
enough or else susceptible to many or all of the same kinds of security
issues.

------
randyzwitch
What are all these new, 'safe' languages written in that they don't eventually
have potential memory issues as well? Don't almost all languages provide C/C++
interoperability?

~~~
steveklabnik
Rust is written in Rust.

Yes, they do, and that's also a potential area of unsafety, even for languages
which are otherwise memory safe.

