15 ms·

To me Swift is one of the most interesting languages right now. It's killer for iOS development of course, but Swift for Tensorflow[0] is exciting and could bec

To me Swift is one of the most interesting languages right now. It's killer for iOS development of course, but Swift for Tensorflow[0] is exciting and could become a refreshing alternative to python for machine learning. Here Swift System + Swift for Linux could make it a compelling alternative to Go or Rust in the future. Looking at Swift System, one interesting thing to note is that they are wrapping the library functions rather than calling into the kernel directly. The source for that is here: https://github.com/apple/swift-system/blob/main/Sources/SystemInternals/Exports.swift https://github.com/apple/swift-system/blob/main/Sources/Syst... [0] Yes, I'm aware of the staffing issues. No need to beat that dead horse again.

wwright 6y ago
I don't think Swift really competes with Rust or Go at all. - Go aims to be simple enough for many engineers to be productive with little investment. - Rust aims to be extremely reliable and efficient. Swift is very complex, and makes many compromises away from reliability or efficiency in favor of application use cases. Swift may fill an interesting role for a "native C#" that is mostly reliable, mostly efficient, and somewhat productive, but on the other hand, C#, OCaml, Java, Kotlin, and so on already have various answers to that, and they're only becoming better at it. The only real advantage it has (as far as I can tell) is iOS (and TensorFlow almost as a knock-on of being the only serious language for iOS).
- usmannk 6y ago
  > Rust aims to be extremely reliable and efficient. Fair point, Swift will never be as predictable or efficient as Rust (not a negative perse, just different goals). But I disagree on the complexity re: Go. What about Swift gives you the impression of extreme complexity? Go is definitely comparatively simpler but I do not think it is so much so as to put it in a different league.
  - novok 6y ago
    The type errors you start running into with generics with all of their weird limitations in swift can make things complicated fast. That and RxSwift. Also swift as a language doesn't scale well. There are a lot of bottlenecks in the build process that doesn't let you scale simply amongst many cores like you can with C++, Obj-C & C and probably many other languages too. You're also effectively limited to xcode & apple desktops, so you can't go rent out a 100 core build server on AWS for builds like you can for every other platform out there, not that is matters much yet with swift's build scaling issues. Also stuff like basic debugging often just... dies. The more I work with a badly scaling language the more I appreciate a design decision like go made with building fast. I hope with generics in go v2 the boilerplate should reduce a lot.
    - jshier 6y ago
      When was the last time you compiled Swift code? Xcode's new(er) build system has solved many of the scaling issues that affected the previous system, to the point where it scales linearly (on large enough projects) even on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with cmake's native Swift support in 3.18(?), the scaling should be more solved across platform as well. There's certainly nothing in the language itself that prevents scaling builds, only the compiler and build systems. The debugger is still rough, true, but improving. Apple just isn't spending the resources needed to bring lldb up to a great experience in a timely fashion.
      - novok 6y ago
        Yesterday! Swifts build system can split off enough threads to consume all of your CPU cores, and batch mode did improve things, but it's not actually doing so efficiently. There is a trade off between total compute time used and number of threads used. In compute time consumed, swift is the most efficient when it's single threaded in WMO mode, but this means you can only compile in parallel with separate modules that don't depend on each other. And even then it's not a very fast compiling language itself, multithreading issues notwithstanding Maybe something has changed recently, but as far as Xcode 12 goes, I haven't noticed much of a difference. I last checked deeply with swift 4. More details here: https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md https://github.com/apple/swift/blob/master/docs/CompilerPerf...
- kitsunesoba 6y ago
  I think one of Swift's advantages is its progressive disclosure. It can be written without using any of its more advanced features, making it approachable without limiting possibilities for more advanced users.
  - usmannk 6y ago
    I agree. I referenced this (perhaps a bit too implicitly) in a sibling comment. Swift's complexity is there but only when you need it.
  - cylon13 6y ago
    Can it be read without knowing about its more advanced features though? Production software is read much more often than it is written.
    - nicoburns 6y ago
      I've been able to dip into Swift codebases with zero previous experience without too much trouble. I do have Rust experience which helps. But never-the-less everyday Swift seemed pretty readable to me.
    - cutler 6y ago
      Swift has some really clunky "features" such as dual-identifier parameters and escaped opening parens as identifiers for string templates. WTF! As if function/method declarations weren't complex enough in a statically-typed language which supports generics.
      - pansa2 6y ago
        > escaped opening parens as identifiers for string templates Do you mean the use of “\(variable)” for string interpolation? What’s wrong with that?
        cutler 6y ago
        It's just downright clunky. What's wrong with ${variable} as in Kotlin and Javascript?
- wffurr 6y ago
  Swift has almost seamless interoperability with existing C and C++ libraries and has much stronger safety guarantees than either of those languages. It's not on the same level as Rust, but ARC eliminates entire classes of memory safety issues. The Swift runtime is large-ish, but not outrageously so, and is generally statically compiled-in to the binaries, so there's no dependencies on dynamic libraries. It is, as you say, quite complex, but still an interesting choice IMO.
  - dagmx 6y ago
    Minor nitpick but it does not have seamless interfacing with anything other than Objective C. C can be exposed as Objective C, but C++ has to go through C (potential objective C++) first. This is really no different than most other languages. What it does do is provide good auto binding tools however to expose classes and objects bidirectionally to objective C.
    - deleted 6y ago
      [deleted]
    - ladon86 6y ago
      My understanding was that there is no need to involve Objective-C if you’re directly interfacing with C. That interop is direct/seamless, and works on Linux etc. even without Objective-C or Darwin [0]. But the C++ story is what you’ve described above. [0] https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_functions_in_swift https://developer.apple.com/documentation/swift/imported_c_a... and https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift https://developer.apple.com/documentation/swift/imported_c_a...
      - wool_gather 6y ago
        I wouldn't say "seamless". Interacting with C directly from Swift is possible, and fine from a binary perspective, but quite clunky at the source level. (Which obviously is a motivation for the library that is being announced here.) There are still assorted gaps in C imports -- a key example is forward-declared structs, that _all_ arrive in Swift as a _single shared_ `OpaquePointer` type: https://forums.swift.org/t/opaque-pointers-in-swift/6875 https://forums.swift.org/t/opaque-pointers-in-swift/6875
