> By far, most code doesn't allocate or free (and that's a good thing).

Depends on the code you write. If, like in C++, non-stack memory management is painful, programmers tend to react like you suggest.

In pure-by-default languages, you are creating new and destroying old objects all the time. (At least conceptually. A sufficiently smart compiler can eliminate most of that.)

Obviously depends on the use case, but since C++11 there is little to no pain involved in manual non-stack memory management. You clearly express the ownership semantics through things like std::unique_ptr and std::shared_ptr and if those make sense then everything works (minus problems like circular shared_ptr references, which exists in similar forms with GCs).

> (minus problems like circular shared_ptr references, which exists in similar forms with GCs)

Most GC can deal with circular references just fine?

Yeah, I didn't elaborate this enough (because it wasn't really the main point). When I said "similar" I meant "things holding onto things they should no longer be holding onto", not circular referencing in particular.

I realize that the kind of bug that leads to effective memory leaks with GCs has its own equivalent in manual memory management, but my overall point was that neither manual memory management nor GCs make you immune to leaks from badly designed or incorrectly implemented data structures. Each takes some aspect(s) of pain away.

On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.

Of course there will always be some issues somewhere. But, ignoring perfect memory safety, the issues are widely overblown, to the extent that I find manually managing memory a lot easier than dealing with GC once a project grows beyond a couple KLOC.

It's all about proper planning and code organization. Use pooling, central manager structures, etc. If it can be avoided, then do not allocate and free stuff in a single function like you would carelessly do with automated GC. Structure the data such that you don't have to release stuff individually - put it in containers (such as vectors or maps), such that you can release everything at once at certain points in time, or such that you can quickly figure out what can be released at central code locations (that's much like automated GC, but it's staying in control and retaining room for optimization).

I don't think "multiple distributed teams" makes the challenge any harder. You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team.

> You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team.

That doesn't work in enterprise projects with heavy dosis of consulting.

Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++.

For me the big attraction of GC is memory safety not convenience.

Try Rust. Proven memory safety, no GC.

Until one tries to do GUI programming, then it is Rc<RefCell<>> everywhere, or arrays with vector clocks for managing old entries.

no opportunity at $CURRENT_JOB, but in the future, sure, it is definitely on my radar!