If you actually use static analysis, you can't forget it in Java either.
And it isn't as if using languages without static analysis is still considered a best practice in the 21st century.
And it isn't as if using languages without static analysis is still considered a best practice in the 21st century.
So in summary, "Please just do better". Not helpful as a video game meme, and really no better for programming.
An example of a clippy lint that I like in clippy:
If you try to transmute() &[u8] into a &str clippy will point out that you should probably from_utf8_unchecked() -- this lint results in code that does the same thing but is clearer for maintainers about what we intended. If our reaction to the lint is "But it isn't UTF-8" then we just got an important red flag, but that's not why the lint is there.
On the other hand, clippy lints for truncating casts and I want those gone from the language so the warnings ought to at least live in the compiler not clippy. I would like to see a future Edition outlaw these casts entirely so that you need to write a truncating cast explicitly if that's what you needed.
FYI: As I understand, escape analysis is frequently used to either (a) avoid allocating on the heap, or (b) auto-magically free-ing a malloc'd object from a tight scope.
https://en.m.wikipedia.org/wiki/List_of_Java_virtual_machine...
As it stands is mostly done at runtime and only for a).
Otherwise you are better with try-resources, and for something like malloced memory there are off-GC heap APIs.
Also Valhalla will eventually land, although it is getting long by now.