- webmobdev 6y ago
  Where do you think Ada - a mature and tested language - fit in between these 3 newbies?
  - wwright 6y ago
    I don't know Ada well personally, but from what I've read, it's a bit less advanced than Rust at static checks, a good bit simpler than Rust and Swift but more complex than Go, and a little bit old-fashioned in approach (verbose syntax and all that). But I'm not very educated. I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not).
    - pjmlp 6y ago
      Rust lacks the formal specifications from SPARK. And SPARK 2014 will support ownership specifications. Rust is the less advanced one.
      - wwright 6y ago
        Good feedback there :)
    - thesuperbigfrog 6y ago
      >> I don't know Ada well personally >> But I'm not very educated. If you don't know, please don't speculate. I use Ada professionally and I am experimenting with Rust. Rust has great promise and I am interested to see where it will go, especially as an alternative to C++. >> it's a bit less advanced than Rust at static checks Ada 2012 has comparable and in many cases more advanced static checks than Rust with the exception of memory management. This is especially true of the Ada type system (https://learn.adacore.com/courses/intro-to-ada/chapters/strongly_typed_language.html https://learn.adacore.com/courses/intro-to-ada/chapters/stro...) and design by contracts (https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont...). If you use the SPARK subset of Ada, you can use advanced tools to prove the correctness of your program. See https://learn.adacore.com/courses/intro-to-spark/index.html https://learn.adacore.com/courses/intro-to-spark/index.html Rust's borrow checker approach to memory management is novel and SPARK is acutally adding similar concepts to the next version of SPARK (https://blog.adacore.com/using-pointers-in-spark https://blog.adacore.com/using-pointers-in-spark). >> a good bit simpler than Rust and Swift but more complex than Go Ada is a large and fairly complex language because it was designed for hard real-time, safety-critical, embedded systems and it has been in real-world use for 40+ years. I don't think it is that simple, but judging simplicity is subjective: what one person sees as complex, another person might see as simple. You can browse the Ada 2012 Language Reference Manual and see what you think: http://ada-auth.org/standards/12rm/html/RM-TOC.html http://ada-auth.org/standards/12rm/html/RM-TOC.html >> a little bit old-fashioned in approach (verbose syntax and all that). This comes from the Ada design philosophy to be explicit in everything and to prefer the use of keywords over symbols. "Readability is more important than conciseness. Syntactically this shows through the fact that keywords are preferred to symbols, that no keyword is an abbreviation, etc." (See https://learn.adacore.com/courses/intro-to-ada/chapters/introduction.html#philosophy https://learn.adacore.com/courses/intro-to-ada/chapters/intr...) Long-life programs tend to be read more than they are written. The Ada way is to make programs easier to read rather than faster to write. >> I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not). This is largely true. Ada occupies a niche for aerospace and other safety-critical areas, but has not been widely adopted due to the "uncoolness" factor and the cost of most of the available Ada compilers and toolchains. I think the popularity of Rust has peaked some interest in Ada as well, but I am not sure if it will cause any change it where either are used. I would like to see Rust to continue to mature and get adopted for wide-spread use with multiple implementations and a language standard. As it currently stands, many aerospace and safety-critical spaces would not be willing / able to adopt Rust without a language standard and certifications. Here's hoping . . .
- coldtea 6y ago
  >Swift is very complex, and makes many compromises away from reliability or efficiency in favor of application use cases. Swift is only complex if you need it, otherwise very easy, with few caveats. And it's efficient enough for all application / cli etc use cases -- if Go can do it, Swift can do it even better. It's not Rust in performance and low-levelness, but Rust is the "really complex" one in its semantics and learning curve.
  - mjlawson 6y ago
    > if Go can do it, Swift can do it even better. This might be hyperbole, but if not I'd love to see some examples on how Swift can improve on Go's concurrency patterns.
    - coldtea 6y ago
      It might not offer first class support for green threads like Go, but GCD is an even better imho model for 90% of concurrency needs of the average app: https://developer.apple.com/documentation/DISPATCH https://developer.apple.com/documentation/DISPATCH
      - microcolonel 6y ago
        "concurrency needs of the average app" is different from what Go does well with green threads; this seems like something Swift does notably worse, but well enough that it doesn't annoy you in your use case. I feel like this is a different standard from "if Go can do it, Swift can do it better".
      - harikb 6y ago
        Isn’t that just a bridge to an existing OS level feature? Also is GCD green? (As in light weight, co-operative muti-threading)
        coldtea 6y ago
        >Isn’t that just a bridge to an existing OS level feature? Yes. A feature well designed for this very purpose. >Also is GCD green? GCD tasks are not green threads but they're not direct threads either (even though they're used under the hood). They're more lightweight and much faster to create (than direct OS threads).
