Hacker News Reader

Comment by bloat | Hacker News Reader

You don't see any benefits to garbage collection at all? Would you even prefer to do your own memory management if you had a magic GC which never paused? I'd be interested in your reasoning if so.

View on HN

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?

Ever heard of RAII?

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

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

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

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.

Reply on news.ycombinator.com