8 ms·

@50m in they discuss the problems of using Swift on non-iOS platforms. How far is Swift from being a good cross-platform language?

saagarjha 8y ago
It’s not great, but it’s not bad in Linux. In other platforms it’s going to be a pain.
- wenc 8y ago
  It is curious to me that Swift was chosen as a target language for Tensorflow [1]. It sounds like a really well-designed language but has almost no community outside the iOS platform. [1] https://www.tensorflow.org/swift https://www.tensorflow.org/swift
  - favorited 8y ago
    There's a pretty solid overview of the decision making process (including pros and cons compared to other options) here: https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
    - wenc 8y ago
      Yes there was an HN discussion on it a few days ago, and this was the final justification: "In the end, we narrowed the list based on technical merits down to Swift, Rust, C++, and potentially Julia. We next excluded C++ and Rust due to usability concerns, and picked Swift over Julia because Swift has a much larger community, is syntactically closer to Python, and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster." However, the Swift community is larger only because it is used on iOS for non-numerical computation applications completely unrelated to Tensorflow. If we draw the lines of community around people who are in Tensorflow-related fields (i.e. numerical computation), I suspect the size of the Julia community is actually larger than Swift's. I've been a Pythonista for a decade and a half, but in this case, Julia seems to me to be the more logical pick, given that it is designed for numerical computation (it is the modern successor to Fortran). Julia is syntactically closer to Matlab, which is a language familiar to many grad students, a pool from which many future Tensorflow users are mined. The last point is valid though. Still, as someone with a numerical computation background, Swift remains a curious choice.
      - skohan 8y ago
        > I've been a Pythonista for a decade and a half, but in this case, Julia seems to me to be the more logical pick, given that it is designed for numerical computation (it is the modern successor to Fortran). Julia is syntactically closer to Matlab, which is a language familiar to many grad students, a pool from which many future Tensorflow users are mined. It's an interesting point, but it reminds me of the reasoning Ryan Dahl used to choose Javascript as the language for Node.js: JS had a massive community, and everyone doing web development should have some familiarity with it, so it seemed like a natural choice for that domain. However while it might have aided adoption, the weaknesses of Javascript as a language are undoubtedly the worst part of what is otherwise a useful and well-implemented server-side framework. I'm not very familiar with Julia, but my impression of Matlab from university is that it was a pragmatic tool which was useful in its domain because of library support, but not that it was a well-designed language that I wish I could use everywhere. If Julia has aped Matlab's conventions because they are familiar to the community, I would worry that it may have also learned from Matlab's bad habits. I would be more trusting of the software engineering community to produce tools which are optimized for usability and creating robust software.
        wenc 8y ago
        I don't think Julia has aped Matlab's conventions as such [1]. There are languages that have done this (Scilab, Octave) but those were developed as Matlab clones. Julia isn't a Matlab clone. No, it's more like Julia has taken "Matlab: The Good Parts" as well as practices from modern languages and created a new language with them that is morphologically familiar to Matlab users, yet is an entirely new design. [1] Except for 1-indexing, but that was a carryover from Fortran, which in turn adopted it from linear algebra convention and it seriously isn't that bad. I wrote production Matlab for 12-years and 1-indexing was the least of my troubles. It's a theoretical polarizing issue like Python's use of whitespace, but in practice it's not an issue.
        renox 8y ago
        > It's a theoretical polarizing issue like Python's use of whitespace, but in practice it's not an issue. I think that it really depends on the use case, if you're using only Julia it won't be an issue, if you use Lua as an extension languages of C++ and you have to work on both side at the same time like I had to do.. Well, let's just say that I wasn't exactly having nice thoughts towards Lua creators ..
    - curyous 8y ago
      I wouldn't call it solid. On first glance it seems like someone trying to backwards-rationalize an emotional decision.
      - favorited 8y ago
        It makes sense to me... They wanted to solve issues that come from Python, and lots of languages were no-go. They were left with Swift, Rust, or C++. The determination was that C++ and Rust have unacceptable learning curves, so they went with Swift.
  - skohan 8y ago
    > almost no community outside the iOS platform. I would not say that's exactly true. There are a number of projects shipping server-side swift, and there is some nice tooling for using Swift where you might otherwise use a scripting language. Personally I reach for it more and more for projects outside of mobile, and find that the non-iOS ecosystem has grown to feel very functional in the past couple years. iOS is undoubtedly still the main use-case for Swift, but plenty of people are using it for other things.
    - pjmlp 8y ago
      Those Swift server side projects, while nice, aren't something that matches up against Spring, JEE, ASP.NET, Yesod, Play, DropWizard, Actix, Revel,.... IBM helps with Kitura, but I am yet to see some real project worthy of news headlines deployed with Kitura.
      - skohan 8y ago
        To be fair, it's still relatively early days. If your test for whether a new technology is useful in a domain is that there is already a large, headline-making example use-case that exists, you will never adopt a new technology because someone has to be the first mover. The point is it is possible to deploy serious server-side software written in Swift, and people are already doing it. It's inaccurate to say that Swift is only useful for iOS projects. It remains to be seen whether Swift will find wide adoption, and a lot of that hinges on tooling support which needs a lot of work outside Apple platforms, but I think there is also too much of a tendency in the Software community to under-estimate Swift's potential usefulness as a general-purpose language because of its origins in iOS. I see that frequently in the tepid reaction to Swift for TensorFlow.
        pjmlp 8y ago
        > The point is it is possible to deploy serious server-side software written in Swift, and people are already doing it. Examples that you would care to share with us? Really serious examples, not the typical blogs and ToDo's done with Kitura I have seen at some conferences. For me, Tensorflow would be better served with Julia, given the target demographics. However if it helps Swift ever to be usable on Windows, then more the better.
