There is some support on GNU/Linux, almost non-existant in other platforms.
However what makes a programming language is not only syntax and semantics, but libraries, IDE, tooling in general, and those are pretty much only available on Apple platforms.
There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift.
Swift is already more widely used than Objective-C outside of Apple platforms. The main difference is that the Objective-C runtime (which is required to make Objective-C useful in any meaningful way) is closed-source and not available on non-apple platforms. The Swift runtime is available and officially supported on Ubuntu.
> There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift.
Most of those examples are proprietary frameworks for interfacing with the Apple platforms directly. Most major platforms include proprietary frameworks, and their existence as value-adds on that platform don't speak to a detriment of the language as a whole. Your statement is like saying C++ is not useful outside of Windows because there is no DirectX.
There is already a large body of open source libraries for Swift for a variety of tasks, and moreover Swift's excellent C interoperability makes it very reasonable to make serious platform-agnostic software with Swift.
Which is actually the only OS outside Apple platforms that has any kind of proper support for Swift.
> Your statement is like saying C++ is not useful outside of Windows because there is no DirectX.
C++ is usefull outside Windows, because it is an ISO standard in no means bound to Windows, with several OS vendors and OEM contributing for multiple implementations of the said standard.
> There is already a large body of open source libraries for Swift for a variety of tasks, and moreover Swift's excellent C interoperability makes it very reasonable to make serious platform-agnostic software with Swift.
Quantity does not mean usefulness.
Great interoperability with C isn't exclusive to Swift, and is also available in languages with a bigger markeshare, with implementations across several OSes.
Swift is great as replacement for Objective-C, improving the safety on Apple's platforms and making FP mainstream on those platforms, as cross platform language it still has quite a lot to improve.
I agree with you that Swift has a way to go before it can be considered a truly platform agnostic general purpose programming language, but it is making strides in that direction. Recently Windows nightly builds have been introduced, and work has started on Language Server Portocl support, which should aid usability on 3rd part IDE’s. Also it’s somewhat perplexing to me that Swift for Tensorflow is often viewed as a strange move under the assumption that Swift is only for iOS, rather than being viewed in terms of Swift’s adoption for a new category of use-cases with the backing of a tech giant in Google.
It remains to be seen whether Swift will find wide adoption, but I think it’s a mistake to assume it won’t only because of its origins.
Naturally GNUStep kind of runned out of steam by Pather, but still.
Not to mention that it’s very different to have cross platform support as part of the core development process. With a 3rd party implementation like GNUStep,(especially one with a relatively small user base) there is no guarantee that it would keep pace with Apple’s implementation.
Swift is a much smoother, modern experience. I am not saying it is perfect, and other languages have much better support across platforms, but to compare Swift and Objective-C is just not accurate.
I would not say that's exactly true. There are a number of projects shipping server-side swift, and there is some nice tooling for using Swift where you might otherwise use a scripting language. Personally I reach for it more and more for projects outside of mobile, and find that the non-iOS ecosystem has grown to feel very functional in the past couple years.
iOS is undoubtedly still the main use-case for Swift, but plenty of people are using it for other things.
But to add to my point... unfortunately, none of those are in the realm of numerical computation or anything remotely connected to the Tensorflow domain.
If a Tensorflow user needed to interact with the ecosystem, it would seem that there's not much in place because the folks currently in the Swift community don't work in those fields, whereas Julia folks do. It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc.
Now that is not to say that with Google's backing, the community won't shift, but that will take time and uptake is uncertain, whereas with Julia that community alignment already exists.
And the Julia community didn't start out being platform-centric, so it has a broader base. I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary.
Again, not to put Swift down. It's just a very curious choice for Tensorflow is all.
Actually I think thst's something which is very strong about the TensorFlow for Swift effort: it allows you to call Python out of the box, so all the Python tooling which is currently available to data scientists is immediately available. It seems the goal of the project is to allow users to immediately take advantage of the convenience of swift (especially the type system) in an incremental way, leaving most of their workflow intact.
They're also already bringing a lot of numerical computing utilities into the language itself. It already has native linear algebraic operators like dot product built in, and automatic differentiation is coming.
> I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary.
So I currently experiment with it using Docker, which you could do on Windows. I know that's not as good as official support, but it is possible.
Anyway, I haven't worked with Julia beyond playing with the REPL a bit, and maybe it would have also been a great choice for TensorFlow. At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language.
I find it very nice to work with and I would be happy to use it in more places where Python is currently the main option. Also the TensorFlow team seems to be doing some very interesting things with it.
> At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language.
I'm sure there's some of that, but my feeling is -- and I speak only for myself and maybe some in my tribe -- that it isn't so much the perception of Swift as a proprietary language but more that it isn't a language designed for DS/ML/applied math and maybe the Swift community doesn't really get our needs, whereas Julia is and does. Python feels like the latter too -- it was swiftly adopted in DS/ML because it was already used heavily in scientific computing, which is part of the same family.
The community vibe alignment isn't quite there with Swift -- it has no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and a kind of depth as it were.
But it's just a feeling. I will leave it at that.
It's an interesting perspective, and I think my own tribal bias as a software engineer plays in to my gut feeling on the topic.
To me it's natural to see it in these terms: who's going to make a better saw: a metal worker or a wood worker? The woodworker might know exactly what he wants out of a saw, but the metal worker is a heck of a lot better making things out of metal.
But that's just my biased opinion.
A good saw is spec'ed by a woodworker and made by a metalworker.
A great saw is made by a metalworker who is also a woodworker. This latter bit is true for the Python community, at least for the people and companies who write DS/ML tooling in Python. Excepting hobbyist/academic tooling, Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. Julia seems to following the same path though it's not as far along as Python, but from what I've seen, Julia folks are numerical computation folks who also really understand software.
At present, Swift is like a metalworker who's seen saws used by woodworkers but isn't really into woodworking (yet) and doesn't have a whole lot of experience with the woodworking craft.
So this is what I see in the TensorFlow for Swift project. If you look at the core contributors, you have a team of ML experts, as well as the original creator of the language. It still remains to be seen how it will go, but it seems like the right group of people to go about this effort.
> Python has some really high-quality DS/ML tooling built by people who know software and the problem domain.
See that's where you lose me a bit. There is a lot of really exceptional work done in Python, but in my view that's in spite of the language.
Python strikes me as as a language which has been adopted in the scientific community because it's low barrier to entry makes it approachable to non-expert programmers, but comes up lacking when compared to modern programming languages.
Between the version fragmentation, environment management, type system and the nature of runtime errors there are a lot of pain points which are already solved problems in other languages. When I have to work in Python, I am not particularly happy to do so.
Maybe Julia solves these problems. But I also wonder whether the scientific/ML community really knows what they're missing.
IBM helps with Kitura, but I am yet to see some real project worthy of news headlines deployed with Kitura.
The point is it is possible to deploy serious server-side software written in Swift, and people are already doing it. It's inaccurate to say that Swift is only useful for iOS projects.
It remains to be seen whether Swift will find wide adoption, and a lot of that hinges on tooling support which needs a lot of work outside Apple platforms, but I think there is also too much of a tendency in the Software community to under-estimate Swift's potential usefulness as a general-purpose language because of its origins in iOS. I see that frequently in the tepid reaction to Swift for TensorFlow.
Examples that you would care to share with us?
Really serious examples, not the typical blogs and ToDo's done with Kitura I have seen at some conferences.
For me, Tensorflow would be better served with Julia, given the target demographics.
However if it helps Swift ever to be usable on Windows, then more the better.
Also a few links I was able to find with a quick search:
ING is using it:
And also this startup
So again not huge examples by any measure, but it’a not nobody.
"In the end, we narrowed the list based on technical merits down to Swift, Rust, C++, and potentially Julia. We next excluded C++ and Rust due to usability concerns, 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."
However, the Swift community is larger only because it is used on iOS for non-numerical computation applications completely unrelated to Tensorflow. If we draw the lines of community around people who are in Tensorflow-related fields (i.e. numerical computation), I suspect the size of the Julia community is actually larger than Swift's.
I've been a Pythonista for a decade and a half, but in this case, Julia seems to me to be the more logical pick, given that it is designed for numerical computation (it is the modern successor to Fortran). Julia is syntactically closer to Matlab, which is a language familiar to many grad students, a pool from which many future Tensorflow users are mined.
The last point is valid though. Still, as someone with a numerical computation background, Swift remains a curious choice.
I'm not very familiar with Julia, but my impression of Matlab from university is that it was a pragmatic tool which was useful in its domain because of library support, but not that it was a well-designed language that I wish I could use everywhere. If Julia has aped Matlab's conventions because they are familiar to the community, I would worry that it may have also learned from Matlab's bad habits. I would be more trusting of the software engineering community to produce tools which are optimized for usability and creating robust software.
No, it's more like Julia has taken "Matlab: The Good Parts" as well as practices from modern languages and created a new language with them that is morphologically familiar to Matlab users, yet is an entirely new design.
 Except for 1-indexing, but that was a carryover from Fortran, which in turn adopted it from linear algebra convention and it seriously isn't that bad. I wrote production Matlab for 12-years and 1-indexing was the least of my troubles. It's a theoretical polarizing issue like Python's use of whitespace, but in practice it's not an issue.
I think that it really depends on the use case, if you're using only Julia it won't be an issue, if you use Lua as an extension languages of C++ and you have to work on both side at the same time like I had to do..
Well, let's just say that I wasn't exactly having nice thoughts towards Lua creators ..
Maybe it's because I come from a C/C++ background, but declaring a few weak references here and there never felt like much of a hindrance to me.
* You're always thinking of whether you might need to use weak refs, right? That's a cognitive load that you would otherwise be spared.
* What are the consequences when you get it wrong?
* How probable is a mistake, particularly when working with a large complex codebase that you didn't create, and don't fully understand?
* How probable is it that you might fail to detect a mistake, for a long time?
I’ve really found this to be the case with every app I’ve made. I used to make the app, then start working on marketing, and then realize in trying to frame the app for its target audience that there were a bunch of things I’d want to change in the app. By constantly working on the marketing aspect, you’re able to get those things in early. Launching the initial prototype to a group of trusted testers and then iterating constantly is a really effective way of doing this, at least in my experience.