Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

At that level of reliability, language matters surprisingly little since everything is heavily tested, reviewed, hand verified, etc... Language safety is a cheap high-value solution, but might not make sense when coupled with other more expensive safety solutions (imagine wearing a simple seatbelt with a complete safety harness, they aren't additive). C/C++ have other benefits: minimal abstraction, lots of trained up talent.

View on HN

If there are no bugs, you're right. However, every bug that does ship becomes harder to debug, and so does every bug you fight with during development. The impact of bugs becomes more severe and less predictable on average (dangling reference or buffer overflow can affect pretty much anything.)

The more accurate analogy is seatbelts' utility in a car fitted with various collision avoidance devices all the way up to fully autonomous driving. I say you'd still want the seatbelt for when collision does occur after all.

Again, the assurances you get from a seatbelt are dwarfed by the safety harness, they aren't additive. That is, you are going to have to check everything very carefully anyways, anything that allows you to be less careful then isn't very useful, and can actually be counterproductive. Continuing the analogy, the cheap seatbelt kills you when combined with a fancy safety harness/ejection system; it isn't helping, and it can actually hurt.

I agree that the resulting quality doesn't really depend on language choice. I just wonder about the development cost. For example, a lot of time can be spent reviewing code and checking that no unsafe constructs are used. A safe language makes that unnecessary. Some of those checks can be automated, but in my experience there is still a lot of manual checking going on.

I think that the main advantage of C/C++ is the number of people who speak it. But my guess is that the time to train a competent programmer in a safe language can be easily saved in improved productivity.

The main advantage of C (and, to a lesser, but still very significant degree, C++) in this field -- besides the number of people who speak it -- is the availability of a great deal of mature, well-tested compilers, static analysis tools and so on.

We have about 40 years of experience writing C compilers today (and we still screw it up sometimes; C++ is... well, I mean, we have about 30 years of experience writing C++ compilers, but those are still in the "mostly right" state). Many subtleties of the language are well understood and many problems have had idiomatic, well-known, widely-used solutions for decades now.

Ada would be a good choice for such projects but for the relative flimsiness of its ecosystem. It's a great language, but its development is fairly underfunded, and back when all this stuff was happening, its future was very uncertain (it still is, I guess).

And when I say "fairly underfunded" and with a "very uncertain" future, you should understand that I mean "it used to be funded by the DoD, but with various levels of commitment" and "only a few companies, most of them government contractors, and maybe a few state institutions along with a small, but enthusiastic community were pushing for it".

Its fame on HN and Reddit may not indicate it, but Rust fares even worse in this regard. Ten years from now, Rust may not even exist anymore.

It's not only about technical merit. Projects like these would benefit a lot from being written in Ada (and Rust, too, I guess -- it's a great language), provided that there were such a well-developed ecosystem around either of them. But there isn't. E.g. when choosing their static analysis tools, these guys settled for the top 5 solutions. Top 5! They evaluated a bunch of programs and settled for the best 5. I don't think there are 5 static analysis solutions for Rust in total (and I'm pretty sure there are only two or three for Ada that have been maintained after 1999 or so).

Excellent response. My default recommendation is Ada + SPARK but I can easily recommend a C subset + tooling for those reasons. Especially on the compiler issue as it's known that Ada compilers aren't what they advertise themselves to be. The static analysis observation I'm not as sure about. A combo of SPARK, safe concurrency, the monitor concept w/ restarts or failovers, and one analysis tool should cover about anything they want. There's a quality vs quantity effect in Ada vs C static analysis where I can't be sure which wins here.

The ecosystem is really weak, though. There's no doubt about that. I don't see that changing regardless of whether Ada stays around. It's why I'm excited about Rust's mainstream adoption where it might get where Ada is or exceed it as tooling improves. It's one of few times mainstream goes for The Right Thing over Worse is Better. Eiffel, esp SCOOP model, being another good example that has significant momentum. The CompSci people are doing amazing things with SCOOP extensions right now that could be implemented in an Ada successor.

So, still potential at least. Plus, at least our tooling for C is now good enough to emulate Ada's safety with the right people doing the work. Plus, we only have to buy 5 tools now. Much improvement over old days. ;)

> It's why I'm excited about Rust's mainstream adoption where it might get where Ada is or exceed it as tooling improves.

Me too! We had a great chance with Ada and we kindda wasted it. Rust is literally a second chance. This is pretty rare in tech.

I'd point out that C only got to this stage of tooling maturity by being around a while -- it's not like less than a year after its first "stable" release it was in that state (which is the current age of the Rust stable releases). If Rust manages enough staying power to be here in 20/30/40 years, who knows. Every grizzled and battle-hardened language ecosystem needs to start out young and a bit wild-west-ish before it can gain legitimacy and rock solid tooling.

Exactly! There's nothing really wrong with Rust -- it's a good language -- but people in this space (and in the embedded world in general, myself included) are skeptical of it simply because reliability is not only something that's inherent to a design, but also something that a) has to be a quality of an implementation, not just of the principles behind it, and b) something that has to be proven in practice, both for the principles and for the implementation.

Edit: for what it's worth, I do think it's on the right track on both accounts!

What safer languages you would recommend?

He mentionned Ada and Rust in his initial comment.

C is the most widely used and deployed language in the world and it has a very long tenure. I would trust it much more with billions of dollars at stake than a less proven language like Rust. And as a C programmer, it's really not a bad language, and it makes sense for this application.

Exactly. Rust is great for deployments which can't afford such rigorous testing processes; for NASA however any abstraction above the bare minimum is just another risk.

Reply on news.ycombinator.com