GC's strength is not only in the ease of writing but at also reading, since you don't need to interleave allocation and business logic everywhere (be it through types or imperative code).

GC simply is the only way to approach the clarity of pseudo-code in real code. That's one of my later realizations concerning the subject (https://world-playground-deceit.net/blog/2024/11/how-i-learn...)

▲

adrian_b 2 hours ago | parent [-]

You mean "interleave deallocation and business logic everywhere".

For allocation there is no difference between automatic memory management with garbage collectors or reference counts and manual memory management, where the programmer is responsible for invoking "free".

These alternative memory management methods differ only in how deallocation is handled.

Allocation must always be done by defining a new object, regardless of how memory is managed. Moreover, allocation also does not depend on whether an object is allocated in static storage, in a stack or in a heap. You always must define the object, so that memory should be allocated for it at compile-time if in static storage, or at run-time if in a stack or in a heap.

	▲	a-french-anon an hour ago \| parent [-]
		Well, it's true that most of the noise comes from deallocation but I did mention types for good reasons: having your code littered with std::shared_ptr (or worse for Rust where encoding lifetime goes much further than Rc/Arc) is a direct consequence of wanting GC without a global one. The source of my second revelation: GC should be opt-out (e.g. SBCL's arena system) instead of opt-in via refcounted types.