iceninenines 8y ago
I would look at something elss besides Swift in such scenarios like Kotlin or Crystal.
cageface 8y ago
IMO the choice of reference counting for memory management means Swift is going to lose out to garbage collected languages for most problem domains. It makes sense for UIKit but not for most backend work.
- skohan 8y ago
  What would you say is the problem with Reference Counting for back-end work? Maybe it's because I come from a C/C++ background, but declaring a few weak references here and there never felt like much of a hindrance to me.
  - MaxBarraclough 8y ago
    On the flipside though: * You're always thinking of whether you might need to use weak refs, right? That's a cognitive load that you would otherwise be spared. * What are the consequences when you get it wrong? * How probable is a mistake, particularly when working with a large complex codebase that you didn't create, and don't fully understand? * How probable is it that you might fail to detect a mistake, for a long time?
- vlozko 8y ago
  Could you, at least, provide something to substantiate your opinion? There's ups and downs to both approaches. But you should note that reference counting, for the most part, is handled for you at compile time.
  - cageface 8y ago
    My iOS code is loaded with manual weak ref handling. It’s easy to get wrong. It’s an extra cognitive load and source of bugs. I’d say on pretty much every iOS project I’ve been on there’s been at least one client visible bug caused by forgetting to use a weak ref somewhere.
pjmlp 8y ago
As much as Objective-C gets used outside Apple platforms, in spite of 20+ years of support on GCC. There is some support on GNU/Linux, almost non-existant in other platforms. However what makes a programming language is not only syntax and semantics, but libraries, IDE, tooling in general, and those are pretty much only available on Apple platforms. There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift.
- skohan 8y ago
  > As much as Objective-C gets used outside Apple platforms, in spite of 20+ years of support on GCC. Swift is already more widely used than Objective-C outside of Apple platforms. The main difference is that the Objective-C runtime (which is required to make Objective-C useful in any meaningful way) is closed-source and not available on non-apple platforms. The Swift runtime is available and officially supported on Ubuntu. > There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift. Most of those examples are proprietary frameworks for interfacing with the Apple platforms directly. Most major platforms include proprietary frameworks, and their existence as value-adds on that platform don't speak to a detriment of the language as a whole. Your statement is like saying C++ is not useful outside of Windows because there is no DirectX. There is already a large body of open source libraries for Swift for a variety of tasks, and moreover Swift's excellent C interoperability makes it very reasonable to make serious platform-agnostic software with Swift.
  - mulle_nat 8y ago
    The Apple Objective-C runtime is right there on Apple Opensource https://opensource.apple.com/source/objc4/objc4-750.1/ https://opensource.apple.com/source/objc4/objc4-750.1/
    - skohan 8y ago
      If it is now, that has not always been the case. Also I invite you to build and link the runtime on a non-apple platform and compare that experience to building a working binary with the Swift Package Manager.
chriseidhof 8y ago
We wrote the Swift Talk backend in it. It’s mostly fine, but some parts are still buggy on Linux. For us, there were two or three bugs that took a few hours each (over the course of a few months of development). Apart from that, I loved Swift on the server: it’s the language I know, so it makes things really fast to build for me. The performance is amazing (both in terms of execution time as well as memory usage).

