from Hacker News

Why Swift for TensorFlow?

by nnd on 2/10/19, 7:58 PM with 143 comments

  • by 3jckd on 2/10/19, 9:52 PM

    It's interesting how it's going to play out. On one hand side, Swift is a pleasant language to work with (despite its infancy). But on the other, having a Tensorflow API doesn't suddenly give it a bunch of libraries for statistics, comp. vision, modeling, visualisation, etc. that Python/R/Julia coughMATLABcough have.

    Nowadays, it's difficult enough to convince people to drop e.g. MATLAB for R or Python for Julia (let's assume that there's some merit to it), despite them having excellent counterparts for almost everything. Swift's success in this domain depends solely on the adoption by developers/researchers/engineers. Unless they're just going to mostly use it internally (as Google is known to).

    Which brings me to the last point - why on Earth would they pick Swift (apart from Christ Lattner being involved) when Julia was on the table? It ticks all their boxes and has more mature ecosystem for all things "data". Provided rationale is hardly convincing.

  • by elpakal on 2/10/19, 8:50 PM

    I also wonder how much of this coincidentally lines up with Chris Lattner landing at Google. As Chris will admit, and as was left out of this analysis, Swift has also been given the humble goal of achieving world domination. All joking aside I'm very thrilled about this and have enjoyed tremendously watching the Swift language mature since its launch due in large part to the open source community and the Swift team's admirable commitment. Onward!

  • by tanilama on 2/11/19, 1:10 AM

    Fail to see the point of this project.

    Swift for Tensorflow might work if the scope is to create a client side model definition loader natively for various TF models.

    Nobody use Swift seriously for server side training, there is no point in doing so except to add swift to the list of language that claim to do deep learning but in reality nobody will consider them.

  • by kodablah on 2/10/19, 10:14 PM

    Strange to see a requirement for choosing one language over another is supposed ease of adoption and then they choose the one not easily adopted across every platform. That easy to write syntax takes precedence over general easy to write/run is unfortunate.

  • by igotsideas on 2/10/19, 9:13 PM

    Well written explanation! I really enjoy Swift but it's not as accessible as some of the other languages mentioned. I have a 2011 Macbook Pro and wanted to use the latest and greatest new Swift features. Unfortunately, my machine is too old to upgrade to Mojave which means I can't download the latest version of xcode, which means no new version of Swift. I'm not mad at Apple in the least bit. I just wish I could use Swift 4 on my machine.

  • by byt143 on 2/10/19, 11:22 PM

    Julia would have been a much better and more cost effective choice in my opinion.

    It's a superior platform to on which develop this sort of thing, and further along at that. Also easier to use.

  • by m0zg on 2/10/19, 9:13 PM

    Is there a "standard" way of running Swift on Ubuntu LTS nowadays? A while back I looked into it, and ran into some hokey and unsatisfying solutions. I used Swift on iOS, and I like it a lot, but if they care about adoption, someone needs to reduce friction of getting up and running to approximately zero. A snap package a-la Go or per-user script based installation a-la Rust would be quite OK, as long as it's just one, easy to discover command.

  • by gthippo on 2/10/19, 9:15 PM

    Swift is also now supported in Colab (Google-hosted Jupyter notebooks) and there's a nice tutorial on some of the features of Swift for Tensorflow at https://colab.research.google.com/github/tensorflow/swift-tu...

  • by sjwright on 2/10/19, 8:54 PM

    I have no idea what TensorFlow is (other than the basics) but I enjoyed reading that entire document because it did such a wonderful job of explaining a complex and potentially contentious decision. It’s fascinating to see Swift feature so strongly in a pragmatic analysis that doesn’t explicitly favour Apple platform interop.

  • by tylerwhipple on 2/11/19, 2:58 AM

    I am surprised Dart is not mentioned at all (maybe implied under the OOP languages?). While Flutter and Tensorflow are very different usecases, I am surprised there is nothing in the document on why Dart specifically would be a good choice. I believe if they used Dart for Tensorflow as well, the community would be able to get behind the idea that will not be an abandoned language.

  • by mamcx on 2/11/19, 12:24 AM

    I vaguely know tensor flow as the most(?) popular lib of his kind, but I wonder how is the history of swift on non-apple platforms and its impact of the actual users.

    Is TensorFlow "huge" in linux, windows, android? Because I also evaluate swift for my use case (https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif...) and decide instead on use rust mainly because the lack of solid support on non-apple platforms. However, after use rust for months now I still consider swift a better contender between performance/ergonomics than rust (rust is damm hard sometimes, and suddenly you could hit a trouble with above-average complications. I don't see how put this burden in a library to be used for more "regular" folks could work)

  • by solidsnack9000 on 2/11/19, 2:42 AM

    Setting aside for a moment the appropriateness of Swift for TensorFlow, this is a very impressive example of using an embedded DSL to work with a component that is a full programming system in its own right.

    On the one hand, we do want full access to the programming model exposed by the component -- its control structures, abstractions, everything else. One the other hand, these are mostly duplicated by our host programming language: it's going to have variable bindings, operators, iteration, conditionals and everything else. Doing an embedding like this is a way to expose most of the component's facilities without introducing a ton of "new syntax" in the form of combinators or having programs where a lot of the critical code is escaped in strings.

    This same problem shows up in programming interfaces to RDBMSes. LINQ is a good example of the same embedding technique.

  • by victor106 on 2/10/19, 9:57 PM

    You might agree/disagree with their decision but this is one of the most honest and comprehensive evaluation for using a language I've read.

  • by skwb on 2/10/19, 9:49 PM

    Forgive me for my ignorance, but does swift have any good plotting and interactive "notebook" ability? Specifically the ability to plot images such as matplotlib.

    I ask this because the number 1 reason my deep learning research group chose python was because of the extensive and interactive scientific plotting ability that's built into python jupyter notebooks. While our volume of analysis isn't on the scale of say a google/fb (primarily biomedical image analysis), the ability to easily visually debug the results is much more important for developing robust models.

  • by moocowtruck on 2/11/19, 2:01 AM

    why? because i made the language, thats why...no real good reason

  • by lovasoa on 2/11/19, 4:23 PM

    Reading the document really gives a feeling the author is not being honest on why they chose Swift.

    The lack of windows support is addressed in just two lines. Julia being an already established language in the domain of data science does not seem to be especially important to them.

    I think the most honest part of the document is:

    > because we were more familiar with its [Swift's] internal implementation details

  • by sometimesijust on 2/11/19, 11:48 AM

  • by mikkelam on 2/11/19, 3:44 PM

    As as python machine learning practitioner and previous iOS engineer I have for while come to miss using swift and type safety for that matter. I really like the language and wish great success for the TF team with swift.

    Side note, does anyone know the effort required to get various python based libraries running on swift? i.e. numpy, scipy, pandas and so on?

  • by adamnemecek on 2/10/19, 8:46 PM

    I can imagine swift really taking off in this space. It’s going to be a battle between Julia and Swift for who does the best automatic differentiation.

  • by midgetjones on 2/11/19, 12:22 PM

    I wonder what this means for iOS apps themselves

  • by masha_sb on 2/11/19, 7:27 AM

    I'll wait for the PyTorch version.

  • by ramoz on 2/11/19, 12:19 PM

    Is there an official release roadmap?

  • by xiaodai on 2/11/19, 8:12 AM

    Haven't we seen this before?

  • by hooloovoo_zoo on 2/10/19, 9:37 PM

  • by aaaaaaaaaaab on 2/10/19, 9:33 PM

    Why not Rust?

    Edit: I wonder if Swift could be replaced with Rust for iOS development?

  • by 5stospace on 2/11/19, 12:39 AM

    I still don't understand why they would choose Swift over C#?

    They complain about C#/Java having "highly dynamic constructs" but correct me if I'm wrong but isn't swift also a GC/OOP like Java and C#?

    I don't think Swift has any inherent objective advantages over c#.

    I think it would have been a better decision to go with C# over Swift as Microsoft has a clear roadmap with the language and it is already supported on linux/mac/windows.