Memory isn't the only limited resource which needs to be managed. File handles, network ports, etc. all all need proper design to avoid leaks. If you are used to only the allocation and never the cleanup, your design style won't hand effective management of these other types of resources for which GC isn't an option.

I'd use Java if it let me annotate when I want things to be deleted.

I'm perfectly happy to have all you lot depending on GC.

And, I don't "do my own memory management". I just don't rely on a GC to do it.

It may be constructive to say what you do do, instead of leaving us to guess and telling us we're wrong.

I mostly use "}".

You write programs so short and uncomplex that you rarely need to free memory?

I interpret it as meaning they don't use dynamic memory allocation.

False. Use of dynamic memory allocation without GC, without reference-counting (which is GC) and without manual memory management is the usual practice in C++ and Rust.

Reference-counting GC is available when it is not too costly, which is common, and more convenient, which is rare. Ordinary automatically-generated destructors handle almost everything, almost all the time. Once in a great while, performance demands a concession such as an arena allocator, which also is not "manual memory management", and also not GC, and is radically cheaper than either one.

Ever heard of RAII?

That's still memory management, because you need to worry about lifetimes.

It is automated, not manual, memory management. Just not GC.

You only need to worry that data that you need doesn't go out of scope.