1. 49

Got the title from https://twitter.com/migueldeicaza/status/1103427307451035648

  1.  

  2. 53

    You might even say they’re “borrowing” the model

    1. 23

      Too bad rust won’t be able to use it anymore.

      1. 16

        They can still use it, they just won’t be able to make any more changes.

        1. 2

          Digital piracy did it first, Rust is just an imposter

          1. 1

            Well played ;)

        2. 15

          The Swift ownership system is simpler and less intrusive than Rust’s lifetime system, which in Rust, unlike Swift, is part of the type system.

          From the article, an explanation why it isn’t like Rust:

          The lifetime-qualification systems behind first-class references in languages like Rust add a lot of complexity to the user model. That complexity has real costs for users. And it’s still inevitably necessary to sometimes drop down to unsafe code to work around the limitations of the ownership system. Given that a line does have to be drawn somewhere, it’s not completely settled that lifetime-qualification systems deserve to be on the Swift side of the line.

          1. 17

            I feel like one should also quote the next section:

            A Rust-like lifetime system would not necessarily be as powerful in Swift as it is in Rust. Swift intentionally provides a language model which reserves a lot of implementation flexibility to both the authors of types and to the Swift compiler itself.

            Rust Ownership and Lifetime system gains a lot from being the fundamentals of the language. It’s hard to add one one on top and reap the same benefits.

            Swift and Rust are approaching a similar problem space from different directions, but there’s a lot of cross-pollination between the two languages (especially given that a lot of Rust people ended up working for Apple at Swift and vice versa).

            That being said, I find the work being done on Swift very impressive and I’m sure they will gain a useful feature.

          2. 8

            Note that this doc is originally from 2017. The current version of Swift (4) has the first of the three “tentpoles”, exclusivity enforcement, by default in debug builds. Swift 5 will be out in the next few months and turn exclusivity enforcement on in release builds.

            More info here: https://swift.org/blog/swift-5-exclusivity/

            Now that Swift 5 is getting ABI stability nailed down, I hope we’ll see more of the proposals in this doc (as well as other things like concurrency improvements!) get implemented.

            1. 2

              I wish Swift would gain wider adoption for cross platform work. I like it quite a bit but find being constrained to XCode/OSX for many things quite frustrating.

              1. 2

                There seems to be some sort of support for Linux (well, Ubuntu at least).

                1. 1

                  Seems like maybe it’s gotten better. There’s always been runtime support, but every time I ever looked at utilizing any kind of third party library, the assumption was always that you were building with XCode.

                  1. 1

                    Yes it got much better. Especially important is SwiftPM(Swift Package Manager) which handles cross-platform build as well as dependency.

                    1. 1

                      That’s really fantastic to hear. When I last dipped a toe in - many months ago at this point, the docs basically said “You pretty much have to develop using XCode”.

                      This is kind of a deal breaker for me since I’m expunging all my Mac related infrastructure in favor of commodity hardware (mostly running Linux).

              2. 2

                See this part of the document for an explicit comparison to Rust.

                1. 1

                  I’m pretty hyped up about this as someone who used both Rust and Swift, and while I liked the safety model of Rust, I found Swift a lot easier to get productive with, especially as a Mac user.

                  Are there more languages employing a similar ownership model?

                  1. 1

                    I think “Swift a lot easier to get productive with” exactly because it doesn’t check ownership.

                    If Swift adopts something like this, it will become harder to get productive in Swift.

                    Just because it is built by Apple doesn’t mean there is a free lunch – getting from Cyclone’s or ATS’ level of usability to Rust’s level of usability required massive efforts and hard work by smart people.

                    If Swift wants to substantially improve on this (to avoid making their language harder to get productive with), Apple will have to put an massive effort into it and I think they will run into hiring limitations quite soon, because there are not that many people on this planet that are a) capable and b) unemployed.

                    1. 1

                      The idea as laid out is for it to be “opt-in” and used only in code where the benefits are important, with everything else still using ARC. At least in theory, the average Swift developer who isn’t doing low-level library/kernel/embedded/real-time/etc work won’t ever even encounter it. Sounds like the best of both worlds; we’ll see how well that works in practice, of course.

                      1. 1

                        As usual in those “best of both worlds” scenarios I’d assume that you will pay the complexity of both, plus additional complexity of making them integrate with each other, while gaining only limited benefits. At least if you consider such failed attempts like mixed types/untyped languages.

                        1. 2

                          I thought gradual typing, typified by TypeScript, was a great success and model of transfer from research to application. Why do you think it is a “failed attempt”?

                          1. 1

                            I agree with your point, but I think TypeScript is the odd one out in multiple ways:

                            • The lack of deep class hierarchies makes mixing typed/untyped code less painful in practice.
                            • Most efforts of going the hybrid route not only want safer code, but also want to derive runtime benefits from it. TypeScript never had to deal with this issue, due to man-centuries spent on making a very slow language (JavaScript) very fast, without relying on static types.
                            • The types don’t need to be correct, because the runtime saves you from wrong assumption, or better said – wrong assumptions in types don’t lead to misoptimizations/wrong code gen in the backend.

                            So yes, TypeScript is a success, but only repeatable if you have similar resources as Microsoft, Google and Mozilla combined.