[pjmlp]

That is a misconception, RAII like code can be achieved in two ways:

- defer (possibly add a go vet check for when missing it)

- when Go 1.18 brings generics, the withFunc pattern from FP where lambdas get given a resource released on function exist, thus having regions/arena like resource management

[tialaramex]

The description for go vet says, "it should be used as guidance only". Go vet is in fact a linter (go lint is also a linter, but one focused on style).

So what you're doing there is adding a control to try to mitigate the consequences of a language failing. Go doesn't actually prevent you from getting this wrong, but a linter such as go vet can flag cases where it suspects you screwed up, and maybe you'll catch the worst mistakes most of the time this way and by having usage conventions.

We shouldn't mistake this for equivalent capability. The complicated cases that tempt people to ignore or switch off such linting are exactly the cases most likely to have an undetected problem.

So this is "RAII like" only in the sense that "Just remember to do it properly" is RAII like, and we could make exactly the same claim for C.

[pjmlp]

Just like you need to use clang tidy to fix all the issues with writing proper C++ code.

[tialaramex]

Fair. However, there continues to be an unresolved tension in the C++ community about whether they want C++ to focus on its considerable legacy by ensuring enduring compatibility ("No ABI breaks, ever!") or to continue growing and changing even if that means not everybody can follow ("Performance trumps compatibility, ship it!"). Although we can anticipate some sort of compromise, it just isn't possible to have a C++ 2x that delivers everything the modernizers want yet still runs people's technically conforming C++ 11 code unchanged with that binary DLL they've got no source code for. Some people will be unhappy, maybe everybody in the C++ community will end up unhappy.

In the "no breaking changes" case I agree that C++ objects that live in the free store are in the same place as Go, the programmer has a responsible which they may not fulfil, to manage this resource and a linter can only help mitigate this problem.

But plenty of people including Stroustrup want to do lifetime management, despite potential breaking changes from that, and under lifetime management the compiler has visibility into your object lifetimes and can reject programs which inadvertently leak.

Now, that doesn't (can't) make leaks impossible, but it means any leak is now in some sense "on purpose" and would happen for GC'd resources too, it isn't just an accident. For example Rust's mem::forget will prevent the drop happening for the object you're forgetting, but it's not as though you type mem::forget() by mistake. You clearly wanted to achieve that (e.g. you stole the underlying Unix file descriptor from a File and sent it over a socket to a separate process, so now cleaning up that descriptor is the Wrong Thing™) and incorrect usage is not the same category of error as forgetting a with clause in Python.

[deathanatos]

defer (/using/with) all require the programmer to remember, and write, O(use site) times, the code to release the resource.

RAII destructors, on the other hand, do not permit the coder (at the use site of the type) to forget, as the destructor is invoked automatically when the variable goes out of scope.

In my time reviewing Python (also GC, "with" provides a similar functionality), this is a very common error.

[pjmlp]

Apparently you missed my go vet reference on purpose, just make all of us aware of it not being the same.

Same applies to using on .NET, where forgetting to call using on an IDisposable type can trigger a compiler error, via Roslyn plugins.

Also seem to be unaware how closure based RAII works on FP languages.

RAII isn't triggered on heap allocated objects unless smart pointers are used everywhere.

Python doesn't have a static analysis tool for with, nor does it support value types with stack allocation. Not all GC languages were born equal.

[nemetroid]

> RAII isn't triggered on heap allocated objects unless smart pointers are used everywhere.

It's triggered unless you have memory leaks.

[pjmlp]

So it isn't.

[nemetroid]

Correct, but except in very special cases, memory leaks are themselves considered bugs. Using memory leaks as an example of RAII not always working is, in my mind, similar to saying Rust doesn't prevent memory errors since it has the "unsafe" keyword.

[pjmlp]

Except when using system code you might have to pack pointers in OS IPC structures which don't map into smart pointers.

Similar to forgetting memory in Rust, and then there is no miracle RAII.