I needed to make a distinction in the dedinition I gave. And I stand by it, even if the wording comes across as snarky. There are software engineering methods that are proven to work. They do not involve just diving in and changing the code. But I also think that there are valid reasons to not apply these rigid development practices to certain kinds of projects. For the rest, we might well get mandatory development standards forced on us to
I am well aware of the pressure on developers to get requested feature done quickly. But the vast majority of bugs that get shipped would be easily prevented by more thorough processes. All those projects writing highly reliable software demonstrate this. But the price tag has a few zeroes appended as a result.
There are software engineering methods that are proven to work.
Rust’s type system is arguably one of them.
I was talking about processes, not tools. Rust is just tool. But good software comes from thorough processes.
Good software comes from processes that aren't afraid to adopt tools to automatically enforce those processes in order to guard against human oversight.
Tools come from processes. You need to know what the tool needs to do (the process) before you can write it.
Type systems are applied mathematics. You can’t get more engineering-y than that.
See my reply to the other comment.
Type systems are tools that simply the process of checking that you do not mangle data by applying the wrong instructions to them. They didn't come out of nowhere.
As beneficial to your argument as it would be for that change to be the definition of "software", I don't think that's likely.