4 ms·

>At this point, we know that it's not enough to hire brilliant C programmers and have them exercise care. I mostly agree with your points. In my experience (ne

by carlmr 6y ago

>At this point, we know that it's not enough to hire brilliant C programmers and have them exercise care. I mostly agree with your points. In my experience (never worked at FAANG), the brilliant C programmer hypothesis is almost untested, since most companies hire mostly average C programmers. It's only logical that non-brilliant programmers will be working somewhere. Even if a company has a few brilliant C programmers on staff, they won't be able to find all the issues the mediocre programmers produce. This is why I think it's about time that any safety critical industry should think of retiring C in favor of safer alternatives. Rust would personally be my favorite since it solves most of the really terrible issues around memory management in C and C++ (mediocre programmers not being able to compile due to the borrow checker is a feature). Of course Rust doesn't have the necessary certifications yet, but industry would be wise to contribute. Such efforts are underway (Sealed Rust by Ferrous Systems), but I don't see big aerospace, automotive and industry sponsorship here, i.e. those who would benefit the most. There is a safer language that is certified that is often ignored, which is ADA. It's actually quite modern in terms of features since the 2012 release. It has some other concepts than Rust for safety, but that doesn't mean it's worse. The heavy lifting in terms of design and certification here has been paid for by the DoD and aerospace companies, so there's no reason other industries couldn't use it.

MaxBarraclough 6y ago
> the brilliant C programmer hypothesis is almost untested, since most companies hire mostly average C programmers. It's only logical that non-brilliant programmers will be working somewhere. Chromium has suffered from buffer-overflow issues, and that's a high-profile security-sensitive C++ codebase run by Google. > Rust doesn't have the necessary certifications yet, but industry would be wise to contribute I'd rather avionics code be written in verified SPARK than in Rust, but if they can build a rock-solid Rust compiler it would be good to have it compete in that space. I imagine it could be a nice alternative to MISRA C++, for instance. As you've probably gathered from my mention of SPARK, I agree with you that Ada is sadly overlooked. Turns out that the basic idea of an imperative language that's much like C/C++ but is much safer and better suited to automatic runtime checks, isn't a new one. Ada does this, it's existed since around 1980, it's mature, there are various compilers for it approved for life-critical work, and its performance matches that of C if runtime checks are disabled. It's comparable to Zig and Rust in that regard, but those languages aren't the first to aim for C performance with far superior safety properties. > there's no reason other industries couldn't use it. Right, especially considering the fine work done by AdaCore, who make their tooling available as Free and Open Source software. Perhaps Ada's reputation for being boring is its greatest vice, as well as its greatest virtue?
- carlmr 6y ago
  >Chromium has suffered from buffer-overflow issues, and that's a high-profile security-sensitive C++ codebase run by Google. Like I said, I haven't worked at Google. But are you sure every programmer on Chromium is a genius? Google has a hard Interview process, but does it filter out every bad engineer? And if Google's "probably better than other company's" engineers can't do it? How can we expect other companies to deal with C? >I'd rather avionics code be written in verified SPARK than in Rust, but if they can build a rock-solid Rust compiler it would be good to have it compete in that space. I imagine it could be a nice alternative to MISRA C++, for instance. Right now SPARK would definitely be favorable. But I think even current Rust would be much safer than MISRA C++.
  - MaxBarraclough 6y ago
    > are you sure every programmer on Chromium is a genius? Google has a hard Interview process, but does it filter out every bad engineer? I suspect that yes, it filters out all candidates who are outright bad. I don't think this point really matters though. If even Google aren't able to produce a large C++ codebase free of buffer-overflows, even when it really matters, it suggests that no-one can. edit This doesn't need to be an argument drawn from a single sample, either. Buffer overflows happen to just about all major C/C++ codebases. OpenSSL, the Linux kernel, Windows, the Apache Web Server, nginx, etc. We could quibble about the way they don't use the sort of methodology used in avionics software development, but I don't think there's much value in exploring that. If Google consider that to be too slow/costly for Chromium, it highlights how rarely those methodologies can practically be used. I don't think there are any individual C++ programmers who are too smart to ever introduce undefined behaviour, but even if there were it wouldn't matter. As you indicate, real large-scale software development happens with teams, not lone geniuses. > I think even current Rust would be much safer than MISRA C++. I agree that the language might be a reasonable choice, but I don't think the Sealed Rust project is anywhere near delivering a Rust compiler that can be trusted with your life. Even mature C compilers can have serious bugs, [0] and compiling Rust is far more challenging than compiling C. [0] [PDF] Finding and Understanding Bugs in C Compilers, Regehr et al, 2011, https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf
hutzlibu 6y ago
"Even if a company has a few brilliant C programmers on staff, they won't be able to find all the issues the mediocre programmers produce." Also, I am very sceptical, that even brilliant C programmers won't have a bad day, lack of sleep or distracted by personal problems - to avoid misstakes. And about ADA, have you experience with it? What could be the reason, it is not used on a broader base? I assume also lack of libaries, etc.? I mean, there are millions of free and open C and C++ libaries around for allmost any usecase, I assume this is not the case with ADA? edit: about ADA https://www.electronicdesign.com/technologies/iot/article/21801203/comparing-ada-and-c https://www.electronicdesign.com/technologies/iot/article/21... is a good comparison of C and Ada, I found. Basically with ADA, you develope much slower (and performance is usually lower). But if you want reliability, it does sound good.
- carlmr 6y ago
  I have only hobbyist experience with ADA. It didn't seem nearly as hard as a lot of people said it was, and I was intrigued about in which ways it's safer than C. My best guess is that people are unfamiliar with ADA, unwilling to learn, and most of all believe that hiring will turn into a problem if they switch to ADA. Also they bring up the brilliant programmer theory. The hiring problem seems superficially compelling. There are indeed fewer ADA programmers out there, which of course is a chicken and egg problem if companies are not trying to adopt it. Now the fourth argument often follows the third argument. My problem with it is that most of the programmers I've worked with that I'd describe as brilliant are the first ones to tell you that we should use a safer language, because they know even they make mistakes. And a lot of the brilliant programmers wouldn't have trouble picking up ADA or learning something new. So my answer would be that if you truly have brilliant programmers, you don't need to worry about hiring. If you don't have those brilliant programmers you really can't afford staying with C because you will have huge costs from debugging and being sued for the bugs you didn't find.
- MaxBarraclough 6y ago
  > I assume also lack of libaries, etc.? I think that's a part of it. Few GUI toolkits can easily be used from Ada, for instance. Ada has excellent support for interfacing with C code, but making decent bindings is never trivial. I think lack of hype might be part of it too. Ada is seen as a stodgy and boring language good for writing autopilot software, whereas Rust and Zig are seen as new and exciting general-purpose programming languages. I'm not saying Rust and Zig bring nothing new to the table, of course, as they both do, but in terms of safety and programming with an emphasis on correctness, Ada has a lot to offer.

by carlmr 6y ago

MaxBarraclough 6y ago

> the brilliant C programmer hypothesis is almost untested, since most companies hire mostly average C programmers. It's only logical that non-brilliant programmers will be working somewhere. Chromium has suffered from buffer-overflow issues, and that's a high-profile security-sensitive C++ codebase run by Google. > Rust doesn't have the necessary certifications yet, but industry would be wise to contribute I'd rather avionics code be written in verified SPARK than in Rust, but if they can build a rock-solid Rust compiler it would be good to have it compete in that space. I imagine it could be a nice alternative to MISRA C++, for instance. As you've probably gathered from my mention of SPARK, I agree with you that Ada is sadly overlooked. Turns out that the basic idea of an imperative language that's much like C/C++ but is much safer and better suited to automatic runtime checks, isn't a new one. Ada does this, it's existed since around 1980, it's mature, there are various compilers for it approved for life-critical work, and its performance matches that of C if runtime checks are disabled. It's comparable to Zig and Rust in that regard, but those languages aren't the first to aim for C performance with far superior safety properties. > there's no reason other industries couldn't use it. Right, especially considering the fine work done by AdaCore, who make their tooling available as Free and Open Source software. Perhaps Ada's reputation for being boring is its greatest vice, as well as its greatest virtue?

