[staticassertion]

> Thing is many of Rust features could probably be enforced with a static analysis tool, which a large majority unfortunately ignores.

But it definitely can't be? There are plenty of open source projects (Chromium, Firefox) that develop and leverage state of the art static analysis tools and best practices. It's very clearly not enough, and the costs (built/ test time) are really significant.

[pjmlp]

Our day to day software development practices still fail short of what design by contract, MISRA, AUTOSAR, DO-178B and similar offer in terms of delivered quality.

Only with further increase in lawsuits and returned faulty software, like in other commercial areas, will companies start paying attention to QA budgets.

[AlexanderDhoore]

MISRA and DO-178B deliver more on the illusion of quality then anything else. They are desperate attempts to tame software complexity. But they don't fundamentally solve anything.

[pjmlp]

How come? They aren't perfect, but they seem to at least make Ada/Pascal out of C.

[Matthias247]

I would agree with the parent. It's a while since I did my last MISRA project, but I know that it doesn't even prevent basic memory safety issues or leaks. It's more a set of coding guidelines that prevent some kinds of errors than robust tool that will reliably detect those.

Static analyzers work better, but often have a terrible signal-to-noise ratio. I think Rust can on average prevent more errors than all of those things out of the box, which is impressive.

The downside is obviously the increased complexity, and that it sometimes feels one is forced to work around the limitations of the "static analysis tool". Which likely comes from the fact that the borrow checker is some kind of analysis tool, where the annotations are directly included into the language.

[pjmlp]

Thanks, my experience is just on reading papers about it, so it is nice to have feedback from actual uses of it.

Regarding with Rust having a kind of analysis tool directly built into the language, fully agree, that is what is so nice about safer systems languages, and what I liked in Algol/Wirth languages.

[vinay_ys]

Please elaborate with examples.

Since most new cars are Internet connected and have whole hosts of complex safety features dependent on software correctness, I sure do hope you are wrong about this.

[roca]

MISRA and similar standards are incredibly limiting. For example MISRA forbids dynamic allocation.

They not only make writing software a lot more difficult and expensive, they also restrict the kind of software you can write.

[carlmr]

Do you think QA budgets would actually help here? At least the way I know it QA and development is separated, and no matter how many QA people you hire, many developers brush off QA until later.

Considering Rust shows can enforce so many things in the compiler, to me it's clear that a better compiler/language is a better way to address this problem than QA people.

Also the built in testing with cargo test makes TDD so much more attractive.

[pron]

They don't, but others do. Sound static analysis tools like TrustInSoft (https://trust-in-soft.com/) guarantee no undefined behavior (array overflow, use-after-free etc.).

[roca]

That's basically a reduced form of program verification, and requires a lot of developer help. You end up programming in a language that looks like C but isn't. It is not simply a matter of throwing a pile of C++ code at the tool and fixing a few errors it reports.

[pron]

That depends what you mean by "a lot". The effort required is significantly less than a rewrite in a safe language. If we're talking about properties that safe languages can verify, i.e. simple, local, ones (like memory safety), verifying those in a sound static analysis tool is not hard, either.