But the question is whether it's worth using it over Kotlin (which is also better Java) - Swift is hamstrung because its primary implementation of standard libraries is limited to single vendor platform. If you try to run it on Linux/Windows, you're forever going to be fighting compatibility quirks stemming from the fact that the main libraries only target the Apple implementation of dependencies. It's a similar situation as Mono users were stuck in.
Kotlin is a language by a small company that only grew out of sheer love by the world. Even Google had to throw in the towel and officially support Kotlin. Flutter is a reflection of "creating a new language" - Dart.
Kotlin doesnt have the heavy handed lock-in of Swift. Wouldnt Swift fundamentally by handicapped by Apple's stewardship ? What if Lattner wants to add new constructs to the language ?
Kotlin is an interesting option, especially now that it compiles to the LLVM. One of the issues I see is the mind space these languages occupy. Kotlin is deeply linked to the Andriod community which oddly feels like baggage.
Julia has done a great job at marketing itself as the language built for modern numerical computing by numerical computing people. They have effectively recruited a lot of the scientific community to build libraries for it. I think the language is flawed is some deep ways, but there is a lot to learn in how they positioned themselves.
I like Kotlin, but the garbage collector isn't really meant for numerical computing I'd guess, and I doubt having to think about LLVM and JVM and JS at the same time is going to work out well for it when it needs such a heavy, heavy focus on performance.
"Java / C# / Scala (and other OOP languages with pervasive dynamic dispatch): These languages share most of the static analysis problems as Python: their primary abstraction features (classes and interfaces) are built on highly dynamic constructs, which means that static analysis of Tensor operations depends on "best effort" techniques like alias analysis and class hierarchy analysis. Further, because they are pervasively reference-based, it is difficult to reliably disambiguate pointer aliases.
As with Python, it is possible that our approaches could work for this class of languages, but such a system would either force model developers to use very low-abstraction APIs (e.g. all code must be in a final class) or the system would rely on heuristic-based static analysis techniques that work in some cases but not others."
Their justification for picking Swift over Julia rings a bit false, unless one reduces it to "we're familiar with Swift, and that's why".
They can't argue for Swift over Julia due to community size, given that Julia is far more portable, and more familiar to users in the scientific ___domain. 'Similarity of syntax to Python' is another very subjective 'advantage' of Swift: Later in the same document they mention "mainstream syntax" - that is, Swift having a different syntax from python - as an advantage.
I wonder whether they just decided on the language in advance, which is totally fine, but we could do without the unconvincing self-justification.
Julia may be portable but it doesn't run well at all on smaller embedded devices like a Pi or Nano for example and its compiler will be an issue on most mobile devices outside of terminal emulators.
They seem to be saying, they could have picked Julia, but were just more familiar with Swift:
> and 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 - which allowed us to implement a prototype much faster.
I think it's very debatable to claim Swift is more similar to Python syntactically, as Julia looks more like a dynamic language to the user. Also, Julia is closer to languages like Matlab and R, which many mathematical and scientific programmers are coming from.
Swift has a much larger community, but it's not clear how big the overlap is between iOS app developers and Machine Learning developers. It probably would make deploying models on iOS devices easier, however.
