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.
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.
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.
the python interoperability allows you to use all python libraries but in swift
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.
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.
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)
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/
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...
> 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.
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.