I think that's the key. There was ADA now there's Rust. If you can have GC on your system there are plenty of other languages that make strong static typing and other compile time guarantees that beat any analyzed C++.
Is static typing really what you want? I would think that if you want safety against failure, you really want redundant systems that live in separate failure domains and can coordinate in the event of failure.
Why can't you have that with static typing? Btw I think only strong static typing really helps (C is statically typed but allows way too many implicit conversions).
There's also the question of what you regard as safety. Fault tolerance (like in elixir/erlang), or a design for fewer faults (e.g. ADA/Rust)?
Fault tolerance is good for high availability, which can be a safety goal (e.g. What does your airplane do when all the computers are off?) it doesn't help you however if yoir software didn't crash but does the wrong thing (like the boeing).
For the second part, strong static type systems definitely help, they provide clear documentation what can and can't be done, and they cause as many compile time errors if you do the wrong thing as possible. It doesn't rule everything out, but it gets you closer to the goal of correctness.
Fault tolerance is still needed. Usually you want to have redundancy (I think most airplanes use 5 controllers calculating at the same time to prevent atmospheric radiation causing bit flips to cause issues). And you want the system to go into safe states (e.g. Detect a fault and reinitialize, if that doesn't work do your best to stay operational until you've reached safety).
I think we could probably take over some of the supervision ideas from elixir, but combine it with strong static typing guarantees.
Static typing doesn't help you if your software doesn't crash but does the wrong thing (like the Boeing). In that case not even dimensional analysis helps you, because by my understanding that code was really stupid.
I find that if you're only documenting via types, that's a problem. You should also document by writing documentation.
I dont think anybody argues that types replace documentation. However, documentation without types tends to get repetitive and requires you to come up with ways to structure it properly. Turns out, you can encode a lot of information into a type and now it can be automatically verified and frees you to write documentation for things that can not be expressed in types.
Our safety critical languages need to be simpler, so they are amenable to mechanical proofs and exhaustive model checking. Dimensional units would be a good start.
F# has those built in (not mission critical embedded ready, but a very very nicely designed language).
ADA hat strongly typed fixed point built in. Rust I think has a strong enough type system to implement this as a library, at least there seem to be a few.
Idris also looks interesting. Maybe something like this can be done with dependent types.
There's nothing to fix. The fire is either of a type that may be extinguished and a trained firefighter decided to put this type of fire out for everyone, or the fire is unable to be extinguished as was the intention of the entity that started it.
If it's the former, find the correct firefighter, if it's the latter, use a different fire.
There's nothing to fix. The construction material is either of a type that does not spontaneously combust, and a carpenter can make you a fine chair out of it, or the material is the type to spontaneously combust, and if you choose to buy a chair made of that material you will soon find your pants are on fire.
If it's the former, pay a contractor to build you a chair, or make one yourself. If it's the latter, use a different construction material.
There is nothing to cure. The pathogen is either of a type that is curable, and a licensed medical professional can prepare a treatment regimen, or the pathogen will liquefy all of your internal organs within minutes, and if you choose to expose yourself to the latter pathogen, you will find yourself having a bad day very quickly.
If it's the former, pay a licensed medical professional or read online forums and do it yourself. If it's the latter, contact your nearest funeral home.
This reminds me of an elevator's "Door Close" button. Manufacturers still include them for the peace of mind of passengers, despite computerized systems and many area laws (in the US, the ADA has language regarding door-open timespan for wheelchair access).
EDIT: Thanks to a_c_s for pointing out that the button can work when the elevator is in emergency/service mode. More fun information on elevators, crosswalk and other buttons can be found here: https://www.nytimes.com/2016/10/28/us/placebo-buttons-elevat...
In my office (in Germany), when the elevator door opens and I hold the "close door" button, it immediately starts closing as soon as it's finished opening. So at least that one is definitely not a placebo.
Elevator "door close" buttons can fall into several categories.
1. They work as labeled, immediately closing the door.
2. They work, but only after door has been open longer than a threshold time, or only if the door open time has been extended using the "door open" button.
3. They work, but only when the elevator is in some special mode such as fire/emergency mode.
4. They are supposed to work, but broke. A broken "door close" button does not put the elevator out of service, and might not even be noticed at all (especially if it is a category #2 button) for a long time, and so a broken "door close" button can stay broken for a very long time.
5. They would work except they have been disabled by the owner, perhaps to comply with laws, or perhaps because there were too many assholes prematurely shutting doors.
Likely because they've found the tech attractive to buyers compared to "hey, we have another mirror on this mirror" - and that they can pad their dealer network's income stream from the all-too-common side mirror repair/replacement.
But, yes. From a practical standpoint - it's utterly bizzare to me as well!
