4 ms·

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 ou

by 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.

by wenc 8y ago

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.