- throw_m239339 6y ago
  > - Go aims to be simple enough for many engineers to be productive with little investment. Go isn't simpler, there is just a defered cost engineers pay later on when it turns out one cannot just do away with complexity by deeming it irrelevant.
  - Thaxll 6y ago
    Some FUD right there... What exactly is the deffered cost? Give real examples please.
    - earthboundkid 6y ago
      I love Go, but there is a strong case that Kubernetes has a messy codebase because Go didn’t have good dependency management or generics when they started it. The strength of the ecosystem in other areas let them get started and now they have the tragedy of success, a la Wordpress.
      - studmuffin650 6y ago
        Part of the issues with Kubernetes is that it started as a Java project and then it became a Go project. If anyone started a large Go project with that mindset it would look messy no matter what you did.
        bad_user 6y ago
        Can you point to any large Go project that isn’t a mess? I agree that from a single sample you can’t reach conclusions, but “it was their fault” isn’t a great defense.
        nix23 6y ago
        Can YOU point to any large project that isn’t a mess?
        6y ago
- bilekas 6y ago
  I'll tell you: You're wrong, so is OP. Benching languages against eachother is like pitting birds of prey against eachother, its pointless because they will hunt what they hunt. This language/framework dispute I though was fever back in bad PHP days has not changed. I'm not saying; 'oh you kids dont know shit' I'm saying the language is not the problem, the problem is the problem, the right tool for said problem is the answer. You find Swift complex and speak about why, you're not wrong with its application, iOS it does very well, therefore its a tool for an iOS job. If I grew up just learning Swift and nothin else, I would say swift is the best . Plato's cave springs to mind. We are all Engineers, Developers, Hackers, Designers and or Code Monkeys.. Don't try to pit against, know the right tool for the job, if you cant find it, make it. With people who can. I though thats how we roll
  - wwright 6y ago
    To be clear, that’s kind of what I was trying to say :) maybe the “only advantage” part at the end made that unclear. I think the problems you’d want to use Go for, the problems you’d want to use Rust for, and the problems you’d want to use Swift for are largely non-overlapping (in spite of whatever similarities they do have).
- jillesvangurp 6y ago
  I think you are focusing on a bit artificial things here with things like intentions and other biases and notions. Swift is a statically compiled, C like language, that can be used for system programming. Just like C, C++, Rust, Go, etc. This is not an accident. It was built from the ground up to do that. The goal with this OSS library is literally making swift easier to use in projects where you'd otherwise reach for exactly those languages. So, whether you like it or not, it's competing (or at least trying to) in that space (i.e. system programming). Actually, Swift was designed to replace Objective C, which of course was the system programming language that Apple standardized on as an alternative to C decades ago. It's designed from the ground up to be a drop in replacement in any project where you'd previously be using that. So, it's a natural fit for any kind of project where you'd otherwise be considering things like Rust, C++, Go, C, etc. Whether that makes sense or not in your context is of course up for debate and highly subjective.
dmitriid 6y ago
I will gather a lot of downvotes, but still: I find Swift a very haphazardly designed language with very little foresight and forethought. This is further compounded by its standard libraries which are directly lifted from MacOS with all of their idiosyncrasies and huge incompatible changes from version to version. For what it's worth, [1] [2] [3] [4] [1] A type system that can't cope with SwiftUI: https://tonsky.me/blog/swiftui/ https://tonsky.me/blog/swiftui/ [2] More syntax to shake a stick at https://twitter.com/dmitriid/status/1276482336486576133 https://twitter.com/dmitriid/status/1276482336486576133 [3] Even more syntax weirdness https://twitter.com/bradfitz/status/1285302091544576000 https://twitter.com/bradfitz/status/1285302091544576000 [4] Standard library between versions: https://twitter.com/dmitriid/status/1201441652507844608 https://twitter.com/dmitriid/status/1201441652507844608 File manipulation functions on String, great design.
- valuearb 6y ago
  So you ding the language because of a suboptimal choice made by one tool for it? The good and bad of Swift is the regular breaking updates. Sure it’s a pain when things change, but it’s also healthy when they improve, and almost every change has been an improvement. A language as simple as C can slowly grow without breaking existing source code. But it’s also never been able to address its most significant flaws.
  - dmitriid 6y ago
    > So you ding the language because of a suboptimal choice made by one tool for it? I provided 4 different links showing multiple different features in the language I find suboptimal. > Sure it’s a pain when things change, but it’s also healthy when they improve, and almost every change has been an improvement. It's a very dubious statement at the very least. > But it’s also never been able to address its most significant flaws. Can Swift address its flaws even with its breaking changes? So far its been piling on more and more syntax, and continuously breaking its standard library (whose design choices like writing to files from Strings are very dubious)?
- deleted 6y ago
  [deleted]
