The Internet Has a Huge C/C++ Problem and Developers Don't Want to Deal with It
motherboard.vice.com
motherboard.vice.com
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.
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.
> 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.
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?
The decision to rewrite in a memory-safe language would create a lot of work for the developers, the decision to stick to unsafe languages creates a lot of work for the people handling security incidents. These aren't necessarily the same people, in the open source world you usually have dedicated teams that are having trouble keeping up with the number of severe software defects discovered every other day.
In any case, I hope articles like these help us to overcome the inertia you mention, although, realistically, I don't think a project like the Linux (or BSD) kernel will ever be rewritten in a language different than C and* be complete enough to gain widespread use.
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.
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.
Is re-writing everything in Rust really the answer?
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.
People do the C/C++ S&M thing because of interoperability.
You cannot call Ruby from Python or vice versa, but you can call C/C++ from both Ruby and Python.
This is one of the main reasons why people do not change.
We need a better portability layer, Dlang/betterC can be a solution here, but we have to be brave and forward looking.
Yes there is a lot of old C++ out there. But you can do better in C++ without losing the old features that have been debugged over the years, and without all the money of re-writing things that might or might not have bugs.
The point is, some other languages won't let you do it anyway, and given the importance of security these days, we should reconsider our priorities.
When I get a CV that lists "C/C++" as a skill, I know I can discard it without reading any further.
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.
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).
>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.
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.
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.
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."
Don't get me wrong; browsers are impressive. Computers have far more that goes into them than network traffic rendering. Most people just enjoy the luxury of abstracting it away.
Definition games are ones nobody usually wins.
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.
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.
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.
Yes, they do, and that's also a potential area of unsafety, even for languages which are otherwise memory safe.