I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. I like garbage collection—it's not always the right tool, but it's a great tool in the proper domains. Modern GC builds upon decades of research to achieve memory safety at runtime with good performance and very low cognitive overhead on the part of the programmer.
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.
Swift also has some stuff coming from the history of Objective-C interop (inheritance is the big one I'm thinking of, although I'm sure there are others that are slipping my mind). I'm not sure how mainstream this opinion is, but personally I _prefer_ not having classes and inheritance, and while I could always choose not to use them in my own code, I imagine it's common enough in libraries that I'd end up dealing with it a bit anyways. Combined with the fact that Linux support still seems like it's a bit secondary makes me feel like there still is a potential niche out there for "Rust with garbage collecting" that Swift might not be filling entirely.
Yeah I agree, I think one of the biggest mistakes in Swift was coupling reference types to classes. Choosing whether something is a reference type of value type should have been orthogonal to the class system, if they included classes at all.
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
Swift doesn't have tracing GC, but to be pedantic automatic reference counting is a form of GC.
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.
GC is standalone runtime that does tracing and deallocates memory at some arbitrary time. Are you really claiming that using C++'s smart pointers is using GC? I think you're conflating semi/automatic memory management with GC.
ARC in Swift doesn't have runtime part, retain/release code is injected at the compile time. It doesn't have ie. cycle detector running periodically or anything like that. If you define this setup as GC then by this definition Rust's borrow-checker is also a GC because it works the same way - by injecting static code during compilation (but has different rules).
Chapter 5 of the GC Handbook, one of the major CS references in GC algorithms.
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.
I can attest that so far the lifetime static analysers for C++ haven't progressed that much.
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.
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.