untog 6y ago
IMO (as someone who has written plenty of Swift and Rust) Rust is in category of its own here. It's a fantastic language and I love working with it... but it has a mental overhead in dealing with ownership, borrow checking etc that other languages don't. It's amazing in situations where performance is critical, or where you have constrained resources. But I'd much rather use Swift in other situations.
adamnemecek 6y ago
I used to be a bit of a Swift fan boy, but then I switched to Rust (I was a Rust fanboy for even longer but thought that Swift was better for my use case which is a native macos app). I have not looked back. The Swift ecosystem is mostly people wrapping Apple APIs. God help you if you want to have a swift package with some metal code in it. Rust cargo manages this without a hiccup. Swift is nice as long as daddy Apple had your use case in mind, God forbid you have to tweak something. Rust feels more "timeless". Swift for TF is dead.
- rhodysurf 6y ago
  For a while I was looking aggressively at using swift everywhere, but then I tried rust and read this https://v4.chriskrycho.com/rust-and-swift.html https://v4.chriskrycho.com/rust-and-swift.html and gained a new respect for Rust and have been using it whenever I can since.
  - valuearb 6y ago
    Boy that is really old. And oppressively detailed. And ends up sounding like a Coke vs Pepsi argument. Do I really care about the minutia of minor features when I can build the same things with both tools? For server side I’m probably going to use Rust, for MacOS or iOS I’m certainly using Swift, for Android I choose Kotlin, and for Windows I would choose suicide.
    - rhodysurf 6y ago
      It definitely is old, but a lot of the points still stand with respect to swift syntax. Anyway I was trying to use swift for things outside of iOS work to share code and it wasnt worth it, is what I'm really getting at. So agreed on your whole second sentence haha
    - adamnemecek 6y ago
      I'm using rust and metal on macos and it's pretty nice. I'll switch to wgpu eventually, it's similar enough to metal.
    - 6y ago
StreamBright 6y ago
What is the unique value set that it brings to the table?
marta_morena_29 6y ago
Why would you mention Swift, Go and Rust in the same context? I mean Swift vs. Go kinda has some merit, although they have completely different intentions. At least Go doesn't aspire to be a systems programming language. Rust definitely has no place in this comparison. Rust serves a niche market of systems programming that is so security focused that C/C++ just won't do. It's not useful for anything else (at least not anymore than Haskell is useful for anything besides university projects, in the real world at least). Swift has many nice similarities with Rust and other current languages from a pure syntactical/language perspective, while aiming to be a GP language. It definitely serves a broader audience than Go, whose main target is server programming. Swift's main target is Apple UI programming, however, the language is capable of so much more. Which is why Open Source is good news. It may make it escape its Apple box.
- rkrzr 6y ago
  Why the cheap swipe at Haskell? We use Haskell very productively in the real world. You can take a look at some of our blog posts here, if you want to learn more: https://tech.channable.com/ https://tech.channable.com/ Here is one post about writing an Aho-Corasick implementation in Haskell which is as fast as the fastest Rust implementation: https://tech.channable.com/posts/2019-03-13-how-we-made-haskell-search-strings-as-fast-as-rust.html https://tech.channable.com/posts/2019-03-13-how-we-made-hask...
- oaiey 6y ago
  Harsh words. I agree with the statement, but Rust is used not only for system programming and Haskell has its niche beyond university. I think Swift is where .NET was in its first decade. While capable of so much more, it is limited by its designers and primary purpose so it cannot go beyond. The tight coupling to UI products is a burden an ecosystem carries. Java won in the backend not with is UI, JavaScript with node/npm before Angular reset the frontend and C# just when .NET Core pushed it into spaces it has not been before (apis, lambdas, etc).
- jtsiskin 6y ago
  What do you mean by "so security focused that C/C++ just won't do"? Anything on the internet should be cautious of memory unsafety issues. Something like an image processing library I won't consider 'security focused' yet I would trust one written in Rust over one written in C.
amelius 6y ago
> but Swift for Tensorflow[0] is exciting and could become a refreshing alternative to python for machine learning I prefer the landscape for ML not to be fragmented based on non-essential qualities like the language that is used. How great is it that researchers publish code in the same language, and everybody can use that code immediately without having to learn language X and/or porting the implementation?
- skohan 6y ago
  My problem with Python is that once you start working with a strongly-typed language, a duck-typed interpreted language starts to feel like it's missing a major tool in terms of writing correct code. I also think S4TF's approach has been really neat here: there's a really nice python interop so you still have access to the entire body of work and tools in python available, and it basically feels like writing native swift code.
  - formerly_proven 6y ago
    > My problem with Python is that once you start working with a strongly-typed language, a duck-typed interpreted language starts to feel like it's missing a major tool in terms of writing correct code. I primarily write C++ and Python and never feel like this.
    - skohan 6y ago
      Not all type systems are created equal. Swift's is powerful and expressive
      - amelius 6y ago
        You could at least explain what features set it apart, in your opinion, from other type systems and why they are important in this case ...
        skohan 6y ago
supernintendo 6y ago
How many active Linux projects are still written in Objective C? Personally, I see no compelling reason to use Swift on Linux. Programming languages are dime-a-dozen. The libraries and ecosystem surrounding a language are what’s important to me. Currently, I’m at a handicap if I try to write Swift on anything but macOS; no Xcode, most third party libraries depend on proprietary Apple SDKs and most of the Swift community just assumes you’re working on a Mac because why wouldn’t you be? So if I’m a Linux user and I’m choosing a language, why choose Swift over other languages like Rust, Go or even modern C++? Don’t get me wrong, I love Swift. It’s an absolute pleasure to work in and my first language of choice for projects targeting Apple platforms. But I’m very skeptical of its long-term potential outside of that ecosystem, especially with Apple’s move toward custom silicon and relying on hardware-level implementations of what would traditionally reside in software. This approach has worked out well for Apple with the rest of their product line and I’m completely on board from an engineering perspective - but it’s a path that will not result in higher cross-platform adoption.
- rahkiin 6y ago
  It could be useful for a backend for a Swift iOS application, so you do not have to switch language and can make a library for the protocol
