I actually met a programmer who worked on military jets. According to her, Ada is only used anymore for the older jets that were already programmed in it, and she worked in C++.
No need to be so dramatic. Shitheads will make software fail in any language. Memory "safety" will not help you correctly and in timely manner calculate position of flight controls for example.
One can write reliable, and I mean airtight good enough for medical devices and nuclear deterrence, in basically any even vaguely modern language (think Algol-60 or later). It’s simply a matter of disciplined design and running on hardware that’s sufficiently predictable.
Most aerospace stuff is. The thing is, they have reams of very specific rules about how it's coded, how to verify that code, and how to verify the compiler of that code, and how to verify the code output from that compiler. It's not an easy process to replace, but its proven reliable just by all the commercial planes flying every day without falling out of the sky.
In theory, something like Rust could do the job instead, but they'd still have to verify the entire chain. Rust is for the rest of us to get something half as reliable as that while also being able to write more than two lines of code per day.
I wouldn't trust USB flash drives with anything long term. Best archival method would be to print something out (perhaps an encrypted message in a QR code), have it put away somewhere secure, and use that for a key to unlocking everything else.
Yes, this, USB flash drives live at most 5 years or something. Things get even worse for SSD.
If we are talking just about credentials, you can just print the password and access instructions to a password manager and give it to the people you trust. This is one place were having a cloud password manager might be helpful, otherwise you would need to also provide the access to a device containing the offline manager (or a updated copy of it)
You probably don't need to keep a whole flash drive for credentials. Unless you also want to keep some other files secure without being on other devices
Bitcoiners have been thinking about this storage problem for a decade now. Secure electronic devices in faraday cages and tamper and water proof bags or engraved steel plates (possibly cut up and distributed) seem to be the way to go for storing small bits of extremely valuable information.
Or of course you can use multiple key storage techniques and have a 2 out of 3 or more type setup. It all depends on how valuable the information is.
Security against unauthorized use and data lifespan are separate concerns. They're not fully orthogonal—security tends to make things more brittle—but you can apply whatever form of security you like and then store the secured data in any way you like. Hardburn seems to have been talking purely about the useful life of the archived data. The charge in flash storage leaks, so the data is eventually lost if not refreshed. A flash drive is reliable for a year, but not a decade. If you want long term storage you're going to want something else. Paper would be fine for most uses. An ordinary printout subjected to ordinary handling is good for a few decades with reasonable storage conditions.
Which also gives away some gaps in the author's knowledge.
Perl wasn't following the PCRE standard. It was the PCRE standard. Everything else was following it. Usually with some piece missing--far more implementations should have the /x modifier.
The Perl 6 design process didn't throw it away after 30 years. It threw it away with less than 10 years. There was already widespread knowledge that Perl had gone beyond "regular expressions", and IIRC, that was even before it had implemented recursive expressions. Perl 6 would be "patterns", and they would be good enough to be used as a full grammar. The language itself could be parsed in it, and Raku sometimes is, depending on the implementation.
But it is also true that Raku’s grammars were designed from the start to write real parsers in, whereas Perl 5’s regexes sort of gradually got that way.
It doesn't go the speed of light in copper, either. In fact, that study has a nice table on page 5. Looks like other than thick coax, fiber is a bit faster than most copper options.
