> 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.

I guess that is why no one bothers with clippy then, it is superfluous.

Everywhere that a clippy lint is there to catch bugs, I wish it wasn't a clippy lint because it won't always get run and those bugs will get missed.

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.

Is Java escape analysis done at compile time or run time? I don't know.

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.

First of all it depends on the implementation, the language specification doesn't state how it works.

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.

Personally I wish they would move some escape analysis to compile time just to help with memory consumption. I’m assuming it would require byte code changes though.