bllguo 6y ago
swift for tensorflow is dead, and even if it weren't it hardly makes the language compelling for ml. Machine learning != deep learning, and pytorch is in the lead in deep learning anyway. the alternative to python is julia
- FridgeSeal 6y ago
  Every time Swift for Tensorflow gets brought up I am reminded of the disappointment that they didn’t make arguably the smarter choice and do it in Julia

wwright 6y ago

I don't think Swift really competes with Rust or Go at all. - Go aims to be simple enough for many engineers to be productive with little investment. - Rust aims to be extremely reliable and efficient. Swift is very complex, and makes many compromises away from reliability or efficiency in favor of application use cases. Swift may fill an interesting role for a "native C#" that is mostly reliable, mostly efficient, and somewhat productive, but on the other hand, C#, OCaml, Java, Kotlin, and so on already have various answers to that, and they're only becoming better at it. The only real advantage it has (as far as I can tell) is iOS (and TensorFlow almost as a knock-on of being the only serious language for iOS).

usmannk 6y ago
> Rust aims to be extremely reliable and efficient. Fair point, Swift will never be as predictable or efficient as Rust (not a negative perse, just different goals). But I disagree on the complexity re: Go. What about Swift gives you the impression of extreme complexity? Go is definitely comparatively simpler but I do not think it is so much so as to put it in a different league.
- novok 6y ago
  The type errors you start running into with generics with all of their weird limitations in swift can make things complicated fast. That and RxSwift. Also swift as a language doesn't scale well. There are a lot of bottlenecks in the build process that doesn't let you scale simply amongst many cores like you can with C++, Obj-C & C and probably many other languages too. You're also effectively limited to xcode & apple desktops, so you can't go rent out a 100 core build server on AWS for builds like you can for every other platform out there, not that is matters much yet with swift's build scaling issues. Also stuff like basic debugging often just... dies. The more I work with a badly scaling language the more I appreciate a design decision like go made with building fast. I hope with generics in go v2 the boilerplate should reduce a lot.
  - jshier 6y ago
    When was the last time you compiled Swift code? Xcode's new(er) build system has solved many of the scaling issues that affected the previous system, to the point where it scales linearly (on large enough projects) even on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with cmake's native Swift support in 3.18(?), the scaling should be more solved across platform as well. There's certainly nothing in the language itself that prevents scaling builds, only the compiler and build systems. The debugger is still rough, true, but improving. Apple just isn't spending the resources needed to bring lldb up to a great experience in a timely fashion.
    - novok 6y ago
      Yesterday! Swifts build system can split off enough threads to consume all of your CPU cores, and batch mode did improve things, but it's not actually doing so efficiently. There is a trade off between total compute time used and number of threads used. In compute time consumed, swift is the most efficient when it's single threaded in WMO mode, but this means you can only compile in parallel with separate modules that don't depend on each other. And even then it's not a very fast compiling language itself, multithreading issues notwithstanding Maybe something has changed recently, but as far as Xcode 12 goes, I haven't noticed much of a difference. I last checked deeply with swift 4. More details here: https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md https://github.com/apple/swift/blob/master/docs/CompilerPerf...
kitsunesoba 6y ago
I think one of Swift's advantages is its progressive disclosure. It can be written without using any of its more advanced features, making it approachable without limiting possibilities for more advanced users.
- usmannk 6y ago
  I agree. I referenced this (perhaps a bit too implicitly) in a sibling comment. Swift's complexity is there but only when you need it.
- cylon13 6y ago
  Can it be read without knowing about its more advanced features though? Production software is read much more often than it is written.
  - nicoburns 6y ago
    I've been able to dip into Swift codebases with zero previous experience without too much trouble. I do have Rust experience which helps. But never-the-less everyday Swift seemed pretty readable to me.
  - cutler 6y ago
    Swift has some really clunky "features" such as dual-identifier parameters and escaped opening parens as identifiers for string templates. WTF! As if function/method declarations weren't complex enough in a statically-typed language which supports generics.
    - pansa2 6y ago
      > escaped opening parens as identifiers for string templates Do you mean the use of “\(variable)” for string interpolation? What’s wrong with that?
      - cutler 6y ago
        It's just downright clunky. What's wrong with ${variable} as in Kotlin and Javascript?
wffurr 6y ago
Swift has almost seamless interoperability with existing C and C++ libraries and has much stronger safety guarantees than either of those languages. It's not on the same level as Rust, but ARC eliminates entire classes of memory safety issues. The Swift runtime is large-ish, but not outrageously so, and is generally statically compiled-in to the binaries, so there's no dependencies on dynamic libraries. It is, as you say, quite complex, but still an interesting choice IMO.
- dagmx 6y ago
  Minor nitpick but it does not have seamless interfacing with anything other than Objective C. C can be exposed as Objective C, but C++ has to go through C (potential objective C++) first. This is really no different than most other languages. What it does do is provide good auto binding tools however to expose classes and objects bidirectionally to objective C.
  - deleted 6y ago
    [deleted]
  - ladon86 6y ago
    My understanding was that there is no need to involve Objective-C if you’re directly interfacing with C. That interop is direct/seamless, and works on Linux etc. even without Objective-C or Darwin [0]. But the C++ story is what you’ve described above. [0] https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_functions_in_swift https://developer.apple.com/documentation/swift/imported_c_a... and https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift https://developer.apple.com/documentation/swift/imported_c_a...
    - wool_gather 6y ago
      I wouldn't say "seamless". Interacting with C directly from Swift is possible, and fine from a binary perspective, but quite clunky at the source level. (Which obviously is a motivation for the library that is being announced here.) There are still assorted gaps in C imports -- a key example is forward-declared structs, that _all_ arrive in Swift as a _single shared_ `OpaquePointer` type: https://forums.swift.org/t/opaque-pointers-in-swift/6875 https://forums.swift.org/t/opaque-pointers-in-swift/6875
