6 ms·

>Can you elaborate on this? The languages seem very different to me--Swift is garbage collected (reference counting being a form of GC), for example. ARC is no

by Jerry2 10y ago

>Can you elaborate on this? The languages seem very different to me--Swift is garbage collected (reference counting being a form of GC), for example. ARC is not garbage collection [0]. Swift doesn't have a separate processes managing memory during the runtime. In Swift, compiler analyzes the code during the static compilation pass and inserts release/retain code during the compile time. See this SO answer for more info [1]. And you don't have to use ARC if you don't want to [2]. GC in Java or Go or CLR, for example, is completely different. Obj-C 2.0 was garbage collected but Apple hated it because of GC pauses and they vowed to remove it and never use GC again. [3] Hence, they developed ARC. [0] https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting [1] http://stackoverflow.com/a/7894809 http://stackoverflow.com/a/7894809 [2] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html#//apple_ref/doc/uid/TP40014097-CH20-XID_88 https://developer.apple.com/library/ios/documentation/Swift/... [3] https://en.wikipedia.org/wiki/Objective-C#Garbage_collection https://en.wikipedia.org/wiki/Objective-C#Garbage_collection

MichaelGG 10y ago
ARC is a form of GC, but the definition doesn't matter. Why do you say this is a wider range of applications? Swift's ARC no doubt slows it down and makes it unsuitable for some applications, right?
- winstonewert 10y ago
  Is Rust's borrow system also a form of garbage collection?
  - steveklabnik 10y ago
    It is not, unless you count some library types that add reference counting, but those are rarely used. Ownership and borrowing are calculated at compile time, not runtime.
    - millstone 10y ago
      Borrowing is purely compile time, but ownership has a runtime component, essentially a 1 bit reference count, called the drop flag. This is needed because objects may be conditionally initialized or uninitialized, depending on runtime values.
      - erickt 10y ago
        The drop flag is only generated for types that implement the `Drop` trait. Furthermore, there's work [0] that will shift the drop flag out of the value onto the call stack frame, and then even only in situations where the compiler cannot statically prove that that the type will be dropped or not. This should save a lot of memory, and potentially open up a whole host of optimizations. [0]: https://github.com/rust-lang/rust/issues/34398 https://github.com/rust-lang/rust/issues/34398
        millstone 10y ago
        Yes, that's good. Swift also aggressively elides reference count modifications, and will stack-allocate class types if the lifetime can be proven.
        pcwalton 10y ago
        It is silly to try to equate the drop flags with atomic reference counting on the heap. We could statically eliminate the drop flag entirely if we wanted to, with aggressive tail duplication. (It's not worth it, though, because the drop flag never shows up in profiles, so the code size bloat would be a cure worse than the disease.) 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.
        millstone 10y ago
        Whoa! I simply observed that both Rust and Swift eliminate their respective forms of reference counting when the lifetimes are statically known. The optimization is analogous, even if the nature of the reference counting is very different, as you say. 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.
  - pcwalton 10y ago
    No. Automatic memory management dynamically (at runtime) works out which objects are no longer referenced. Swift's reference counting is a form of automatic memory management because keeping the reference counts up to date is a way of dynamically working out which objects are alive and dead. Rust's ownership system does not: it is static, in that objects are unconditionally freed at specific, static program points.
    - deleted 10y ago
      [deleted]
steveklabnik 10y ago
There's a split between industry and academia here. Reference counting is traditionally considered GC in the literature, but not by working programmers, who usually say "garbage collection" and mean "tracing garbage collection." Both Swift and Rust muddy this traditional ontology a bit. Swift's ARC has both a compile time and runtime component, and while the Rust language itself doesn't know anything about reference counting, we do provide such types in the standard library.
pcwalton 10y ago
Regardless of what Apple's documentation says, reference counting is garbage collection. This is academic consensus since the 1980s and there is no need to change. It is not a semantic quibble, because there are successful GC schemes that combine tracing with reference counting and aren't any less a form of GC for doing that.
Manishearth 10y ago
> Swift doesn't have a separate processes managing memory during the runtime Plenty of GCs don't have this. You can have cycle collectors and other GCs which run the GC pass on release events (depending on some heuristic) too. This is a terminology issue, anyway -- in academia reference counting is considered a form of GC. In software often the term is used to mean "tracing GC", or sometimes "any system that can automatically handle retain cycles". ----- This still doesn't answer why Swift has a wider range of possible applications, though. I do agree that Swift is or will be better suited for development on iOS, because of good API integration. Rust can program for iOS too, it's just that you will have better support for Swift :) But aside from that, Rust should be able to apply anywhere Swift does.

