[jimfleming]

To those that are upvoting this and previous Swift + TF announcements: What are you excited about, specifically? Why Swift? Why not Julia? Is it the syntax? Types? Compilation? Performance? Community?

I like Swift and all but our ML/DL/RL/DS tools and libraries are in Python (and occasionally R). Most are missing for Swift without an awkward Python compatibility layer and I don't see a compelling reason to adopt it.

[ddragon]

I upvoted it not because because I use Swift (or intend to use it) but because I find it interesting that the concept of differentiable programming is pushed further and further. Having a host language being used to write and compile a second language (which is implemented in a third language) just feels restrictive in many ways.

I do think what is being done with Julia, Cassette, Flux and Zygote more interesting since it's Julia all the way down (while Tensorflow's backend is still C++) and the compiler work is focusing on not being specific to one implementation or technique, but allowing any such language extensions (such as auto-parallelization and other forms of source to source transformations) to be done by any 100% Julia library. So if Tensorflow for Swift (regardless of the actual reasons behind the choice of the language) proves that the technique is a significant upgrade over what currently exists, it could spark interest in the competing approaches, and I think Julia can help pushing the concept even further.

[itsmuriuki]

"I like Swift and all but our ML/DL/RL/DS tools and libraries are in Python (and occasionally R"

the python interoperability allows you to use all python libraries but in swift

[ddragon]

In the perspective of someone who writes Julia, which can also call directly any Python method (and R, Fortran, C and C++), that's a nice stopgap, but you really want a true native ecosystem. Not only there is more mental effort dealing with two languages at the same time (which might lead to people just use Python in the first place), the whole purpose of Swift for Tensorflow is having a language with first class differentiation support, which is pointless when the ecosystem is fragmented in multiple languages.

And there is the risk that the community simply ends up considering that good enough and just make wrappers (since it needs a lot of work to create something nearly as good from scratch). Thankfully that didn't happen with the Julia community, and the key is probably making the creation of the tools much easier so they can catch up to mature but constantly evolving environments.

[oscargrouch]

As far as i know, Swift is the only one embedding the graph flow of the TensorFlow directly in its compiler, so those idioms can translante from IR to machine code with paralelism and a fine-tuned machine code.

As its very common to target this sort of code to GPU´s, and LLVM can target them as output, i think is mostly because you can design and shape the langage right on its high level representation and tune for high performant code in the low level.

The why, i think, its about opportunity.. Chris Lattner going to Google, and people from the language and the compiler side of the fence being open about bake this right into the compiler when necessary.

[rjvir]

I think this article by Jeremy from fast.ai lays out a compelling case:

https://www.fast.ai/2019/03/06/fastai-swift/

[Someone]

”To those that are upvoting this and previous Swift + TF announcements […] Why not Julia?”

You seem to imply that people who upvote both Swift/TF articles won’t upvote Julia ones.

For me personally, I have upvoted earlier Swift/TF articles because they were well-written, and integrating differentiation fairly deeply into the compiler seemed novel to me.

I think I also have upvoted some Julia articles in the past, not because they were about Julia, but because they were interesting and well-written.

”tools and libraries are in Python (and occasionally R). Most are missing for Swift without an awkward Python compatibility layer”

An upvote need not mean “that’s immediately useful for me”. It could also mean “I like Swift, and this looks quite an improvement for it, making it more competitive with the leading technologies for machine learning” (you like Swift, so you _could_ upvote articles like these for that reason, too)

[sharcerer]

Fastai is also working on S4TF integration in the future. Here's Jeremy Howard's blogpost on WHY Swift?

Edit: I apologise, just after posting this comment I saw this link had already been posted. https://www.fast.ai/2019/03/06/fastai-swift/

[yeldarb]

You mentioned it but, for those who don’t know:

As a stopgap while all the data science tooling is being built out for Swift you can use anything from the Python ecosystem (including np and pd) by using the Python interop:

let np = Python.import(“numpy”)

https://github.com/tensorflow/swift/blob/master/docs/PythonI...

[mlevental]

how does this work? does it actually compile/embed there python interpreter or does it make calls to the system interpreter somehow?

[wool_gather]

From the linked document:

> To accomplish this, the Swift script/program simply links the Python interpreter into its code.

I would imagine that having the interpreter in another process would be a gigantice performance hit.

[mlevental]

yea i realized it's the obvious thing: load the dll.

[mlevental]

i just tried this out and i'm blown away that it works. even matplotlib. does anyone know how to point it at a different interpreter? a venv for example?

[pama]

My top four reasons: 1) the eventual MLIR for LLVM will empower new algorithms; 2) Lattner and team have a track record; 3) vast community of swift application developers; 4) fastai.

[threeseed]

I assume it is because you can use it on iOS/OSX.

And people are still doing a lot of Data Science work in R and Scala so I wouldn't say it is at all Python centric.

[sharcerer]

that's not the reason. Read this link: https://www.fast.ai/2019/03/06/fastai-swift/