saagarjha 8y ago

It’s not great, but it’s not bad in Linux. In other platforms it’s going to be a pain.

wenc 8y ago
It is curious to me that Swift was chosen as a target language for Tensorflow [1]. It sounds like a really well-designed language but has almost no community outside the iOS platform. [1] https://www.tensorflow.org/swift https://www.tensorflow.org/swift
- favorited 8y ago
  There's a pretty solid overview of the decision making process (including pros and cons compared to other options) here: https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
  - wenc 8y ago
    Yes there was an HN discussion on it a few days ago, and this was the final justification: "In the end, we narrowed the list based on technical merits down to Swift, Rust, C++, and potentially Julia. We next excluded C++ and Rust due to usability concerns, and picked Swift over Julia because Swift has a much larger community, is syntactically closer to Python, and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster." However, the Swift community is larger only because it is used on iOS for non-numerical computation applications completely unrelated to Tensorflow. If we draw the lines of community around people who are in Tensorflow-related fields (i.e. numerical computation), I suspect the size of the Julia community is actually larger than Swift's. I've been a Pythonista for a decade and a half, but in this case, Julia seems to me to be the more logical pick, given that it is designed for numerical computation (it is the modern successor to Fortran). Julia is syntactically closer to Matlab, which is a language familiar to many grad students, a pool from which many future Tensorflow users are mined. The last point is valid though. Still, as someone with a numerical computation background, Swift remains a curious choice.
    - skohan 8y ago
      > I've been a Pythonista for a decade and a half, but in this case, Julia seems to me to be the more logical pick, given that it is designed for numerical computation (it is the modern successor to Fortran). Julia is syntactically closer to Matlab, which is a language familiar to many grad students, a pool from which many future Tensorflow users are mined. It's an interesting point, but it reminds me of the reasoning Ryan Dahl used to choose Javascript as the language for Node.js: JS had a massive community, and everyone doing web development should have some familiarity with it, so it seemed like a natural choice for that domain. However while it might have aided adoption, the weaknesses of Javascript as a language are undoubtedly the worst part of what is otherwise a useful and well-implemented server-side framework. I'm not very familiar with Julia, but my impression of Matlab from university is that it was a pragmatic tool which was useful in its domain because of library support, but not that it was a well-designed language that I wish I could use everywhere. If Julia has aped Matlab's conventions because they are familiar to the community, I would worry that it may have also learned from Matlab's bad habits. I would be more trusting of the software engineering community to produce tools which are optimized for usability and creating robust software.
      - wenc 8y ago
        I don't think Julia has aped Matlab's conventions as such [1]. There are languages that have done this (Scilab, Octave) but those were developed as Matlab clones. Julia isn't a Matlab clone. No, it's more like Julia has taken "Matlab: The Good Parts" as well as practices from modern languages and created a new language with them that is morphologically familiar to Matlab users, yet is an entirely new design. [1] Except for 1-indexing, but that was a carryover from Fortran, which in turn adopted it from linear algebra convention and it seriously isn't that bad. I wrote production Matlab for 12-years and 1-indexing was the least of my troubles. It's a theoretical polarizing issue like Python's use of whitespace, but in practice it's not an issue.
        renox 8y ago
        > It's a theoretical polarizing issue like Python's use of whitespace, but in practice it's not an issue. I think that it really depends on the use case, if you're using only Julia it won't be an issue, if you use Lua as an extension languages of C++ and you have to work on both side at the same time like I had to do.. Well, let's just say that I wasn't exactly having nice thoughts towards Lua creators ..
  - curyous 8y ago
    I wouldn't call it solid. On first glance it seems like someone trying to backwards-rationalize an emotional decision.
    - favorited 8y ago
      It makes sense to me... They wanted to solve issues that come from Python, and lots of languages were no-go. They were left with Swift, Rust, or C++. The determination was that C++ and Rust have unacceptable learning curves, so they went with Swift.