by Jerry2 10y ago

MichaelGG 10y ago

ARC is a form of GC, but the definition doesn't matter. Why do you say this is a wider range of applications? Swift's ARC no doubt slows it down and makes it unsuitable for some applications, right?

winstonewert 10y ago
Is Rust's borrow system also a form of garbage collection?
- steveklabnik 10y ago
  It is not, unless you count some library types that add reference counting, but those are rarely used. Ownership and borrowing are calculated at compile time, not runtime.
  - millstone 10y ago
    Borrowing is purely compile time, but ownership has a runtime component, essentially a 1 bit reference count, called the drop flag. This is needed because objects may be conditionally initialized or uninitialized, depending on runtime values.
    - erickt 10y ago
      The drop flag is only generated for types that implement the `Drop` trait. Furthermore, there's work [0] that will shift the drop flag out of the value onto the call stack frame, and then even only in situations where the compiler cannot statically prove that that the type will be dropped or not. This should save a lot of memory, and potentially open up a whole host of optimizations. [0]: https://github.com/rust-lang/rust/issues/34398 https://github.com/rust-lang/rust/issues/34398
      - millstone 10y ago
        Yes, that's good. Swift also aggressively elides reference count modifications, and will stack-allocate class types if the lifetime can be proven.
        pcwalton 10y ago
        It is silly to try to equate the drop flags with atomic reference counting on the heap. We could statically eliminate the drop flag entirely if we wanted to, with aggressive tail duplication. (It's not worth it, though, because the drop flag never shows up in profiles, so the code size bloat would be a cure worse than the disease.) 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.
        millstone 10y ago
        Whoa! I simply observed that both Rust and Swift eliminate their respective forms of reference counting when the lifetimes are statically known. The optimization is analogous, even if the nature of the reference counting is very different, as you say. 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.
- pcwalton 10y ago
  No. Automatic memory management dynamically (at runtime) works out which objects are no longer referenced. Swift's reference counting is a form of automatic memory management because keeping the reference counts up to date is a way of dynamically working out which objects are alive and dead. Rust's ownership system does not: it is static, in that objects are unconditionally freed at specific, static program points.
  - deleted 10y ago
    [deleted]

steveklabnik 10y ago

There's a split between industry and academia here. Reference counting is traditionally considered GC in the literature, but not by working programmers, who usually say "garbage collection" and mean "tracing garbage collection." Both Swift and Rust muddy this traditional ontology a bit. Swift's ARC has both a compile time and runtime component, and while the Rust language itself doesn't know anything about reference counting, we do provide such types in the standard library.

pcwalton 10y ago

Regardless of what Apple's documentation says, reference counting is garbage collection. This is academic consensus since the 1980s and there is no need to change. It is not a semantic quibble, because there are successful GC schemes that combine tracing with reference counting and aren't any less a form of GC for doing that.

Manishearth 10y ago

> Swift doesn't have a separate processes managing memory during the runtime Plenty of GCs don't have this. You can have cycle collectors and other GCs which run the GC pass on release events (depending on some heuristic) too. This is a terminology issue, anyway -- in academia reference counting is considered a form of GC. In software often the term is used to mean "tracing GC", or sometimes "any system that can automatically handle retain cycles". ----- This still doesn't answer why Swift has a wider range of possible applications, though. I do agree that Swift is or will be better suited for development on iOS, because of good API integration. Rust can program for iOS too, it's just that you will have better support for Swift :) But aside from that, Rust should be able to apply anywhere Swift does.