webmobdev 6y ago
Where do you think Ada - a mature and tested language - fit in between these 3 newbies?
- wwright 6y ago
  I don't know Ada well personally, but from what I've read, it's a bit less advanced than Rust at static checks, a good bit simpler than Rust and Swift but more complex than Go, and a little bit old-fashioned in approach (verbose syntax and all that). But I'm not very educated. I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not).
  - pjmlp 6y ago
    Rust lacks the formal specifications from SPARK. And SPARK 2014 will support ownership specifications. Rust is the less advanced one.
    - wwright 6y ago
      Good feedback there :)
  - thesuperbigfrog 6y ago
    >> I don't know Ada well personally >> But I'm not very educated. If you don't know, please don't speculate. I use Ada professionally and I am experimenting with Rust. Rust has great promise and I am interested to see where it will go, especially as an alternative to C++. >> it's a bit less advanced than Rust at static checks Ada 2012 has comparable and in many cases more advanced static checks than Rust with the exception of memory management. This is especially true of the Ada type system (https://learn.adacore.com/courses/intro-to-ada/chapters/strongly_typed_language.html https://learn.adacore.com/courses/intro-to-ada/chapters/stro...) and design by contracts (https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont...). If you use the SPARK subset of Ada, you can use advanced tools to prove the correctness of your program. See https://learn.adacore.com/courses/intro-to-spark/index.html https://learn.adacore.com/courses/intro-to-spark/index.html Rust's borrow checker approach to memory management is novel and SPARK is acutally adding similar concepts to the next version of SPARK (https://blog.adacore.com/using-pointers-in-spark https://blog.adacore.com/using-pointers-in-spark). >> a good bit simpler than Rust and Swift but more complex than Go Ada is a large and fairly complex language because it was designed for hard real-time, safety-critical, embedded systems and it has been in real-world use for 40+ years. I don't think it is that simple, but judging simplicity is subjective: what one person sees as complex, another person might see as simple. You can browse the Ada 2012 Language Reference Manual and see what you think: http://ada-auth.org/standards/12rm/html/RM-TOC.html http://ada-auth.org/standards/12rm/html/RM-TOC.html >> a little bit old-fashioned in approach (verbose syntax and all that). This comes from the Ada design philosophy to be explicit in everything and to prefer the use of keywords over symbols. "Readability is more important than conciseness. Syntactically this shows through the fact that keywords are preferred to symbols, that no keyword is an abbreviation, etc." (See https://learn.adacore.com/courses/intro-to-ada/chapters/introduction.html#philosophy https://learn.adacore.com/courses/intro-to-ada/chapters/intr...) Long-life programs tend to be read more than they are written. The Ada way is to make programs easier to read rather than faster to write. >> I would say that Ada and Rust probably compete on some things, but given the history of Ada in industry, it's probably only in fields that already use Ada (aerospace and what-not). This is largely true. Ada occupies a niche for aerospace and other safety-critical areas, but has not been widely adopted due to the "uncoolness" factor and the cost of most of the available Ada compilers and toolchains. I think the popularity of Rust has peaked some interest in Ada as well, but I am not sure if it will cause any change it where either are used. I would like to see Rust to continue to mature and get adopted for wide-spread use with multiple implementations and a language standard. As it currently stands, many aerospace and safety-critical spaces would not be willing / able to adopt Rust without a language standard and certifications. Here's hoping . . .
coldtea 6y ago
>Swift is very complex, and makes many compromises away from reliability or efficiency in favor of application use cases. Swift is only complex if you need it, otherwise very easy, with few caveats. And it's efficient enough for all application / cli etc use cases -- if Go can do it, Swift can do it even better. It's not Rust in performance and low-levelness, but Rust is the "really complex" one in its semantics and learning curve.
- mjlawson 6y ago
  > if Go can do it, Swift can do it even better. This might be hyperbole, but if not I'd love to see some examples on how Swift can improve on Go's concurrency patterns.
  - coldtea 6y ago
    It might not offer first class support for green threads like Go, but GCD is an even better imho model for 90% of concurrency needs of the average app: https://developer.apple.com/documentation/DISPATCH https://developer.apple.com/documentation/DISPATCH
    - microcolonel 6y ago
      "concurrency needs of the average app" is different from what Go does well with green threads; this seems like something Swift does notably worse, but well enough that it doesn't annoy you in your use case. I feel like this is a different standard from "if Go can do it, Swift can do it better".
    - harikb 6y ago
      Isn’t that just a bridge to an existing OS level feature? Also is GCD green? (As in light weight, co-operative muti-threading)
      - coldtea 6y ago
        >Isn’t that just a bridge to an existing OS level feature? Yes. A feature well designed for this very purpose. >Also is GCD green? GCD tasks are not green threads but they're not direct threads either (even though they're used under the hood). They're more lightweight and much faster to create (than direct OS threads).