carlmr 6y ago
>Chromium has suffered from buffer-overflow issues, and that's a high-profile security-sensitive C++ codebase run by Google. Like I said, I haven't worked at Google. But are you sure every programmer on Chromium is a genius? Google has a hard Interview process, but does it filter out every bad engineer? And if Google's "probably better than other company's" engineers can't do it? How can we expect other companies to deal with C? >I'd rather avionics code be written in verified SPARK than in Rust, but if they can build a rock-solid Rust compiler it would be good to have it compete in that space. I imagine it could be a nice alternative to MISRA C++, for instance. Right now SPARK would definitely be favorable. But I think even current Rust would be much safer than MISRA C++.
- MaxBarraclough 6y ago
  > are you sure every programmer on Chromium is a genius? Google has a hard Interview process, but does it filter out every bad engineer? I suspect that yes, it filters out all candidates who are outright bad. I don't think this point really matters though. If even Google aren't able to produce a large C++ codebase free of buffer-overflows, even when it really matters, it suggests that no-one can. edit This doesn't need to be an argument drawn from a single sample, either. Buffer overflows happen to just about all major C/C++ codebases. OpenSSL, the Linux kernel, Windows, the Apache Web Server, nginx, etc. We could quibble about the way they don't use the sort of methodology used in avionics software development, but I don't think there's much value in exploring that. If Google consider that to be too slow/costly for Chromium, it highlights how rarely those methodologies can practically be used. I don't think there are any individual C++ programmers who are too smart to ever introduce undefined behaviour, but even if there were it wouldn't matter. As you indicate, real large-scale software development happens with teams, not lone geniuses. > I think even current Rust would be much safer than MISRA C++. I agree that the language might be a reasonable choice, but I don't think the Sealed Rust project is anywhere near delivering a Rust compiler that can be trusted with your life. Even mature C compilers can have serious bugs, [0] and compiling Rust is far more challenging than compiling C. [0] [PDF] Finding and Understanding Bugs in C Compilers, Regehr et al, 2011, https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf

hutzlibu 6y ago

"Even if a company has a few brilliant C programmers on staff, they won't be able to find all the issues the mediocre programmers produce." Also, I am very sceptical, that even brilliant C programmers won't have a bad day, lack of sleep or distracted by personal problems - to avoid misstakes. And about ADA, have you experience with it? What could be the reason, it is not used on a broader base? I assume also lack of libaries, etc.? I mean, there are millions of free and open C and C++ libaries around for allmost any usecase, I assume this is not the case with ADA? edit: about ADA https://www.electronicdesign.com/technologies/iot/article/21801203/comparing-ada-and-c https://www.electronicdesign.com/technologies/iot/article/21... is a good comparison of C and Ada, I found. Basically with ADA, you develope much slower (and performance is usually lower). But if you want reliability, it does sound good.

carlmr 6y ago
I have only hobbyist experience with ADA. It didn't seem nearly as hard as a lot of people said it was, and I was intrigued about in which ways it's safer than C. My best guess is that people are unfamiliar with ADA, unwilling to learn, and most of all believe that hiring will turn into a problem if they switch to ADA. Also they bring up the brilliant programmer theory. The hiring problem seems superficially compelling. There are indeed fewer ADA programmers out there, which of course is a chicken and egg problem if companies are not trying to adopt it. Now the fourth argument often follows the third argument. My problem with it is that most of the programmers I've worked with that I'd describe as brilliant are the first ones to tell you that we should use a safer language, because they know even they make mistakes. And a lot of the brilliant programmers wouldn't have trouble picking up ADA or learning something new. So my answer would be that if you truly have brilliant programmers, you don't need to worry about hiring. If you don't have those brilliant programmers you really can't afford staying with C because you will have huge costs from debugging and being sued for the bugs you didn't find.
MaxBarraclough 6y ago
> I assume also lack of libaries, etc.? I think that's a part of it. Few GUI toolkits can easily be used from Ada, for instance. Ada has excellent support for interfacing with C code, but making decent bindings is never trivial. I think lack of hype might be part of it too. Ada is seen as a stodgy and boring language good for writing autopilot software, whereas Rust and Zig are seen as new and exciting general-purpose programming languages. I'm not saying Rust and Zig bring nothing new to the table, of course, as they both do, but in terms of safety and programming with an emphasis on correctness, Ada has a lot to offer.