[neonscribe]

Obviously this is a joke, but the real message should be: if you can't manage your own memory, you should be using a language implementation with automatic memory management. If your code really needs to run "close to the metal", you really need to figure out how to manage your memory. In 2024, language implementations without automatic memory management should be reserved for applications that absolutely need them.

[zokier]

Funny, I think the lesson is the opposite: just because you have mechanisms that technically prevent memory leaks doesn't mean that you don't need to think about memory and its allocation/freeing. Or rather, memory leaks generally are not problem, unbounded memory consumption is, regardless if the consumption is technically due leak or some reference stashed somewhere.

[Zababa]

> if you can't manage your own memory, you should be using a language implementation with automatic memory management.

I agree, and would expand the idea to all kinds of resources (files for example). Sadly not many languages have "automatic resource management". For example Go has automatic memory management, but if you read an HTTP request's body you have to remember to call req.Body.Close(). If you open a file you have to call file.Close(). If you launch a goroutine, you have to think about when it's going to end.

I'd like to know if some languages manage to automatically managed resources, and how they do it.

[kwhitefoot]

C# has Using. When the block ends the destructor is called.

VB Classic has reference counting and the terminate event is fired when the count goes to zero. So as long as you don't store the reference in a global the terminate event is guaranteed to run when it goes out of scope (so long as you don't have circular references of course).

C++ has Resource acquisition is initialization (RAII)

[_a_a_a_]

It obviously is a joke, but at the same time it's actually a viable approach for the right problem. Sometimes leaking is very tolerable and in terms of programmer time, very cheap!

[Dylan16807]

> It obviously is a joke, but at the same time it's actually a viable approach for the right problem.

Define "it" here.

Because "just don't free" is pretty different from what's in the post!

[_a_a_a_]

Yes. Hence the word 'joke' I used. For short running programs, it's fine. The longer running programs you can often find a few places where 95% of the leaks happen and easily 'free' those leaving the last 5% to leak slowly. It depends. Just remember it's a valid solution sometimes.

[Dylan16807]

I still don't understand.

The joke and the sometimes valid solution are different strategies.

The joke only reminds people of the valid solution. It feels like multiple people are giving the article the briefest skim and assuming the two are the same. Perhaps focusing on the words "optional to call free" and extrapolating off that without looking at the code or properly reading the rest of the text.

Unless I'm badly missing something?

[_a_a_a_]

I think you're just looking more deeply at it than I am. No more than that.

[Voultapher]

I think the mold linker does this.