Hacker News Reader

Comment by uoaei | Hacker News Reader

Gonna be a long while before safety and certification bodies for industries like aerospace move away from C++. All the tools for the past few decades focus on C++ as the main systems language in these cases.

Rust is great as a spiritual successor with more stable performance (in general) but the institutional inertia with C++ is strong.

View on HN

In this aerospace company, we use C, no C++ allowed, to avoid all the extra footguns that get in the way of safety and certification. Rust will probably be the next choice on the scene, but I expect it'll take as long to come as Ada took to go.

In this aerospace company, we use C, and sometimes a subset of C++ that is basically C+epsilon. That's all new, however, so each new project that goes that direction is walking a dark forest.

We've got some Rust on the ISS, but honestly, the interest from the serious FSW folks isn't there.

There is some interest in safety-critical Rust: https://ferrous-systems.com/ferrocene/

But it's going to take a lot of time and work.

> Rust will probably be the next choice on the scene

I'm not sure about it.

I think Rust might be hard to certify for aerospace usage.

Not because it's bad, but because it's still complex. Just a lot of negative side effects of complexity are contained due to the compiler checks and design.

But that makes it harder to certify as I can tell.

Would it be a plausible way forward to set a certification procedure that forces a certain compiler configuration?

Off topic, but curious why Ada went?

Would also be curious to know this. I had heard (anecdotally) that Ada is commonplace in aerospace tech.

I only have limited experience, but I’ve seen projects migrate from Ada to C++ more often than the other way around. If I had to guess why, it’s probably because it’s easier to hire for.

As counter example, NVidia a C++ powerhouse, is using Ada for their autonomous vehicles firmware.

Ada relied on colleges teaching it or Pascal, so then it became hard to hire. I understand the rationale behind this, but the language is surprisingly easy to learn because it's usually explicit and straightforward.

It suffered from two decades of bad press due to being forced by the DoD and then almost two decades of no press. Looking at Google ngrams, C (due to Unix) took big chunks out of it and then Java gave the death blow by becoming a major teaching language. Ada 2012 had the capability to do for Ada what C++11 did for C++, but it wasn't sold well.

I picked up Ada 2012 last year and made a tool I use everyday now for real work--it's not a bad language. It suffers from a lot of myths about it, but the tool modernization like getting a package manager makes it productive. It is "boring" in the sense that there's nothing flashy about it, and its surface verboseness which saves other code later, and lack of curly braces turns people off. The community is super small and nice, but it never learned to sell the benefits of the language.

What's the state of Rust/C++ interop currently? Naively it seems like allowing Rust in C++ projects could be a reasonable way forward, but I haven't tried it personally yet.

It's fine, works well enough. Challenges are passing data across the boundaries as the data types need to conform to both sides. E.g. using a string in both languages without doing copies means using a C-style string and now you've lost some expressiveness in both languages.

Second challenge is smoothness of integration in build systems. In C++ you might use CMake, in Rust you use Cargo, so now who is authoritative? Do you use Cargo to build the C++ code? Do you build your Rust projects in CMake?

C++ doesn't have a well defined ABI. So the interropt between rust and C++ is mostly over a C ABI bridge. For the most part, that's not too painful.

cxx, the high-level Rust/C++ interoperability layer, is currently used in production at large scale.

I think you're implicitly saying that Rust solves the problems in the article, and so migrating C++ projects to use Rust is a path forward. However, the blog author's first example was implementing a "contiguous circular queue", so you should try to do that in Rust. Of course Rust already has VecDeque<T>, but then C++ already has std::deque<T> too (although not promised to be contiguous). So the exercise is to implement your own, from scratch, without just wrapping a type that does the dirty work for you.

If you look closely at the implementation details for VecDeque<T>, you'll find a lot of complexity you might not expect. To do it efficiently and correctly, you need to work with unitialized memory. So there will be unsafe blocks in there. A VecDeque<T> is built of a RawVec<T>, which uses a Unique<T>, which finally has a pointer, but also contains a magical PhantomData<T>. Look at the code [0] [1] [2] [3], look at the implementation details, read the comments, and assess for yourself if it's easier or harder than C++.

Later in the article, he talks about exception safety. For something like a container, the most likely exceptions are that you've run out of memory, or you can't move/copy/construct an item in the container. I'm honestly not sure how Rust's builtin containers handle these problems. (Panic?) But if you're comparing the two languages, the apples and oranges matter.

All of this to say that Rust is not simple either. You can program Rust by using its standard collections, and you can do the same with C++. If you try to implement those collections, say for learning/teaching data structures, both languages seem painfully complicated to me.

[0] https://doc.rust-lang.org/src/alloc/collections/vec_deque/mo...

[1] https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#52

[2] https://docs.rs/ptr/0.1.0/src/ptr/lib.rs.html#39-47

[3] https://doc.rust-lang.org/src/core/marker.rs.html#679

> Later in the article, he talks about exception safety. For something like a container, the most likely exceptions are that you've run out of memory, or you can't move/copy/construct an item in the container. I'm honestly not sure how Rust's builtin containers handle these problems. (Panic?)

As I understand it yes, the containers will panic.

Part of the discussion about using Rust in the Linux kernel is what to do about failed memory allocations. And this is a problem more generally for Rust usage in embedded systems.

So there may need to be support for alternative allocators or something else.

Part of the key is that they’re not really “built in.” They’re in the standard library. When you’re in those contexts, you just don’t use the standard library. Problem solved.

Now, the standard library is also getting support for these things not panicking on allocation failure, and when that’s ready enough for those that want it (Rust for Linux has pulled the changes into their tree, in my understanding) then they could use them.

(I work on embedded systems with no dynamic allocation, Rust is great.)

Aerospace industry? C++? Frightening.

I thought Ada is prevalent in this space.

I'm not in the industry but from what I know it's a split between Ada/C/C++. More space related applications tend to be C/C++ (satelites, rovers, etc.) while the aero-side uses more Ada (Boeing, Airbus etc.).

Ada never really "won". It was mandated by DOD, but the industry more or less rebelled at the idea. Fortran was pretty common, but C and C++ are the dominant languages. The last greenfield aerospace (avionics) project I was on, we were given a choice and it seemed that we (and everyone else) went with C or C++. There are a lot of static analysis tools now that cover most of what you get from Ada (and then some, even with SPARK), but the choice was really based on familiarity for potential new hires. You also use strict subsets of C or C++ in this field, not every feature will be available. (I wish it had been in Ada, a lot of issues in the system wouldn't have happened in Ada, but they did eventually get worked out anyways.)

Reply on news.ycombinator.com