Submitting it not for the job listing or to spam Thales, but because I’m surprised such critical software (possibly life threathning) is written in an “unsafe” language.
We’ve been writing safe code in unsafe languages for a lot longer than safe languages have been around. You can always obtain safety through rigorous (and tedious) human processes and controls as well.
I’m in aerospace, we use C++ all the time for both safety-critical and performance-critical code. Rust on microcontrollers seems to be coming along nicely for some specific applications (Oxide being a great example where they’ve essentially built their own all-Rust RTOS but it has limited MCU support so far) but is a long long way from being the norm.
I’m actually more surprised about this line:
to take part in one of our development teams, which are multidisciplinary and self-organizing Agile/Scrum team
My team does Kanban-style firmware with a some planning up front (we have to plan out how the hardware is going to work before laying out circuit boards, as an example, or doing a trade study on which protocol stack we want to use for communication between microcontrollers and processors) but we do handle a lot of our software design work in a “make it work, refactor as needed to keep it high quality” iteration loop. It’s been working effectively for us but I’d be really curious how it scales to larger companies and teams like what they have at Thales.
I’m in air traffic control software. It’s all C++ for performance and hiring reasons. The industry isn’t against considering other options; around six years ago my company looked at Rust for a new product but it was still too rough at the time. Maybe today we’d have picked it.
We have other processes to help with C++ being what it is. Everything is run through valgrind and sanitizers, there are tests for most things, a big QA department, in-house debugging tools, and more.
critical software (possibly life threathning) is written in an “unsafe” language.
A critical system certainly has quality standards for each individual component, but often the real trick is making the system as a whole work, expecting that something, somewhere, is going to fail regardless of how hard you try to make perfect parts. So while I’m sure they have their processes in place to avoid C++ trouble, I’m equally sure they design everything that when the code inevitably fails, there’s a backup plan to save things from going too bad. For example, there might be two separate programs, written by entirely different teams with different paradigms, so they check each other. I’m sure at some point, there’s a procedure the sailors drill on in case of total computer failure too. (Think how on a commercial flight, there’s two sets of controls, two pilots, etc., so if one of them has trouble the other can take over without delay, and when all is going well, they help each other with the work so things are less likely to get to serious trouble.)
Of course, it also possible they want C++ experience but are using that as a proxy for general programming knowledge, and actually use something else, with the idea that if you’re good at C++, you can learn what they need you to learn on the job. (I know a few companies that use D advertise it as requiring C++ knowledge, since the skills are generally crossover and they’re more likely to get applicants for popular C++ than for obscure D on the general market.)
One of the first jobs I applied for (~1996) was for some company using embedded C/C++ for control software on nuclear sub engine systems. Thankfully for everyone there was a snafu which meant I found another job in a much less safety critical industry before they got back to me with an offer.
My marginally educated guess from hanging around the aerospace industry for a good chunk of my career is that the UI will be written in Java and run on some kind of hardened/minimal Windows machine (probably an industrial integrated board) and then the code that is doing most of the sensing and math will be C++ on embedded Linux/RTOS/some kind of microcontroller.
And honestly… I’m not actually sure that in 2024 I’d choose a different tech stack. While Java UIs in 2024 don’t necessarily routinely coming out looking as clean as something native, Qt-based, or Electron-based, Thales likely has a very standardized set of UI components and tooling that will feel familiar to their users without needing a bunch of retraining. Those UI components would also likely be tailored very well to the specific use cases of being used on the bridge of a ship (high contrast, large text on a daylight-readable display, potentially touch-compatible or interfacing to a non-standard set of physical buttons and knobs).
On the computation side… the code that actually computes the firing solutions is likely not new but rather as been (literally) battle-tested for years. There’s a non-zero chance that it’s actually written on Fortran (like a bunch of the BLAS and LAPACK stuff is). I know there are some FFI issues integrating C++ code and Rust code; I can only imagine what that would look like trying to integrate Rust and Fortran code.
I loathe BitBucket but the Atlassian suite is very popular in government, defence contractors, and similar large organizations. At least, it was until Atlassian changed their pricing to make running your own on-prem suite prohibitively expensive: everyone seems to be switching to GitLab now.
Submitting it not for the job listing or to spam Thales, but because I’m surprised such critical software (possibly life threathning) is written in an “unsafe” language.
We’ve been writing safe code in unsafe languages for a lot longer than safe languages have been around. You can always obtain safety through rigorous (and tedious) human processes and controls as well.
I’m in aerospace, we use C++ all the time for both safety-critical and performance-critical code. Rust on microcontrollers seems to be coming along nicely for some specific applications (Oxide being a great example where they’ve essentially built their own all-Rust RTOS but it has limited MCU support so far) but is a long long way from being the norm.
I’m actually more surprised about this line:
My team does Kanban-style firmware with a some planning up front (we have to plan out how the hardware is going to work before laying out circuit boards, as an example, or doing a trade study on which protocol stack we want to use for communication between microcontrollers and processors) but we do handle a lot of our software design work in a “make it work, refactor as needed to keep it high quality” iteration loop. It’s been working effectively for us but I’d be really curious how it scales to larger companies and teams like what they have at Thales.
The fun part about “agile” is that it’s just a word. As long as you have “sprints” every two weeks you can keep waterfalling to your heart’s content.
I’m in air traffic control software. It’s all C++ for performance and hiring reasons. The industry isn’t against considering other options; around six years ago my company looked at Rust for a new product but it was still too rough at the time. Maybe today we’d have picked it.
We have other processes to help with C++ being what it is. Everything is run through valgrind and sanitizers, there are tests for most things, a big QA department, in-house debugging tools, and more.
This may vary between locations, but a lot of the air traffic control software I’ve seen was Ada. Zero downtime in twenty years was their boast.
A critical system certainly has quality standards for each individual component, but often the real trick is making the system as a whole work, expecting that something, somewhere, is going to fail regardless of how hard you try to make perfect parts. So while I’m sure they have their processes in place to avoid C++ trouble, I’m equally sure they design everything that when the code inevitably fails, there’s a backup plan to save things from going too bad. For example, there might be two separate programs, written by entirely different teams with different paradigms, so they check each other. I’m sure at some point, there’s a procedure the sailors drill on in case of total computer failure too. (Think how on a commercial flight, there’s two sets of controls, two pilots, etc., so if one of them has trouble the other can take over without delay, and when all is going well, they help each other with the work so things are less likely to get to serious trouble.)
Of course, it also possible they want C++ experience but are using that as a proxy for general programming knowledge, and actually use something else, with the idea that if you’re good at C++, you can learn what they need you to learn on the job. (I know a few companies that use D advertise it as requiring C++ knowledge, since the skills are generally crossover and they’re more likely to get applicants for popular C++ than for obscure D on the general market.)
One of the first jobs I applied for (~1996) was for some company using embedded C/C++ for control software on nuclear sub engine systems. Thankfully for everyone there was a snafu which meant I found another job in a much less safety critical industry before they got back to me with an offer.
Also, both Java and C++. Also code hosted on BitBucket for a national security critical piece of code?
Governments, they really are just like -us- large bumbling enterprises too.
My marginally educated guess from hanging around the aerospace industry for a good chunk of my career is that the UI will be written in Java and run on some kind of hardened/minimal Windows machine (probably an industrial integrated board) and then the code that is doing most of the sensing and math will be C++ on embedded Linux/RTOS/some kind of microcontroller.
And honestly… I’m not actually sure that in 2024 I’d choose a different tech stack. While Java UIs in 2024 don’t necessarily routinely coming out looking as clean as something native, Qt-based, or Electron-based, Thales likely has a very standardized set of UI components and tooling that will feel familiar to their users without needing a bunch of retraining. Those UI components would also likely be tailored very well to the specific use cases of being used on the bridge of a ship (high contrast, large text on a daylight-readable display, potentially touch-compatible or interfacing to a non-standard set of physical buttons and knobs).
On the computation side… the code that actually computes the firing solutions is likely not new but rather as been (literally) battle-tested for years. There’s a non-zero chance that it’s actually written on Fortran (like a bunch of the BLAS and LAPACK stuff is). I know there are some FFI issues integrating C++ code and Rust code; I can only imagine what that would look like trying to integrate Rust and Fortran code.
I loathe BitBucket but the Atlassian suite is very popular in government, defence contractors, and similar large organizations. At least, it was until Atlassian changed their pricing to make running your own on-prem suite prohibitively expensive: everyone seems to be switching to GitLab now.
Why did BitBucket surprise you so much?