7 ms·
The creator of Swift (and LLVM), Chris Lattner now works for Google. There’s already an experimental version of Tensorflow[1] for Swift. I personally believe th
by woadwarrior01 7y ago
The creator of Swift (and LLVM), Chris Lattner now works for Google. There’s already an experimental version of Tensorflow[1] for Swift. I personally believe that Swift will really shine in differentiable programming and thus machine learning. A little over a decade ago, most of the machine learning community was using either Matlab (and it’s open source clone Octave) or R.
It took a long time for the machine learning eco-system around Python to develop. I believe that’s the case with Swift as well.
[1]: https://www.tensorflow.org/swift/ https://www.tensorflow.org/swift/
- xvilka 7y agoJulia is better suited for differentiable programming and machine learning. Something like frontend/scripting with Julia, and computing cores with Rust, as an alternative to the ubiquitous Python + C/C++ stack. And there are already more or less established frameworks for Julia: - FluxML[1] for machine learning - Zygote[2] for differentiable programming - Turing[3] for probabilistic programming - Rich support for GPU[4] [1] https://fluxml.ai/ https://fluxml.ai/ [2] https://fluxml.ai/Zygote.jl/latest/ https://fluxml.ai/Zygote.jl/latest/ [3] https://turing.ml https://turing.ml [4] https://juliagpu.org/ https://juliagpu.org/
- favorited 7y agoThey examined both Julia and Rust, among others, before deciding to move forward with Swift for Tensorflow. https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
- xvilka 7y ago> We are not experts in Julia, but since its compilation approach is based on type specialization, it may have enough of a representation and infrastructure to host the Graph Program Extraction techniques we rely on. A quote from your own link. So they admit Julia might be a good fit. The only argument they gave is the "small community size", which is wrong, because Julia data science and any other computational science community is way bigger to almost non-existent Swift one.
- favorited 7y agoYes, and the next paragraph says: > 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 So Julia could match well, but the team at Google determined that Swift was a better fit for their new TensorFlow platform.
- cbkeller 7y agoWell, Julia's technical computing community - arguably the subset that matters here - was much larger than Swift's. The more significant justification IMO, is > and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster. In any case, both Julia and Swift seem to be making good progress here and I wish them both the best.
- ptx 7y ago> is syntactically closer to Python How is Swift's syntax in any way similar to Python? Other than not having semicolons, they clearly belong to different language families and don't seem particularly similar. Is there some very specific feature they were referring to here?
- cbkeller 7y agoChris Lattner is leading the project, of course they're using the language he designed. Personally I think they substantially underestimated the difficulty of setting up a full technical computing ecosystem in Swift relative to Julia. But, fair enough, if I'd designed Swift I'd probably be dogfooding it too. Some previous discussions that mention the swift-vs-Julia decision: [1] https://news.ycombinator.com/item?id=19714622 https://news.ycombinator.com/item?id=19714622 [2] https://news.ycombinator.com/item?id=19884273 https://news.ycombinator.com/item?id=19884273
- taharvey 7y agoActually this started before Lattner. Richard Wei kicked this off with his DLVM thesis. Either way, Swift's functional design around a type system has some compiler implications towards solving larger problems that Julia probably will struggle with as it moves forward beyond the goal of just being a faster Python.
- byt143 7y agoSpecifically what?
- taharvey 7y agoEssentially Swift is in Lattner's words "Syntactic sugar for LLVM"... meaning it was designed from a compilers point of view to provide an ontology for code that a compiler can analyze, interpret, optimize, and enable deeper functionality. Swift backed that ontology with a functional type system that forms a set proofs of the relationships and meaning of your code. If you take a language like C++, the "atoms" of the code like a Float32, are just hard coded intrinsics in the compiler. As such, they have no ontological meaning in relationship to a Float16, an Int32, or an Array of Strings. In Swift, a float is built from a set of proofs as equatable, hashable, Numeric, FloatingPointNumber, and etc. As related to Julia or Python, a static language built around these proofs, enable compiler's to provide "co-pilot" development assistance, guarantees at runtime, code validation. Why is this important? With deeper knowledge, a compiler can optimize things in ways that weren't previously possible, extract graphs, and automate code execution in heterogeneous computing evironments.
- taharvey 7y agoThe guys in our group giggle at Hacker News. The only time they ever even hear about Julia, is when a Swift article shows up here... then all the Julia nerds come out of the woodwork. Guessing the opposite rarely happens.