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.
- FluxML[1] for machine learning
- Zygote[2] for differentiable programming
- Turing[3] for probabilistic programming
- Rich support for GPU[4]
https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
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.
> 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.
> 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.
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?
Some previous discussions that mention the swift-vs-Julia decision: [1] https://news.ycombinator.com/item?id=19714622 [2] https://news.ycombinator.com/item?id=19884273
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.
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.
Guessing the opposite rarely happens.
Whereas a language like Haskell is happy to try some absurdly abstract concepts in the interest of promoting computer science.
Swift's complexity feels much less compositional. There are still a lot of situations where I won't really know how certain features interact (especially when it comes to generics, associated types, etc.). Also, the documentation on some edge-cases is basically non-existant.
Swift and Rust are definitely similar in complexity, but Rust actually merits most of its complexity imo. It gives strong guarantees and a strong foundation for the future; I don’t believe that Swift has that. Swift adds a lot of features for the sake of having them, and I think that will catch up with the language quickly (see C++.)
As a random example, take the content of this article: https://www.rightpoint.com/rplabs/switch-method-dispatch-tab...
This is something that my less grumpy iOS developer colleagues regularly stumble over, and yet they keep telling me that Swift is super simple.
Also, Apple's tooling for Swift has gotten less crashy, but not more reliable in my experience. Almost every time I command-click a Swift function in Xcode to find its definition/source, Xcode shows me a random C function with the same name in some completely unrelated header file.
I predict/hope that Combine will be peak Swift, and that it will only accelerate the move to Electron and other portable technologies (go Flutter!).
https://news.ycombinator.com/item?id=17278175
I will say that I think the language made compromises in all three of these directions, though.
1. We've moved our company code base from tight C/C++ code to Swift. It is just as fast, with higher level syntax. In some cases faster. It has native SIMD types without external libraries too. Moreover, the Swift group has been focusing on correctness over performance to date. The goal has always been, that its deeply typed design can enable optimizations not even possible in c/c++.
2. Several of the founding Rust team moved to the Swift dev team years ago. As of Swift 5, the memory model supports the Rust-like borrowing. One could say Swift at this point is a complete superset of Rust. But, more importantly Swift favors a functional style of value type operations... which are inherently memory safe, and have no concurrency side effects in the first place. Value types together with Swift's very easy to use Dispatch concurrency library work for most use cases... it is viewed that "borrowing" is only a special purpose opt-in feature.
3. Swift is pragmatic. It is functional in its type system, value type operation, and no side-effect philosophy. But it is multi-paradigm, flexible, and designed for the real-world problems that reflect real programming needs... where as Haskell is arguably an academic curiosity and extremely unlikely to become a mainstream general purpose language.
Been hearing that for a decade now, but somehow I'm not out of work.