Hacker News new | past | comments | ask | show | jobs | submit login
The Internet Has a Huge C/C++ Problem and Developers Don't Want to Deal with It (vice.com)
41 points by littlestymaar 11 months ago | hide | past | web | favorite | 47 comments



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.


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.


> 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.


> 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.


> 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?


I can name quite a few people who'd love to work on this stuff, but the companies that pay them rather would they make yet another chat app or move buttons on a shopping site around. Large movements like this are hard to do on the side, especially since replacing existing software piece-by-piece is often a harder proposition than doing a full replace.


Is interesting, because maybe budget a 10% of time doing this will yield a lot of progress. Also, taking in consideration than certains tools (programming languages, OS APIs, shells, etc) have a large surface area of impact and many developers actually not care if the tools is made on C/C++, care that solve a certain problem. (Of course, this demand that the c-call conventions stay because that wire A LOT, but that is small and contained).


> Obviously, the pain of severe software defects is not yet high enough to warrant switching to memory-safe systems programming languages.

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.


This is probably the problem of the title, he obviously doesn't mean all developers.

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.


Redox has made way more progress than I ever thought it would, so who knows?


put space around the * characters to prevent them being interpreted as formatting


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.


> 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.


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

Is re-writing everything in Rust really the answer?


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...


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.


The tools have come a long ways. However they are not very powerful. C++ the language has come much father in the ability to write memory safe code - but this doesn't do much for the old legacy code out there.


Rust + ATS please. But the problem always is interoperability.

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.


One thing I'd argue vehemently for is to stop thinking about ABI as purely in terms of C, and start finding ways to describe ABI interoperability between different languages that allow more advanced features (such as Unicode strings).


The alternative is live forever in a worse-than-cobol self-inflicted hell.


C and C++ are NOT the same language. If you are writing modern C++ you don't have nearly the memory problems. C++ lets you use/create the C backdoors, but that is something that should only be done when you have to - when you have to are times you either cannot use the alternative language, or you do, but those languages suddenly become just as unsafe.

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.


> C++ lets you use/create the C backdoors, but that is something that should only be done when you have to

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.


Depends on where you work. Some of us aren't in academia. I simply refactor in modern c++ wherever I can and use "nothing but" whenever we start a new project. You get awesome ideas, and then reality kicks in.


Either the other languages allow it (though they might make it inconvenient), or they can't do some of the things C++ can do.


Other languages have other backdoors like Java's sun.misc.Unsafe which is used in many projects to get better performance.


modern c++ provides fixes for everything he mentions in the article without completely swapping out all the experience gained from decades of existence. People just aren't using it enough. It's all there.


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


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.


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


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.


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).


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.


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.


> 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

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


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.


> 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."


The web browser does not implement. It delegates. There is a difference. It provides a layer through which a webpage or client can access those resources, but it is not, nor will it ever be low-level. It sits astride the fundamental subsystems that make the computing machine usable.

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.


I think that's shortsighted, and we already have real-world counterexamples, like ChromeOS.

Definition games are ones nobody usually wins.


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.


> 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.


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.


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.


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.


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.


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.


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?


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: