> Your comment boils down to 'all code should be perfect'.
This is clearly false from a cursory skim of the parent comment, which says
> All processes should be prepared for a sudden crash without corrupting state.
...which is leagues away from "all code should be perfect" - for instance, an obvious example is programs that can crash at any time without state corruption, but contain logic bugs that result in invalid data being (correctly) written to disk, independent of crashing or being killed.
The convo has been a bit light on examples - I think a canonical example of how to achieve this can be found in ACID databases and high uptime mainframes. Definitely doable, but if performance and large scale data is also a concern, doing it from scratch (eg. starting with file handles) is probably a 5-10+ year process to write your own stable db.
This is clearly false from a cursory skim of the parent comment, which says
> All processes should be prepared for a sudden crash without corrupting state.
...which is leagues away from "all code should be perfect" - for instance, an obvious example is programs that can crash at any time without state corruption, but contain logic bugs that result in invalid data being (correctly) written to disk, independent of crashing or being killed.