4 ms·

People interested in Swift at this level should also read Lattner’s comment on /r/rust about the possibility of extending Swift to include Rust’s statically che

People interested in Swift at this level should also read Lattner’s comment on /r/rust about the possibility of extending Swift to include Rust’s statically checked ownership and borrowing concepts: https://www.reddit.com/r/rust/comments/3vadg8/swift_is_open_source/cxnu2kk https://www.reddit.com/r/rust/comments/3vadg8/swift_is_open_...

bluejekyll 11y ago
If you read that though, it is not something that's a high priority for the team. Basically, 90% of devs won't need or want some of these features. Unless Apple decides to have a focused effort around recoding the core of OS X into Swift which would require these changes, it's hard to see when the language would gain these options. Don't get me wrong, Swift is an awesome language, but I see Rust as maintaining a position as a systems language equivalent to C. Where Swift will possibly start supplanting Java/Go/C++/Python use cases.
- pjmlp 11y ago
  As someone that would like to see C replaced by something better and has always been a fan for Wirth influenced languages, Swift has actually a better position to achieve that than Rust. The reason being that Apple, like it happened to OS vendors that adopted C and later C++, can allow themselves to push the language into the developers regardless of what they think they should use. All the systems languages that have survived in the mainstream, have done so by being adopted by an OS vendor.
  - lobster_johnson 11y ago
    Out of interest, in what way do you consider Swift a Wirth-influenced language? Go seems a closer cousin to Wirth's languages. Its strict type coercion, value copying semantics, package system, lack of OO, use of ":=", type declarations with "type", "var", GC, colons, etc. are all reminiscent of Wirth's languages, especially Oberon. (Robert Griesemer worked with Oberon under Wirth at ETH Zürick, so there's a clear relationship.) Another highly wirthian language is Nim, though its influence comes via Delphi/ObjectPascal.
    - acqq 11y ago
      > in what way do you consider Swift a Wirth-influenced language? It looks to me you misunderstood the post.
      - lobster_johnson 11y ago
        How so? He wrote: "As someone that [...] has always been a fan for Wirth influenced languages, Swift [is in a better position]." Why is the sentence premised on Wirth, if it's unrelated to Swift?
        pjmlp 11y ago
        Because Wirth designed/influenced languages for system programming that I consider better than C. Algol, Mesa, Object Pascal, Modula-2, Modula-3, Oberon, Oberon-2, Active Oberon, Oberon-07, Ada All of them were used to write full operating systems for a few years. However, except for Ada, all of them suffered from not being adopted by OS vendors that were able to deliver mainstream OS, as mainstream OS vendors adopted C to replace Assembly (Object Pascal on Apple's case) and eventually C++.
    - pjmlp 11y ago
      > Out of interest, in what way do you consider Swift a Wirth-influenced language? In the context that system programming languages shouldn't sacrifice safety, except when needed and be explicit about it with constructs like unsafe/SYSTEM and so on. Swift is very explicit when doing C style tricks, e.g. UnsafePointer<>. There is more to Wirth school of languages than just syntax.
      - lobster_johnson 11y ago
        The only "safe" Wirth language I know about is Oberon-2, which has bounds-checking of arrays, sentinels and runtime-checking of pointers — though no compile-time checking. Is this what you're referring to? I like Wirth, but his type systems were always super simple, and as far as I know, he never innovated at compile time safety in the way that, say, Rust or Haskell do. Again, Go seems a better analogue; anything that needs to deal with unsafe pointers needs to use the "unsafe" package.
  - kibwen 11y ago
    Apple isn't going to stop supporting C and C++ on their platforms, so it can't "push" Swift at the systems level the same way it can push Swift at the application level on iOS. I also disagree with your repeated claims that systems languages can only survive when they are pushed by an OS vendor. C and C++ dominate for a host of historical reasons (which I'm sure you're well acquainted with). Meanwhile, Rust, at a low level, is such a transparent skin over C and C++'s low-level semantics that it can almost be considered an alternate syntax for those languages (albeit an alternate syntax with extreme static analyzability). The takeaway should not be "systems languages only succeed when pushed by an OS vendor", it should be "programming languages tend to succeed when backed by a large corporate vendor and when they are used to write widely-used software that people come to rely on". Swift is guaranteed a bright future by dint of being the application programming language of choice for iOS. Rust's long-term fate likely hinges on Servo, but it's too soon to say whether that's the only large project that has a chance of entrenching Rust (give it six more months at least to see what nascent Rust projects are gathering in the post-1.0 calm).
    - pjmlp 11y ago
      > I also disagree with your repeated claims that systems languages can only survive when they are pushed by an OS vendor. I was there when Assembly was the only viable choice for targeting home computers, so excuse me if my life experience has made be a bit biased. So when I see Apple going with Swift, Google and Microsoft pimping up C++ and contributing to the C++ Core Guidelines, I get a deja-vu feeling. I hope that Rust does get adoption, that killer feature project that blows wind into its sails.
      - kibwen 11y ago
        > excuse me if my life experience has made be a bit biased. I appreciate the breadth of your experience, but I think that you're overlooking the context of modern systems languages. :) The systems languages of old were wedded to their intended operating systems (indeed, the motivating product was usually the OS itself, with the language being but a necessary feature (Unix/C is no exception here)). As history ran its course and those OSes fell by the wayside, those languages were naturally marginalized (did there even exist usable Mesa/Modula-2/etc. compilers for Unix?). Rust is different because it is not beholden to the fate of any single operating system. Not only is it cross-platform by intent, it has hitched its cart to a world-class retargetable backend for the dominant systems languages of today, meaning that platform availability will never be a problem. There are still plenty of reasons why Rust could fail, of course. But Rust does not require the OS vendors' permission to exist on their platforms (well, except for on non-jailbroken iOS, anyway), and the Rust devs are not especially concerned with those platforms integrating Rust into their kernels (though I'm sure they wouldn't mind).
- pcwalton 11y ago
  Historically, languages that have tried to move from automatic memory management to opt-in manual memory management haven't had a lot of success in doing so. Java direct buffers don't let you do anything more than simple flat heap allocations, and you can't really get away from GC. D hasn't been able to shed a practical dependency on the GC, despite years and years of work. There was some early work to try to use Go in places where GC isn't acceptable, but in practice you can't really avoid it. And so on. Interestingly, the reverse is also true. C++ does not make very good managed language: despite the occasional claim to the contrary, the lack of memory safety and the library ecosystem mean you can't just use shared_ptr "for everything" and forget about memory management in practice. Rust is also in a similar situation: borrowing is front and center, and the language doesn't really try to make managed programming palatable: you have to explicitly clone reference counted pointers, and you need Cell/RefCell if you want to mutate their contents. A lot of this has to do with the library ecosystem. Even if the language supports manual memory management, if the package ecosystem doesn't you can't really program with it in practice. I don't know of any language (with one possible exception below) that has effectively subdivided its package landscape into managed and unmanaged ecosystems. Objective-C is probably one of the few exceptions where you can really mix and match the two worlds. That's because there are effectively two library ecosystems: the C/C++ ecosystem on one hand, and the native Objective-C system on the other. It's a special case because Objective-C/Objective-C++ basically mashes two popular languages together while maintaining full compatibility with the existing C/C++ library landscape. I don't know if you can replicate this without source-level C and C++ compatibility (which Swift drops). The upshot of this, in my mind, is that assuming history repeats itself, multiple languages are probably going to thrive. There won't be one language to rule them all, and large software stacks will mostly continue to consist of components written in multiple languages. Which is, of course, great for us compiler developers, and programming language innovation in general. :)
  - bluejekyll 11y ago
    I get your points, and they're totally valid criticisms of Rust, but I see them as learning curve issues as opposed to oppressive things that are incompatible with certain development practices. In C it's easy to pick up the language, but to manage memory properly is very hard, if not complely unclear in certain cases, C++ is similar. Rust does have direct support for exposing FFI from C quickly in both directions. Objective-C while it could easily incorporate C, it is not easy to go the other direction because of the runtime requirements. The safety of Rust requires learning some patterns to develop properly, but is quite honestly amazing in terms of the guarantees you get.

bluejekyll 11y ago

If you read that though, it is not something that's a high priority for the team. Basically, 90% of devs won't need or want some of these features. Unless Apple decides to have a focused effort around recoding the core of OS X into Swift which would require these changes, it's hard to see when the language would gain these options. Don't get me wrong, Swift is an awesome language, but I see Rust as maintaining a position as a systems language equivalent to C. Where Swift will possibly start supplanting Java/Go/C++/Python use cases.

pjmlp 11y ago
As someone that would like to see C replaced by something better and has always been a fan for Wirth influenced languages, Swift has actually a better position to achieve that than Rust. The reason being that Apple, like it happened to OS vendors that adopted C and later C++, can allow themselves to push the language into the developers regardless of what they think they should use. All the systems languages that have survived in the mainstream, have done so by being adopted by an OS vendor.
- lobster_johnson 11y ago
  Out of interest, in what way do you consider Swift a Wirth-influenced language? Go seems a closer cousin to Wirth's languages. Its strict type coercion, value copying semantics, package system, lack of OO, use of ":=", type declarations with "type", "var", GC, colons, etc. are all reminiscent of Wirth's languages, especially Oberon. (Robert Griesemer worked with Oberon under Wirth at ETH Zürick, so there's a clear relationship.) Another highly wirthian language is Nim, though its influence comes via Delphi/ObjectPascal.
  - acqq 11y ago
    > in what way do you consider Swift a Wirth-influenced language? It looks to me you misunderstood the post.
    - lobster_johnson 11y ago
      How so? He wrote: "As someone that [...] has always been a fan for Wirth influenced languages, Swift [is in a better position]." Why is the sentence premised on Wirth, if it's unrelated to Swift?
      - pjmlp 11y ago
        Because Wirth designed/influenced languages for system programming that I consider better than C. Algol, Mesa, Object Pascal, Modula-2, Modula-3, Oberon, Oberon-2, Active Oberon, Oberon-07, Ada All of them were used to write full operating systems for a few years. However, except for Ada, all of them suffered from not being adopted by OS vendors that were able to deliver mainstream OS, as mainstream OS vendors adopted C to replace Assembly (Object Pascal on Apple's case) and eventually C++.
  - pjmlp 11y ago
    > Out of interest, in what way do you consider Swift a Wirth-influenced language? In the context that system programming languages shouldn't sacrifice safety, except when needed and be explicit about it with constructs like unsafe/SYSTEM and so on. Swift is very explicit when doing C style tricks, e.g. UnsafePointer<>. There is more to Wirth school of languages than just syntax.
    - lobster_johnson 11y ago
      The only "safe" Wirth language I know about is Oberon-2, which has bounds-checking of arrays, sentinels and runtime-checking of pointers — though no compile-time checking. Is this what you're referring to? I like Wirth, but his type systems were always super simple, and as far as I know, he never innovated at compile time safety in the way that, say, Rust or Haskell do. Again, Go seems a better analogue; anything that needs to deal with unsafe pointers needs to use the "unsafe" package.
- kibwen 11y ago
  Apple isn't going to stop supporting C and C++ on their platforms, so it can't "push" Swift at the systems level the same way it can push Swift at the application level on iOS. I also disagree with your repeated claims that systems languages can only survive when they are pushed by an OS vendor. C and C++ dominate for a host of historical reasons (which I'm sure you're well acquainted with). Meanwhile, Rust, at a low level, is such a transparent skin over C and C++'s low-level semantics that it can almost be considered an alternate syntax for those languages (albeit an alternate syntax with extreme static analyzability). The takeaway should not be "systems languages only succeed when pushed by an OS vendor", it should be "programming languages tend to succeed when backed by a large corporate vendor and when they are used to write widely-used software that people come to rely on". Swift is guaranteed a bright future by dint of being the application programming language of choice for iOS. Rust's long-term fate likely hinges on Servo, but it's too soon to say whether that's the only large project that has a chance of entrenching Rust (give it six more months at least to see what nascent Rust projects are gathering in the post-1.0 calm).
  - pjmlp 11y ago
    > I also disagree with your repeated claims that systems languages can only survive when they are pushed by an OS vendor. I was there when Assembly was the only viable choice for targeting home computers, so excuse me if my life experience has made be a bit biased. So when I see Apple going with Swift, Google and Microsoft pimping up C++ and contributing to the C++ Core Guidelines, I get a deja-vu feeling. I hope that Rust does get adoption, that killer feature project that blows wind into its sails.
    - kibwen 11y ago
      > excuse me if my life experience has made be a bit biased. I appreciate the breadth of your experience, but I think that you're overlooking the context of modern systems languages. :) The systems languages of old were wedded to their intended operating systems (indeed, the motivating product was usually the OS itself, with the language being but a necessary feature (Unix/C is no exception here)). As history ran its course and those OSes fell by the wayside, those languages were naturally marginalized (did there even exist usable Mesa/Modula-2/etc. compilers for Unix?). Rust is different because it is not beholden to the fate of any single operating system. Not only is it cross-platform by intent, it has hitched its cart to a world-class retargetable backend for the dominant systems languages of today, meaning that platform availability will never be a problem. There are still plenty of reasons why Rust could fail, of course. But Rust does not require the OS vendors' permission to exist on their platforms (well, except for on non-jailbroken iOS, anyway), and the Rust devs are not especially concerned with those platforms integrating Rust into their kernels (though I'm sure they wouldn't mind).
pcwalton 11y ago
Historically, languages that have tried to move from automatic memory management to opt-in manual memory management haven't had a lot of success in doing so. Java direct buffers don't let you do anything more than simple flat heap allocations, and you can't really get away from GC. D hasn't been able to shed a practical dependency on the GC, despite years and years of work. There was some early work to try to use Go in places where GC isn't acceptable, but in practice you can't really avoid it. And so on. Interestingly, the reverse is also true. C++ does not make very good managed language: despite the occasional claim to the contrary, the lack of memory safety and the library ecosystem mean you can't just use shared_ptr "for everything" and forget about memory management in practice. Rust is also in a similar situation: borrowing is front and center, and the language doesn't really try to make managed programming palatable: you have to explicitly clone reference counted pointers, and you need Cell/RefCell if you want to mutate their contents. A lot of this has to do with the library ecosystem. Even if the language supports manual memory management, if the package ecosystem doesn't you can't really program with it in practice. I don't know of any language (with one possible exception below) that has effectively subdivided its package landscape into managed and unmanaged ecosystems. Objective-C is probably one of the few exceptions where you can really mix and match the two worlds. That's because there are effectively two library ecosystems: the C/C++ ecosystem on one hand, and the native Objective-C system on the other. It's a special case because Objective-C/Objective-C++ basically mashes two popular languages together while maintaining full compatibility with the existing C/C++ library landscape. I don't know if you can replicate this without source-level C and C++ compatibility (which Swift drops). The upshot of this, in my mind, is that assuming history repeats itself, multiple languages are probably going to thrive. There won't be one language to rule them all, and large software stacks will mostly continue to consist of components written in multiple languages. Which is, of course, great for us compiler developers, and programming language innovation in general. :)
- bluejekyll 11y ago
  I get your points, and they're totally valid criticisms of Rust, but I see them as learning curve issues as opposed to oppressive things that are incompatible with certain development practices. In C it's easy to pick up the language, but to manage memory properly is very hard, if not complely unclear in certain cases, C++ is similar. Rust does have direct support for exposing FFI from C quickly in both directions. Objective-C while it could easily incorporate C, it is not easy to go the other direction because of the runtime requirements. The safety of Rust requires learning some patterns to develop properly, but is quite honestly amazing in terms of the guarantees you get.