I have to disagree here. All of these you mentioned have regularly bugs. Multiple spacecraft got lost because of these. For planes there's not so distant Boeing 737 MAX fiasco (admittedly this was bad software behavior caused by sensor failure). And medical devices, the news about their bugs semi-regularly pop up. So while the software for these might do a bit better than the rest, they certainly are not anywhere close to being bug free.
And same goes for specifications the software is based on. Those aren't bug-free either. And writing software based on flawed specification will inevitably result in flawed software.
That's not to say we should give up on trying to write bug free software. But we currently don't know how to do so.
You could say that Python is designed around preventing these memory bugs.
Security and reliability are also parameters that exist on a sliding scale, the industry has simply chosen to slide the "cost" parameter all the way to one end of the spectrum. As a result, the number of bugs and hacks observed are far enough from the desired value of zero that it's clear the true requirements for those parameters cannot be honestly said to be zero.
Zero is not the desired number, particularly not when discussing "hacks". This may not matter in current situation, but there's a lot of "security maximalism" in the industry conversations today, and people seem to not realize that dragging the "security" slider all the way to the right means not just the costs becoming practically infinite, but also the functionality and utility of the product falling down to 0.
Mind, I'm not talking about financial overhead for the company/developer(s), but rather an UX overhead for the user. It often increases friction and might even need education/training to even make use the software it's attached to. It's much like how body armor increases the weight one has to carry and decreases mobility, security has (conceptually) very similar tradeoffs (cognitive instead of physical overhead, and time/interactions/hoops instead of mobility). Likewise, sometimes one might pick a lighter Kevlar suit, whereas othertimes a ceramic plate is appropriate.
Now, body armor is still a very good idea if you're expecting to be engaged in a fight, but I think we can all agree that not everyone on the street in, say, a random village in Austria, needs to wear ceramic plates all the time.
The analogy does have its limits, of course ... for example, one issue with security (which firmly slides it towards erring on the safe side) as compared to warfare is that you generally know if someone shot at you and body armor saved you; with security (and, again, privacy), you often won't even know you needed it even if it helped you. And both share the trait that if you needed it and didn't have it, it's often too late.
Nevertheless, whether worth it or not (and to be clear, I think it's very worth it), I think it's important that people don't forget that this is not free. There's no free lunch --- security & privacy are no exception.
Ultimately, you can have a super-secure system with an explicit trust system that will be too much for most people to use daily; or something simpler (e.g. Signal) that sacrifices a few guarantees to make it easier to use ... but the lower barrier to entry ensuring more people have at least a baseline of security&privacy in their chats.
Both have value and both should exist, but we shouldn't pretend the latter is worthless because there are more secure systems out there.
Today a bank really sent me a legitimate email about trying their new site. Went over, it was their site alright, logged in with correct username and password - poof, instantly blocked for suspicious access (from my usual home machine), call helpline to fix.
Now that's safe ... and useless. But safe.
I still wonder what did I do wrong (support isn't responsive). But it's true that we're both safe from having a user/vendor relationship now.
You could make a car that's safer than others at 10x the price but what would the demand look like at that price?
Would you pay 2x for your favourite software and forego some of the more complex features to get a version with half the security issues?
Well.. except that I never want either of those. So sometimes I want Kate editor and sometimes I want Akelpad.
The answer to the above question will reveal if someone an engineer or a electrician/plumber/code monkey.
In virtually every other engineering discipline engineers have a very prominent seat at the table, and the opposite is only true in very corrupt situations.
Even basic theorems of science are incorrect.
It depends on exactly what you are doing but there are many languages which are efficient to develop in if less efficient to execute like Java and Javascript and Python which are better in many respects and other languages which are less efficient to develop in but more efficient to run like Rust. So at the very least it is a trilemma and not a dilemma.
One of these is not like the others...
Java (JVM) is extremely fast.
Hot take, but: Performance hasn’t been a major factor in choosing C or C++ for almost two decades now.
A while back when my son was playing Chess I wrote a chess engine in Python and then tried to make a better one in Java which could respect time control, it was not hard to make the main search routine work without allocating memory but I tried to do transposition tables with Java objects it made the engine slower, not faster. I could have implemented them with off-heap memory but around that time my son switched from Chess to guitar so I started thinks about audio processing instead.
The Rust vs Java comparison is also pointed. I was excited about Rust the same way I was excited about cyclone when it came out but seeing people struggle with async is painful for me to watch and makes it look like the whole idea doesn’t really work when you get away from what you can do with stack allocation. People think they can’t live with Java’s GC pauses.
Write code that carefully however is really not something you just do, it would require a massive improvement of skills overall. The majority of developers simply aren't skilled enough to write something anywhere near the quality of qmail.
Most software also doesn't need to be that good, but then we need to be more careful with deployments. The fact that someone just installs Wordpress (which itself is pretty good in terms of quality) and starts installing plugins from un-trusted developers indicates that many still doesn't have a security mindset. You really should review the code you deploy, but I understand why many don't.
Djb didn’t allow forking and repackaging so quail did not keep up with an increasingly hostile environment where it got so bad that when the love letter virus came out it was insufficient to add content filtering to qmail and I had to write scripts that blocked senders at the firewall. Security was no longer a 0 and 1 problem, it was certainly possible to patch up and extend qmail to survive in that environment but there was something to say for having it all in one nice package…. And once the deliverability crisis started, I gave up on running email servers entirely.
We built a weird solution where two systems would sync data via email. Upstream would do a dump from an Oracle database, pipe it to us via SMTP and a hook in qmail would pick up the email, get the attachment and update our systems. I remember getting a call one or two years after leaving the organisation, the new systems administrator wanted to know how their database was always kept up to date. It worked brilliantly, but they felt unsafe not knowing how. I really should have documented that part better.