What I don't agree with is the idea of taking Rust's ideas and putting them into manually-memory-managed, unsafe languages. We should be moving away from such languages as an industry.
You're describing Swift
But in practice I think modern swift uses inheritance very sparingly, and leans much harder on the protocol/extensions system, which is very well design imo
But that only goes for reference types. For value types you're correct that both languages use mostly static memory management.
I guess in that sense you'd have to consider Rust as a gc'd language as well: the only difference really is that you have more fine-grained control over which mode of reference counting is being used for a given object.
> We present a formulation of the two algorithms that shows that they are in fact duals of each other. .... Using this framework, we show that all high-performance collectors (for example, deferred reference counting and generational collection) are in fact hybrids of tracing and reference counting.
...
> For every operation performed by the tracing collector, there is a corresponding "anti-operation" performed by the reference counting collector.
...
> We have shown that tracing and reference counting garbage collection, which were previously thought to be very different, in fact share the exact same structure and can be viewed as duals of each other.
Regarding C++ smart pointers, if you manually call them like in std::shared_ptr<>(), no.
If the runtime calls it for you like on C++/CX or compiler blessed types like _com_ptr_t, then surely.
Reference counting is a GC algorithm, regardless how people sell it to the man on the street.
Additionally there is a whole set of politics how ARC had to be sold after the technical failure to make Objective-C GC implementation work without core dumps, due to the underlying C semantics.
Plus making retain/release calls automatic wasn't anything new as idea, VB and Delphi did it first with COM AddRef/Release.
sooo... ocaml?
However until certain C++ overloads don't give more love to memory-safe, garbage collected language or languages like Rust, that is better than nothing.
For example, I don't expect Windows team to ever lose their love for C++, NVidia moving from their C++ love for CUDA, or Metal shaders in something else.
Ah, and then many of those languages are keeping C++ around by building on top of GCC or LLVM.
So any improvement towards to make C and C++ safer is better than just using them as they are.
Edit:
> the constraints of the borrow checker make things like tree structures at least an order of magnitude harder to get right
The constraints of the borrow checker make those things more unlikely to compile without extra ceremony. The likelihood of getting them right is orthogonal from making the compiler "happy", even in Rust but specially in other languages. The way I've heard it described is that Rust is a language where you get the hangover first. It upfronts dealing with the error conditions of your problem space in a way that (you can argue) hinders the exploration phase, but that makes of a very quiet maintenance phase.
Pretty sure modern state of the art GCs, like the ones found in Java or .NET runtimes, are way more efficient than reference counting.
Reference counters have that unfortunate RAM access pattern where the counter is frequently updated from multiple threads concurrently. On modern processors, this means concurrent access to a cache line by different CPU cores. These cache coherency protocols are pretty slow. On many CPUs, reading a cache line recently modified by another core costs 300-500 clock cycles, even more expensive than a cache miss and roundtrip to system RAM.
As an example, here is a video of David Pedersen creating a simple Tower service: https://www.youtube.com/watch?v=16sU1q8OeeI&t=945s
I found it intimidating how much you have to write to create a simple middleware.
Compared to C, and sometimes C++, there's generally less boilerplate in Rust. Compared to more traditional web languages, though, Rust will seem to have more boilerplate due to it's lower-level design.