throw_m239339 6y ago
> - Go aims to be simple enough for many engineers to be productive with little investment. Go isn't simpler, there is just a defered cost engineers pay later on when it turns out one cannot just do away with complexity by deeming it irrelevant.
- Thaxll 6y ago
  Some FUD right there... What exactly is the deffered cost? Give real examples please.
  - earthboundkid 6y ago
    I love Go, but there is a strong case that Kubernetes has a messy codebase because Go didn’t have good dependency management or generics when they started it. The strength of the ecosystem in other areas let them get started and now they have the tragedy of success, a la Wordpress.
    - studmuffin650 6y ago
      Part of the issues with Kubernetes is that it started as a Java project and then it became a Go project. If anyone started a large Go project with that mindset it would look messy no matter what you did.
      - bad_user 6y ago
        Can you point to any large Go project that isn’t a mess? I agree that from a single sample you can’t reach conclusions, but “it was their fault” isn’t a great defense.
        nix23 6y ago
        Can YOU point to any large project that isn’t a mess?
        6y ago
bilekas 6y ago
I'll tell you: You're wrong, so is OP. Benching languages against eachother is like pitting birds of prey against eachother, its pointless because they will hunt what they hunt. This language/framework dispute I though was fever back in bad PHP days has not changed. I'm not saying; 'oh you kids dont know shit' I'm saying the language is not the problem, the problem is the problem, the right tool for said problem is the answer. You find Swift complex and speak about why, you're not wrong with its application, iOS it does very well, therefore its a tool for an iOS job. If I grew up just learning Swift and nothin else, I would say swift is the best . Plato's cave springs to mind. We are all Engineers, Developers, Hackers, Designers and or Code Monkeys.. Don't try to pit against, know the right tool for the job, if you cant find it, make it. With people who can. I though thats how we roll
- wwright 6y ago
  To be clear, that’s kind of what I was trying to say :) maybe the “only advantage” part at the end made that unclear. I think the problems you’d want to use Go for, the problems you’d want to use Rust for, and the problems you’d want to use Swift for are largely non-overlapping (in spite of whatever similarities they do have).
jillesvangurp 6y ago
I think you are focusing on a bit artificial things here with things like intentions and other biases and notions. Swift is a statically compiled, C like language, that can be used for system programming. Just like C, C++, Rust, Go, etc. This is not an accident. It was built from the ground up to do that. The goal with this OSS library is literally making swift easier to use in projects where you'd otherwise reach for exactly those languages. So, whether you like it or not, it's competing (or at least trying to) in that space (i.e. system programming). Actually, Swift was designed to replace Objective C, which of course was the system programming language that Apple standardized on as an alternative to C decades ago. It's designed from the ground up to be a drop in replacement in any project where you'd previously be using that. So, it's a natural fit for any kind of project where you'd otherwise be considering things like Rust, C++, Go, C, etc. Whether that makes sense or not in your context is of course up for debate and highly subjective.

dmitriid 6y ago

I will gather a lot of downvotes, but still: I find Swift a very haphazardly designed language with very little foresight and forethought. This is further compounded by its standard libraries which are directly lifted from MacOS with all of their idiosyncrasies and huge incompatible changes from version to version. For what it's worth, [1] [2] [3] [4] [1] A type system that can't cope with SwiftUI: https://tonsky.me/blog/swiftui/ https://tonsky.me/blog/swiftui/ [2] More syntax to shake a stick at https://twitter.com/dmitriid/status/1276482336486576133 https://twitter.com/dmitriid/status/1276482336486576133 [3] Even more syntax weirdness https://twitter.com/bradfitz/status/1285302091544576000 https://twitter.com/bradfitz/status/1285302091544576000 [4] Standard library between versions: https://twitter.com/dmitriid/status/1201441652507844608 https://twitter.com/dmitriid/status/1201441652507844608 File manipulation functions on String, great design.

valuearb 6y ago
So you ding the language because of a suboptimal choice made by one tool for it? The good and bad of Swift is the regular breaking updates. Sure it’s a pain when things change, but it’s also healthy when they improve, and almost every change has been an improvement. A language as simple as C can slowly grow without breaking existing source code. But it’s also never been able to address its most significant flaws.
- dmitriid 6y ago
  > So you ding the language because of a suboptimal choice made by one tool for it? I provided 4 different links showing multiple different features in the language I find suboptimal. > Sure it’s a pain when things change, but it’s also healthy when they improve, and almost every change has been an improvement. It's a very dubious statement at the very least. > But it’s also never been able to address its most significant flaws. Can Swift address its flaws even with its breaking changes? So far its been piling on more and more syntax, and continuously breaking its standard library (whose design choices like writing to files from Strings are very dubious)?
deleted 6y ago
[deleted]

untog 6y ago

IMO (as someone who has written plenty of Swift and Rust) Rust is in category of its own here. It's a fantastic language and I love working with it... but it has a mental overhead in dealing with ownership, borrow checking etc that other languages don't. It's amazing in situations where performance is critical, or where you have constrained resources. But I'd much rather use Swift in other situations.

adamnemecek 6y ago

I used to be a bit of a Swift fan boy, but then I switched to Rust (I was a Rust fanboy for even longer but thought that Swift was better for my use case which is a native macos app). I have not looked back. The Swift ecosystem is mostly people wrapping Apple APIs. God help you if you want to have a swift package with some metal code in it. Rust cargo manages this without a hiccup. Swift is nice as long as daddy Apple had your use case in mind, God forbid you have to tweak something. Rust feels more "timeless". Swift for TF is dead.

