I'm not sure of Go's support for RAII... the key feature is the "composability" of the RAII technique.
In C++, I can embedded a "socket" class as a member of some other object - on the stack or the heap - and it automatically and implicitly gets cleaned up correctly and deterministically, whether or not an exception is thrown, without me having to write any extra boilerplate.... so long as I follow the "rules" (and this is one of the places where C++ could be improved on).
"try/finally" or some sort of "stack-only" annotation doesn't really cut it for creating new resourceful objects out of existing ones.
For example, C# has the "using" syntax and also supports try/finally - these let you write code that works with anything that implements "IDisposable".
It handles the trivial cases - but as soon as you start wanting to compose together IDisposable instances you end up having to write lots of your own boilerplate to deal with propagating the "dispose" methods and ensuring that everything works correctly if an exception is thrown.
Of course, writing and testing all of the edge cases is very tedious and often difficult because you are dealing with resources like sockets and database connections after all - so even "mocking" them becomes hard.
Because its so difficult, most people just end up writing C# code that leaks resources (but not memory).
the key feature is the "composability" of the RAII technique.
I think it might be possible to have composability in RAII in Go if such objects weren't allowed to live anywhere but the stack. (Which would limit passing through channels.) Those objects would have a well defined creation and destruction time. While not completely universal, this might still be quite powerful and useful.
It would. (In fact, you might be able to do this today with runtime.SetFinalizer.)
You do have to be careful to avoid bringing back the objects that your finalizer references from the grave. If you do that in Go and create cycles, it leaks (which isn't unique to Go, many other languages do this). You need a sophisticated GC (like Java's) or a type system that's aware of the heap/stack distinction of objects (like Rust's) to mitigate that.
In C++, I can embedded a "socket" class as a member of some other object - on the stack or the heap - and it automatically and implicitly gets cleaned up correctly and deterministically, whether or not an exception is thrown, without me having to write any extra boilerplate.... so long as I follow the "rules" (and this is one of the places where C++ could be improved on).
"try/finally" or some sort of "stack-only" annotation doesn't really cut it for creating new resourceful objects out of existing ones.
For example, C# has the "using" syntax and also supports try/finally - these let you write code that works with anything that implements "IDisposable".
It handles the trivial cases - but as soon as you start wanting to compose together IDisposable instances you end up having to write lots of your own boilerplate to deal with propagating the "dispose" methods and ensuring that everything works correctly if an exception is thrown.
Of course, writing and testing all of the edge cases is very tedious and often difficult because you are dealing with resources like sockets and database connections after all - so even "mocking" them becomes hard.
Because its so difficult, most people just end up writing C# code that leaks resources (but not memory).