4 ms·

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/blo

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 ..
      - skohan 8y ago
        Yeah that is my worry reading that: interoperability is going to be a headache.
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.

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 ..
    - skohan 8y ago
      Yeah that is my worry reading that: interoperability is going to be a headache.

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.