What I find sad is that Java garbage collection isn&#x27;t <i>better</i> than manual memory management, given the vast investment in the jvm. There are plenty of ways in which garbage collection <i>can</i> be faster, but production software is still in the stone ages when compared to research from 10 years ago.<p>For example, any scenario where Rust doesn&#x27;t even need a lifetime annotation is a scenario where a garbage collecting language compiler still could manually manage collection at almost zero cost. It could, very simply I might add, make inferences of the most efficient way to collect block scoped objects...the vast majority of which end up getting collected in the short lifetime pool. Long lifetime objects might be more efficiently reference counted, so why can&#x27;t the compiler decide that singletons should be reference counted, <i>or even statically allocated</i> instead of pinged during every large collection? And why can&#x27;t we have an actual disposable interface that actually performs a manual collection?<p>For a language that is as memory heavy as Java is, with as much boxing that it does, and the high performance demands of its user base, it blows my mind that their best idea for improvement in garbage collection in the last decade was to naively go after more concurrency. I realize that is what <i>everybody</i> thought the future was for everything, but something something Amadahl&#x27;s law. There are so many better opportunities that involve allocating less, destroying without a mark stage, etc.