Are you asking what kinds of errors RAII-style C++ programs make that you can't make in Golang (an easy question), or what kinds of errors you can make in Rust that you can't make in Golang (harder)?
I'm just questioning the assumption that RAII as a concept must be memory unsafe, specific language aside.
Edit: To be clear it's the latter question, but more general. C++'s implementation has many opportunities for errors, but I do not think the technique is inherently unsafe. (PL research has proven many similar systems based on unique types and borrowing to be type- and memory-safe.)
A safe RAII system based on unique types is precisely, by definition less powerful than GC, because it allows no operations that GC doesn't allow but forbids some operations that GC allows (namely aliasing).
If you're talking about C++'s unsafe implementation of RAII, that's true of course.
C++ is in fact where my experience with RAII comes from. Could you, for example, forget to make a destructor virtual in "safe" implementations of RAII?
Perhaps the real answer to "Why isn't RAII more popular?" is that C++ has poisoned the well for many programmers.
> C++ is in fact where my experience with RAII comes from. Could you, for example, forget to make a destructor virtual in "safe" implementations of RAII?
No, that would be unsound.
> Perhaps the real answer to "Why isn't RAII more popular?" is that C++ has poisoned the well for many programmers.
Totally agreed. (But that said, I think that Go, and most other languages, made the right decision when going with pervasive GC. It makes the language much simpler, both in terms of implementation and interface. It costs some performance, of course, but being as fast as C in all cases was never a design goal of Go, according to the FAQ. The complexity, both in interface and implementation, that languages buy into if they want safe manual RAII-style memory management is not trivial.)