- skohan 8y ago
  > almost no community outside the iOS platform. I would not say that's exactly true. There are a number of projects shipping server-side swift, and there is some nice tooling for using Swift where you might otherwise use a scripting language. Personally I reach for it more and more for projects outside of mobile, and find that the non-iOS ecosystem has grown to feel very functional in the past couple years. iOS is undoubtedly still the main use-case for Swift, but plenty of people are using it for other things.
  - pjmlp 8y ago
    Those Swift server side projects, while nice, aren't something that matches up against Spring, JEE, ASP.NET, Yesod, Play, DropWizard, Actix, Revel,.... IBM helps with Kitura, but I am yet to see some real project worthy of news headlines deployed with Kitura.
    - skohan 8y ago
      To be fair, it's still relatively early days. If your test for whether a new technology is useful in a domain is that there is already a large, headline-making example use-case that exists, you will never adopt a new technology because someone has to be the first mover. The point is it is possible to deploy serious server-side software written in Swift, and people are already doing it. It's inaccurate to say that Swift is only useful for iOS projects. It remains to be seen whether Swift will find wide adoption, and a lot of that hinges on tooling support which needs a lot of work outside Apple platforms, but I think there is also too much of a tendency in the Software community to under-estimate Swift's potential usefulness as a general-purpose language because of its origins in iOS. I see that frequently in the tepid reaction to Swift for TensorFlow.
      - pjmlp 8y ago
        > The point is it is possible to deploy serious server-side software written in Swift, and people are already doing it. Examples that you would care to share with us? Really serious examples, not the typical blogs and ToDo's done with Kitura I have seen at some conferences. For me, Tensorflow would be better served with Julia, given the target demographics. However if it helps Swift ever to be usable on Windows, then more the better.

iceninenines 8y ago

I would look at something elss besides Swift in such scenarios like Kotlin or Crystal.

cageface 8y ago

IMO the choice of reference counting for memory management means Swift is going to lose out to garbage collected languages for most problem domains. It makes sense for UIKit but not for most backend work.

skohan 8y ago
What would you say is the problem with Reference Counting for back-end work? Maybe it's because I come from a C/C++ background, but declaring a few weak references here and there never felt like much of a hindrance to me.
- MaxBarraclough 8y ago
  On the flipside though: * You're always thinking of whether you might need to use weak refs, right? That's a cognitive load that you would otherwise be spared. * What are the consequences when you get it wrong? * How probable is a mistake, particularly when working with a large complex codebase that you didn't create, and don't fully understand? * How probable is it that you might fail to detect a mistake, for a long time?
vlozko 8y ago
Could you, at least, provide something to substantiate your opinion? There's ups and downs to both approaches. But you should note that reference counting, for the most part, is handled for you at compile time.
- cageface 8y ago
  My iOS code is loaded with manual weak ref handling. It’s easy to get wrong. It’s an extra cognitive load and source of bugs. I’d say on pretty much every iOS project I’ve been on there’s been at least one client visible bug caused by forgetting to use a weak ref somewhere.

pjmlp 8y ago

As much as Objective-C gets used outside Apple platforms, in spite of 20+ years of support on GCC. There is some support on GNU/Linux, almost non-existant in other platforms. However what makes a programming language is not only syntax and semantics, but libraries, IDE, tooling in general, and those are pretty much only available on Apple platforms. There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift.

skohan 8y ago
> As much as Objective-C gets used outside Apple platforms, in spite of 20+ years of support on GCC. Swift is already more widely used than Objective-C outside of Apple platforms. The main difference is that the Objective-C runtime (which is required to make Objective-C useful in any meaningful way) is closed-source and not available on non-apple platforms. The Swift runtime is available and officially supported on Ubuntu. > There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift. Most of those examples are proprietary frameworks for interfacing with the Apple platforms directly. Most major platforms include proprietary frameworks, and their existence as value-adds on that platform don't speak to a detriment of the language as a whole. Your statement is like saying C++ is not useful outside of Windows because there is no DirectX. There is already a large body of open source libraries for Swift for a variety of tasks, and moreover Swift's excellent C interoperability makes it very reasonable to make serious platform-agnostic software with Swift.
- mulle_nat 8y ago
  The Apple Objective-C runtime is right there on Apple Opensource https://opensource.apple.com/source/objc4/objc4-750.1/ https://opensource.apple.com/source/objc4/objc4-750.1/
  - skohan 8y ago
    If it is now, that has not always been the case. Also I invite you to build and link the runtime on a non-apple platform and compare that experience to building a working binary with the Swift Package Manager.

chriseidhof 8y ago

We wrote the Swift Talk backend in it. It’s mostly fine, but some parts are still buggy on Linux. For us, there were two or three bugs that took a few hours each (over the course of a few months of development). Apart from that, I loved Swift on the server: it’s the language I know, so it makes things really fast to build for me. The performance is amazing (both in terms of execution time as well as memory usage).