@clattner What are your thoughts to Jeremy’s explorations and reflections on swift? Taken from the warts section.
I cherry picked and summarized a few that I felt are important for a noob like me. Please read that actual blog post since I am not doing justice by distilling it.
Installation of Swift is a mess. Mac’s Swift is tied to Xcode version in a confusing and awkward way and different version require different installers. Works on Linux but only Ubuntu.
Swift Package Manager (SPM) is not good as conda. Users requires to manage prerequisites, doesn’t let you describe how to build the packages, dependencies is handled awkwardly, and any features like conda is probably not in SPM.
Swift community teaches you bad habits? because most solutions will be done in the style of Objective-C or advice on how to get Xcode to do things for you, rather than writing the code yourself
Swift can’t interface with C++ at all while many of the most useful numeric libraries today are written in C++ (I believe Chris mention that Google? will be converting a lot of packages to swift and is gonna post tutorial on how to do this) But there are a lot of packages.
Note: over the course of this week, Colab will be updated to Swift for TensorFlow v0.3, and we will update the notebooks at that time.
Last time I checked, it wasn’t possible to choose Swift in Colab drop down menu, the only way to get it in Colab was to clone an existing Swift Colab notebook. Is that going to be fixed?
Great question! This is something we will fix soon.
I’m curious, how many people are working full time on S4TF at Google right now?
We have about 8 people on my team, but there are a number of very close friends across Alphabet.
A follow-up question from Jeremy’s comments at the end of last class:
Why has fast.ai chosen Swift over Julia??
Here is the
blog post Jeremy is mentioning.
i get the impression v4 of the course (or 2020 version) will be in Swift 4 TF…
How long will fastai support PyTorch?
google needs it … its says all … so Swift is the way forward
There is no short term plan to discontinue support for PyTorch. The idea is to have fastai sitting on different languages.
Google have a long write up on why they chose it:
This file has been truncated.
# Why *Swift* for TensorFlow?
* Date: April 2018
The core [graph program extraction algorithm](GraphProgramExtraction.md), [automatic differentiation](AutomaticDifferentiation.md), and [Python language interoperability](PythonInteroperability.md) features of Swift for TensorFlow can be implemented for other programming languages, and we are occasionally asked why we didn’t use some other one for this project.
The engineers on the project were previously familiar with Swift (and several other languages), but the choice was guided by the goals of our project, which imposed specific technical requirements (explained below). This choice was also discussed extensively, debated with coworkers and other interested engineers, and we concluded that Swift was the best direction. In this document we're sharing our deliberation process with the community to help explain our decisions.
That said, while our choice of language was guided by our specific project goals, we would love to see wider application of these techniques and ideas in the context of other programming languages! If you are interested in pursuing a similar project, please reach out to us and we will happily share our expertise.
### How we got here
As discussed in the [design overview document](DesignOverview.md) our project goal is to improve usability of TensorFlow. We quickly realized that our core [static analysis-based Graph Program Extraction algorithm](GraphProgramExtraction.md) would not work well for Python given its highly dynamic nature. This led us down the path of having to pick another language to work with, and we wanted to approach this methodically. As such, we defined goals for the project, explored which properties of a programming language are important to achieve those goals, and then evaluated a lot of languages against these properties. You already know the outcome--we eventually settled on Swift.
Below we explain [our project goals](#project-goals), discuss the [programming language properties](#properties-of-programming-languages) that contribute to these goals, provide a short [evaluation of specific languages](#which-languages-fit-our-project-requirements) against those goals, and discuss the [pros and cons of Swift](#evaluating-swift-against-our-language-properties) specifically.
## Project goals
TensorFlow is a world-class machine learning framework used by a wide range of different people for lots of different things. Our project goal is to provide a new interface to TensorFlow that builds on TensorFlow’s power and capabilities, while taking its usability to a whole new level. Our aim is to make machine learning researchers (both theoretical and applied), production engineers deploying at scale, and anyone else using TensorFlow more productive and joyful without sacrificing anything that already makes TensorFlow great.
From the class lecture:
Julia is too mature; Swift is new and maleable
S4TF is support by Google, so they have to make sure it works.
Jeremy likes the direction S4TF is going better than the direction Julia is going
Will S4TF support other than Nvidia GPUs?
like AMD Radeon 7, which has 2x the memory of 2080 which costs similar money.
Do you already see other big OS projects / groups like Google start to work on Swift / S4TF as well? Or are Google and fastai the only ones right now?
Here is Jeremy’s post that Chris just quoted: