[pkolaczk]

Yes, of course I need to know. An important part of production grade software is observability. And that "something" doesn't have to be memory. It can be a connection, file handle, semaphore permit or one of many other things. But even for memory, typically there is not just one global type of memory. Users want to know how much memory is dedicated to X, Y and Z components, they might also want to constrain memory use by logical function. E.g separate buffer pools. This is where automatic memory management with GC falls apart very quickly - even the Java apps I work on actually use a memory/resource abstraction layer on top and manage everything manually, leaving just the last bit of releasing the objects to GC. Which is the worst of both worlds - we get all the disadvantages of MMM and all disadvantages of tracing (pauses, cache thrashing, etc).

[Jensson]

Java doesn't sound right for your use case. Most programs written in Java works just fine without tracking memory, and if you have any issues you do a jvm memory dump to see which object types are taking up all that memory and then look at why they weren't collected.

[pkolaczk]

Sure, I know that. But sometimes you don't have a choice because the decision was made years earlier by someone else, and you obviously won't rewrite a 1M LOC codebase.

Nevertheless, after spending a year writing Rust, I'd take Rust over Java for just any use case now, even including CRUDs and GUIs (actually doing a GTK GUI for a Rust app right now, and it is not any worse in terms of dev speed than Java Swing was, despite what people say about callbacks - I really don't mind an occasional Rc/Refcell/clone here and there).