Maybe we should be using ATS. Or more likely, maybe we should be using some novel language that doesn't exist yet that brings the benefits of ATS to a language with good tooling and good DX that you can use to build practical system software with - that is, a Rust for ATS instead of C/C++. I think we should be designing programming languages that help eliminate as many classes of bug as possible, and Rust is not the culmination of the line here.
One of the lessons of the past 50 years in software correctness is that sound guarantees are not always the most effective path to correctness. The problem is that proving something correct takes a lot of effort (and there are fundamental computational complexity reasons for that), while unsound methods are significantly cheaper and surprisingly effective in practice. A famous 1996 paper by Tony Hoare [1] expresses amazement at how software had become so reliable without proofs, something that in the 1970s was thought impossible. Since then, the field has moved to enthusiastically adopt more unsound methods.
And remember that a software system, unlike an abstract algorithm, is a physical system that cannot be proven correct, since the behaviour of the physical hardware cannot be proven. We're always dealing in probabilities, and so the question is: how do we get the most value (in terms of reducing the probability of costly bugs) for a unit of effort.
Since the 1970s, the size of software that can be proven correct in practice using deductive methods has only fallen compared to the average size of a program (i.e. the size of acceptably-reliable software we write has grown much more rapidly than the size of software we can prove correct using deductive methods). The largest programs ever proven correct using deductive methods are on the order of 10KLOC.
So the field of software correctness has long ago abandoned the position (held by some in the 70s) that proof is always the most effective way toward correctness.
Bit of a tangent, but what is your perspective on formal verification in hard realtime systems? Is the cost justified because the system tends to be simpler and doesn't need to evolve through time, or some other reason? Or do you see formal verification with hard realtime systems as unnecessary effort?
I think formal verification can and should be used everywhere it is helpful, which certainly includes hard realtime systems but isn't limited to them (it's helpful in quite a few areas). But formal verification is by no means the same as deductive theorem proving. Especially for hard realtime systems, which tend to be simple as you say, model-checking has been the formal method of choice for decades.
Even for large, non-critical software, there are useful formal verification methods that aren't end-to-end, i.e. they can cover the design but not the code, and have proven very useful in finding bugs. I for one, am a big fan of TLA+. TLA+ has both an interactive theorem prover and a model checker (or a couple). Most importantly, it allows describing the system at an arbitrary level of detail, which means you can use it at different levels as appropriate. For some things, it can and should, say, describe hardware in full detail; for others, it can be used to describe and verify a very abstract algorithm, well above the code level.
The problem with deductive theorem proving is that it tends to have a low ROI, and there are often more effective methods. It should be used when other methods don't work well.
