6 ms·

>However, languages don't live in a vacuum. Swift has the added benefit of opening up a whole world of possibilities in the Apple ecosystem, not to mention read

by Jerry2 10y ago

>However, languages don't live in a vacuum. Swift has the added benefit of opening up a whole world of possibilities in the Apple ecosystem, not to mention readily available jobs. Because of this, I'd be inclined to invest in Swift rather than Rust. Rust & Swift are fairly similar but Swift has a much wider range of possible applications. Swift is also moving very fast (that's to be expected since it's backed by one of the most valuable companies on Earth). This is the primary reason why I picked Swift over Rust for a project I'm working on (I'm working on an open-source password key store for high-volume services).

icebraining 10y ago
Swift has a much wider range of possible applications Why?
pcwalton 10y ago
> Rust & Swift are fairly similar but Swift has a much wider range of possible applications. 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.
- 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.

by Jerry2 10y ago

icebraining 10y ago

Swift has a much wider range of possible applications Why?

pcwalton 10y ago

> Rust & Swift are fairly similar but Swift has a much wider range of possible applications. 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.

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.