Not sure whether I understood your statement correctly, but you can use Swift for using metal API already. Swift is not the bottleneck for TensorFlow, PyTorch like open-source machine learning library appearing for macOS based on metal, it is the closed nature of mac ecosystem itself.
Look at the flak Google, Facebook get regarding these projects in-spite of them being open-source. If an equivalent metal (only) based open-source machine learning of this scale did pop up with Apple's help; it may not go well with the ML/DL community as sharing & collaboration is valued high here. Apple has even started to publishing open ML papers to attract talent.
Then again, Apple doesn't get as much scrutiny as Google/Facebook does with the tech community, take a look at any HN thread on GoLang/Swift; the discussion on the former goes to the company rather than the programming language as in the case of latter in-spite of both being open-source.
Since the first early release, which largely worked for me, subsequent releases have generally not worked for me. I even had much more trouble with S4TF than, for example, the Haskell TF bindings that always take a bit of setup since I don’t use the provided docker setup.
A little off topic, but, the Julia Flux ML library is worth looking at if you wanna “turtles all the way down” setup.
And I don't see any Windows there.
Then there is the whole set of libraries that only compile on Apple platforms, no IDE, no Playgrounds and so on.
Well, swift-corelibs-foundation has made a lot of progress, and strictly speaking, to a certain point you don't actually want to hide some of the implementation details from the developer. This isn't Java - natively calling out to C is a thing that Swift can and will do.
> I don't see any Windows there.
Look harder. Swift for Windows: https://github.com/compnerd/windows-swift
> no Playgrounds
Swift Playgrounds: https://github.com/save-buffer/swift-repl
> no IDE
official VSCode work: https://github.com/apple/sourcekit-lsp/ + https://github.com/apple/sourcekit-lsp/tree/master/Editors/v...
> and so on
Do tell. What other concerns do you have? You seem deeply misinformed. While Swift may not yet have an ecosystem outside of Apple, it is factually incorrect to say that it is not usable outside of it.
you don't need to compile from source - binaries are distributed (if you actually read my link instead of assuming it was just github source you would see that).
>And I don't see any Windows there.
yes they're aware of this and it's being worked on
>Then there is the whole set of libraries that only compile on Apple platforms, no IDE, no Playgrounds and so on.
you're moving goal posts in order to be able to have an axe to grind.
your comment was
>For Mac OS only apparently.
the fact that there's a runtime that runs on linux shows that that was incorrect.
>set of libraries that only compile on Apple platforms
i don't know what you're talking about here - s4tf libraries compile on all platforms e.g. https://github.com/eaplatanios/swift-rl
>no IDE, no Playgrounds and so on.
i don't see how xcode being developed by apple (not the s4tf team) has anything to do with whether s4tf is multiplatform.
Swift is only usable in Apple OSes.
Making a tiny subject of its ecosystem available outside of Apple platform doesn't make it usable for something that pretends to replace Python ecosystem on data science.
So any language that can target .NET is also able to plug into it, and I certainly would pick F# over Swift.
Well Swift for Tensorflow is more than just a binding to begin with. The difference in maintenance is that Google officially supports Swift whereas Microsoft would be always catching up to keep theirs updated.
> So any language that can target .NET is also able to plug into it, and I certainly would pick F# over Swift.
I can use both Swift for my iOS app (inferencing), training is also possible thanks to Python interoperability (@dynamicCallable), soon to be replaced by native C++ interoperability.
If I chose F#, as much as you may think it is a good choice unless your stack/team is using Microsoft technologies, I see this as a potential sunken cost here and I certainly wouldn't use it for this case and would rather rely on the active maintenance of the Swift/Tensorflow team at Google to improve this rather than using another great language for an unsupported use case.
Even your examples are a proof of that.
Zero persons from Swift/Tensorflow team at Google are working on improving Linux/Windows support.
Linux was been mostly volunteer and some IBM contributions.
Windows are just volunteers, and have restarted the port multiple times.
I'll be amazed if it ever gets any significant foothold in the ML world.
Very interesting that Google is pushing Swift for their Tensorflow Platform. Any ideas why Swift is of interest for Google?
[1]https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
Lol at this. It's ~5 years before S4TF has feature parity with TF let alone pytorch. I watch their design meetings almost every Friday (they're public) and not only is the core autodiff runtime nowhere near 1.0 (just a couple of weeks ago they were talking about replacing their bespoke system with XLA) there's almost no differentiable function type library (nn.functional). Not to mention ecosystem (there are probably, at most, 20 people, including the S4TF team, consistently using S4TF). This is not to say that they're not doing great work but that's it's far off.
Edit: I forgot to also say they're going through the Swift evolution process (since they're building the autodiff into the Swift compiler) and it's completely unknown whether it'll be accepted. I have no idea what will happen to the project if it doesn't but if they end up having to maintain their own Swift runtime then S4TF is dead in the water because no one will be comfortable deploying two runtimes and even then no one will trust Google to maintain.
Five years is pessimistic. The core library is still in a state of flux, but the team is getting the fundamentals hammered out. Once the foundation is in place, adding higher level apis should be relatively straightforward.
Re: XLA/MLIR, s4tf is actively trying to coordinate with other groups within google. Whatever short term losses there are in time/energy will be paid off down the road when the project can piggyback off other people's progress.
Finally, while the swift evolution process isn't going as quickly as would be desired, the changes needed to merge the tensorflow branch have been identified and are being worked on. It's just a matter of time till the two projects are in sync.
I haven't seen people love a language without evangelism like Kotlin. And you already had the world's biggest ecosystem (because of Android).
And Kotlin native is pretty good. i daresay you would have had better control of the compiler there.
Same for Rust, Swift, Go... it's like we are in another bubble like the dot-com and everything is hype driven.
The only thing that is has done right versus Java is having AOT compilation since the begining (.NET always supported it via NGEN).
Not to mention that Java and .NET are platforms for programming languages, and already there Go loses big time versus what we have available on our toolbox.
I have no idea how, but 1-2 years ago when Kubernetes was new I tried it, and somehow got it to build (obviously I must have been using the stuff from the README) - but I haven't learned it.
Whereas with Rust? It's cargo. Done. That's up. Or rustup if you don't have anything yet. With Java? It's IntelliJ or the OpenJDK.
Last time I fiddled with something Go based was wit cfssl (cloudflare's excellent PKI thingie), and that uses something else. I don't remember what, it's in the GitHub Action YML file now. (Which alas turned out to be a big hot air pipeline :// )
I plan on learning a bit more about Go, but last time with the 2.0 proposal and the go mod/dep thing it seemed like there will be some streamlining, so I decided to postpone the immersion into the Go-cean.
The only other language with such a property is to my knowledge, typescript.
The amount of evangelism money that Google is spending on Tensorflow is staggering. Its not just t-shirts, but an entire ecosystem - TensorBoard.dev, Tensorflow Privacy, TF Enterprise, Explainable AI Beta, free TPU on Google Colab etc.
And all of them will soon be backed using Tensorflow Swift (https://www.tensorflow.org/swift). This is MNIST for Swift Tensorflow - https://github.com/tensorflow/swift-models/blob/master/Datas... . Mind you this is runnable on Google Colab using TPU hardware acceleration in swift.
Swift vs Rust is a very political thing...but previous discussions on HN have been tilted in favor of Swift [1]
And we havent even touched on the elephant in the Room - Swift may soon hook into OSX Metal (which is arguably the only way to do GPU AI on macbooks now that the nvidia-Apple CUDA divorce is official [2] ). You can already call Metal from Swift...but not write shaders directly IMHO.
[1] https://cloud.google.com/explainable-ai/
[2] https://gizmodo.com/apple-and-nvidia-are-over-1840015246