rhodysurf 6y ago
For a while I was looking aggressively at using swift everywhere, but then I tried rust and read this https://v4.chriskrycho.com/rust-and-swift.html https://v4.chriskrycho.com/rust-and-swift.html and gained a new respect for Rust and have been using it whenever I can since.
- valuearb 6y ago
  Boy that is really old. And oppressively detailed. And ends up sounding like a Coke vs Pepsi argument. Do I really care about the minutia of minor features when I can build the same things with both tools? For server side I’m probably going to use Rust, for MacOS or iOS I’m certainly using Swift, for Android I choose Kotlin, and for Windows I would choose suicide.
  - rhodysurf 6y ago
    It definitely is old, but a lot of the points still stand with respect to swift syntax. Anyway I was trying to use swift for things outside of iOS work to share code and it wasnt worth it, is what I'm really getting at. So agreed on your whole second sentence haha
  - adamnemecek 6y ago
    I'm using rust and metal on macos and it's pretty nice. I'll switch to wgpu eventually, it's similar enough to metal.
  - 6y ago

StreamBright 6y ago

What is the unique value set that it brings to the table?

marta_morena_29 6y ago

Why would you mention Swift, Go and Rust in the same context? I mean Swift vs. Go kinda has some merit, although they have completely different intentions. At least Go doesn't aspire to be a systems programming language. Rust definitely has no place in this comparison. Rust serves a niche market of systems programming that is so security focused that C/C++ just won't do. It's not useful for anything else (at least not anymore than Haskell is useful for anything besides university projects, in the real world at least). Swift has many nice similarities with Rust and other current languages from a pure syntactical/language perspective, while aiming to be a GP language. It definitely serves a broader audience than Go, whose main target is server programming. Swift's main target is Apple UI programming, however, the language is capable of so much more. Which is why Open Source is good news. It may make it escape its Apple box.

rkrzr 6y ago
Why the cheap swipe at Haskell? We use Haskell very productively in the real world. You can take a look at some of our blog posts here, if you want to learn more: https://tech.channable.com/ https://tech.channable.com/ Here is one post about writing an Aho-Corasick implementation in Haskell which is as fast as the fastest Rust implementation: https://tech.channable.com/posts/2019-03-13-how-we-made-haskell-search-strings-as-fast-as-rust.html https://tech.channable.com/posts/2019-03-13-how-we-made-hask...
oaiey 6y ago
Harsh words. I agree with the statement, but Rust is used not only for system programming and Haskell has its niche beyond university. I think Swift is where .NET was in its first decade. While capable of so much more, it is limited by its designers and primary purpose so it cannot go beyond. The tight coupling to UI products is a burden an ecosystem carries. Java won in the backend not with is UI, JavaScript with node/npm before Angular reset the frontend and C# just when .NET Core pushed it into spaces it has not been before (apis, lambdas, etc).
jtsiskin 6y ago
What do you mean by "so security focused that C/C++ just won't do"? Anything on the internet should be cautious of memory unsafety issues. Something like an image processing library I won't consider 'security focused' yet I would trust one written in Rust over one written in C.

amelius 6y ago

> but Swift for Tensorflow[0] is exciting and could become a refreshing alternative to python for machine learning I prefer the landscape for ML not to be fragmented based on non-essential qualities like the language that is used. How great is it that researchers publish code in the same language, and everybody can use that code immediately without having to learn language X and/or porting the implementation?

skohan 6y ago
My problem with Python is that once you start working with a strongly-typed language, a duck-typed interpreted language starts to feel like it's missing a major tool in terms of writing correct code. I also think S4TF's approach has been really neat here: there's a really nice python interop so you still have access to the entire body of work and tools in python available, and it basically feels like writing native swift code.
- formerly_proven 6y ago
  > My problem with Python is that once you start working with a strongly-typed language, a duck-typed interpreted language starts to feel like it's missing a major tool in terms of writing correct code. I primarily write C++ and Python and never feel like this.
  - skohan 6y ago
    Not all type systems are created equal. Swift's is powerful and expressive
    - amelius 6y ago
      You could at least explain what features set it apart, in your opinion, from other type systems and why they are important in this case ...
      - skohan 6y ago

supernintendo 6y ago

How many active Linux projects are still written in Objective C? Personally, I see no compelling reason to use Swift on Linux. Programming languages are dime-a-dozen. The libraries and ecosystem surrounding a language are what’s important to me. Currently, I’m at a handicap if I try to write Swift on anything but macOS; no Xcode, most third party libraries depend on proprietary Apple SDKs and most of the Swift community just assumes you’re working on a Mac because why wouldn’t you be? So if I’m a Linux user and I’m choosing a language, why choose Swift over other languages like Rust, Go or even modern C++? Don’t get me wrong, I love Swift. It’s an absolute pleasure to work in and my first language of choice for projects targeting Apple platforms. But I’m very skeptical of its long-term potential outside of that ecosystem, especially with Apple’s move toward custom silicon and relying on hardware-level implementations of what would traditionally reside in software. This approach has worked out well for Apple with the rest of their product line and I’m completely on board from an engineering perspective - but it’s a path that will not result in higher cross-platform adoption.

rahkiin 6y ago
It could be useful for a backend for a Swift iOS application, so you do not have to switch language and can make a library for the protocol

bllguo 6y ago

swift for tensorflow is dead, and even if it weren't it hardly makes the language compelling for ml. Machine learning != deep learning, and pytorch is in the lead in deep learning anyway. the alternative to python is julia

FridgeSeal 6y ago
Every time Swift for Tensorflow gets brought up I am reminded of the disappointment that they didn’t make arguably the smarter choice and do it in Julia