> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language

You're describing Swift

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

What are you both talking about? Swift doesn't have garbage collector the same way Rust doesn't have it.

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.

See also "A Unified Theory of Garbage Collection", https://researcher.watson.ibm.com/researcher/files/us-bacon/...

> 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.

Chapter 5 of the GC Handbook, one of the major CS references in GC algorithms.

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.

You're conflating tracing GC algorithm with GC as CS concept.

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.

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).

Swift does not employ garbage collection, but reference counting.

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.

Swift doesn't have tracing gc but ref counting is a form of gc

Also Haskell, D, Chapel, among others.

> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language.

sooo... ocaml?

Or many other programming languages, but yes, OCaml is a pretty good one, and it is perfectly suitable for systems programming.

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.