The thing is software is made to compete for new monopolies rather than to perform functions reliably. There's so much funding for monopoly-rent-seeking that this dominates and characterizes the field. Correctness just isn't that important for that.

Over time, perhaps the available monopolies will dry up, a few megafirms will buy up everything that can collect rents, and the only software left to write will be practical.

>If say liabilities for bugs in critical software shift or if natsec regulations require software that touch infra like: water, power, telecom, and mass transit to be verified like avionics software is. IMO both are likely 2-3 decades out.

This can be mitigated by designing robust systems that are robust to flaws of its components. There is an understanding that bugs or corruption way happen and the system should able to tollerate it and fix itself or alert people that something is wrong or needs to be addressed.

It doesn't seem plausible to me that an organization that refuses to create reliable components will create reliable systems out of the components.

It's cheaper to be able to handle your program crashing every once and a while than to try and earliest 100% of all crashes from your program. It's possible to deal with situation where you know you are never going to be 100% bug free.

I have yet to see something like that remaining robust to unauthorized memory access.