Is Rust's borrow system also a form of garbage collection?
To be sure, the proper Rust analog of Swift classes is Rc/Arc, not drop flags.
> Swift can never eliminate the runtime overhead of garbage collection. That's because, at a language level, Rust has static lifetime semantics and Swift has dynamic semantics.
Would you agree that Rust can never eliminate the runtime overhead of dynamic dispatch, because trait objects, at a language level, require dynamic dispatch? I would not agree: Rust programmers routinely eliminate it by sticking to the statically-dispatched areas of the language. Likewise, Swift programmers routinely avoid the runtime overhead of reference counting by using structs and not classes.
Sharing is something that is pretty necessary in programming; you are severely limited in what you can do without sharing. Trait objects are not, and are pretty rare in Rust. I often see people using enums over trait objects, and only sticking to trait objects for creating extensible APIs.
Rust provides a way of sharing that does not involve any extra runtime overhead, which gets used often. Swift does have nice optimizations to value-typeify things, but without a finer-grained distinction between the kind of sharing you want to do to hint the compiler, this will be vastly limited as compared to Rust giving an explicit choice between borrows and Rc.
If you are referring to borrowing, Swift's answer is not class types, but inout. inout is not as flexible as Rust references, but it does not use reference counting. In most places where a Rust function would return a mutable reference, the analogous Swift function would take a closure that accepts that something as an inout.
I am aware of inout, but like you said it's not as flexible. I find myself reaching for class types in Swift a lot more than in Rust.
inout works for sharing that is extremely local, but more complicated sharing in larger codebases is hard.
It would be sillier to define automatic memory management in terms of conditional releases, (as you seem to have done) and then insist that Rust's conditional releases don't really count. Clearly, it is not really the fact that the releases are conditional that makes the difference.
What is your actual definition of automatic memory management? What, in your view, is the actual semantic difference between a language that has automatic memory management and one that does not?
I can't answer for Patrick, but I don't see the term "automatic memory management" as useful as distinction, I look at it more as a spectrum, and Rust/C++ fall squarely on the "more manual" end of that.
I agree 100%. My objection was to the assertion that Rust and Swift were completely different because Swift was garbage collected and Rust was not. That's just not a helpful way of looking at it, because in many ways Swift's strategy is closer to Rust's then Java's.
type system wise they are pretty comparable otherwise; As a Rustacean who is used to nice type systems, Swift's type system is a pleasure to work with.
But characterizing that as Swift = GC, Rust = No GC, as I was originally objecting to is a pretty terrible way of describing it.
> they still result in code being inserted to do things like deallocate objects at run time.
(and millstone has been making good points about drop flags on this thread, but that's still only in fairly niche cases, only one bit, and is an implementation detail more than a fundamental aspect of the language. We've had several different variants of drop flags over time, and it's going to change even more in the future, as erickt says.)
> Swift and Rust are far more similiar...
Ok, but isn't the question of whether or not something is done at compile or runtime always an implementation detail? The fact that Rust figures out at compile time whether or not to insert the deallocation functions is super awesome, but it doesn't actually change the semantics of the language relative to if has to check flags or reference counts etc.
This is different, to my mind, from static/dynamic typing because they have very different semantics. Early versions of Java used a VM which was dynamically typed, and PyPy converts python code to machine code that doesn't check types (if I'm lucky). So the distinction really isn't whether or not the decision is made at runtime.
But really, I only objected in this thread because the claim was made that Swing and Rust were very different because Swing had GC and Rust didn't which seemed to be overemphasizing the differences here.
There is no concept in Swift of a dead object that is in scope. There is in Rust, which is why you see "use of moved value" errors. That is a language difference.
No it isn't. It changes the entire semantics of your language. For example Python as it exists today simply can have neither type checking nor GC decisions* done at compile time. The language is not capable of expressing those things adequately. Adding those would require some significant changes to Python the language, its stdlibs, as well as the Python VM.
Conversely, starting to use reference counting in Rust is definitely possible but will jack up your memory-related bug count, a rather undesirable result. The code is also pretty much always more difficult to read, understand and debug. Its only redeeming feature is that some datastructures simply need the flexibility it brings.
* I define a GC decision as deciding what to de/allocate and when to do it, rather than performing the de/allocations themselves. For example, the GC algorithms in Java and Go fall under this definition, as does Swift's ARC mechanism, as well as Rust's ownership based decisions. The former 3 decide at Runtime. Rust usually decides at compile time, the only exceptions I can currently think of being code based on the Rc/Arc/RefCell types, which do reference counting and therefore the de/allocation decisions are deferred until runtime.
We're not talking about whether the user manually calls free. Even C has automatic memory management (via stack/activation records) by that definition! The difference is whether the memory management is worked out statically, at compile time, or runtime, via tracing and/or reference counting.
C does manage some memory automatically. But it leaves a lot of memory management up to the user, such that any non-trivial C program will manually manage memory. That's different from Rust, Go, Java, or D in that most programs in those languages will not need to do that.
The distinction is in the programmer model involved. With Swift and GCd languages, you do not know about when the deallocations will happen, because this requires analysis of the whole program and the executions. You program with this in mind. Since GC/ARC is the only way to share, you end up using it often. The compiler can prevent some of this, but not the majority, because there isn't enough annotation helping it.
(There is this difference between Go and Java, too. Go is more explicit about sharing than Java, and needs annotations when you share things (* and &). Java does not. So while Java 8 is getting escape analysis, it can never be as good as what Go does or potentially can do because the compiler just doesn't know enough. Go also generally avoids sharing unless necessary, whereas in Java you will see things shared willy-nilly because the distinction only lies in the optimizer. These annotations aren't as fine grained as Rust -- they're at the same level as Swift, approximately, but I'm trying to give an example of the same annotation-drives-optimization-and-design thing at a different level.)
With Rust and C++, you know just by looking at a function what will be deallocated and where. C++ has API designers implement drop flags anyway (in the form of nulling the internal pointer, or something) for all types with a move constructor. The model of dealing with data changes; you explicitly think about where data comes from and how to share it. The additional annotation of zero-cost borrows (instead of just saying "Share this ... somehow", which is what Go and Swift do) means that zero-cost borrows will always be zero-cost, and not only if the optimizer decides it knows enough to be able to help.
Note that ARC is much much costlier than than pointer-sharing. Not directly because of the increments; but because dynamically allocating for every instance of sharing, and then accessing that allocation whenever you wish to do a read/write or bump the reference count; is horrible for cache performance. This can be assuaged with a tuned allocator, but is less efficient than the usually-to-the-stack borrowed references of Rust.
I will point out that Swift satisfies the academic definition of garbage collection and Rust/C++ do not, but I don't think terminology is as important as understanding what's actually going on.
Rust is "automatic", in a sense, agreed, but automatic memory management is a vague term that can mean anything.
What is this academic definition of garbage collection? I'm familiar with how the different models work. But I'm having trouble with a definition of garbage collection that excludes Rust while containing Swift.
Note that reference counting has been considered a form of GC since the 1960s.
Rust isn't exactly revolutionary in its core memory management ideas, these have been around for a while and have been inside other languages. Cyclone, for example, is basically Rust (memory management wise) but as a safe dialect of C and a different stance on mutation and other things. It is not considered a GCd language. Rust just puts all these ideas together nicely.
The compiler doesn't actually keep track of a reference count, btw. Refcounting and linear types/ownership/borrowing lead to very different programming styles. In Rust's model you actually have to think about ownership and design your program with this in mind that as much as possible you want to use single ownership.
Given that they have very different impacts on programming style, they are pretty different practically speaking. On the other hand in swift you deal with memory management much like in Java, though with a few more choices you can make. Go might be a more apt comparison as far as memory management, though swift is more fine grained than Go as well.