Back when I used to write Ruby, lack of static analysis was a serious problem. I've been able to add Rubocop later, but it's not exactly on the same level as staticcheck, to say nothing about Prusti from the OP.
https://github.com/AdguardTeam/AdGuardDNS/blob/master/script...
https://github.com/AdguardTeam/AdGuardDNS/blob/master/script...
There's some mess in there, but if you only need a list of analysers and examples of usage, these should be enough.
Some of the possible problems are easy to confirm or deny just by looking at one line of code, but others will require much more analysis.
You need a tool/viewer to show the possible problem and what caused the possible problem. Such a tool improves the user experience dealing with static analyzer results.
- https://fbinfer.com/ (<- This one was a breakthrough in static analysis in its time)
- https://github.com/google/error-prone
- https://github.com/facebook/SPARTA
And many others
see tools section in https://learn.microsoft.com/en-us/previous-versions/tn-archi...
The other key static analyzer question is "how easy is it to run and does that happen early in the development cycle?". A static analysis pass built right into the compiler and generating warnings every time you compile has the most chance of having its reports paid attention to. Something that runs at CI time is more annoying. Something that runs only on trunk a week or more behind the leading edge of development and which just lists its reported issues on a webpage somewhere is in grave danger of being outright ignored, or only read by one or two enthusiasts who are forever fixing up other peoples' code...
On the other hand commercial tools have been more of a mixed blessing but that is probably because every time ive seen them deployed the budget hasnt included sufficient engineering time, training or prof services to cut down huge numbers of false positives.
valgrind is not a static analysis tool. But it is a great tool, especially memcheck.
I run mypy as a part of Emacs flycheck mode for Python.
Switching on a static analyzer is usually somehow painful, because old code does not typecheck, or has issues that static analysis discovers but which never get triggered in real life. You have to face constant (and rightful) nagging until you fix all key parts of your code so that the static analyzer no longer has concerns.
In his regard, Python is noticeably behind Typescript, because TS's type system and other amenities allow for more complete and precise descriptions of invariants that hold in the program, and which static analysis tools check.
I think it varies by industry though.
Usually it doesn't matter if devs themselves don't care, because when devops have the management support, they will care to fix that broken build.