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 
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  ). You can already call Metal from Swift...but not write shaders directly IMHO.
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.
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?
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.
I think Rust will eat more and more of the stack.
It has similar performance as C/C++, but feels more higher level. It's a drop-in replacement for C and is developed by a company that devs like.
 -- https://performance-dot-grpc-testing.appspot.com/explore?das...
The gRPC python sever implementation does a lot of work using python builtins, and doesn't use recent asyncio primitives. It uses built-in python thread-pool execution, which means you also have the GIL to worry about: https://grpc.io/docs/tutorials/basic/python/#starting-the-se...
Given that, I would expect its connection / request management to be pretty darn slow. gRPC has better support for Python as the client. The thread pool execution model also prevents you from doing a number of things you might want to do with gRPC servers (long-lived request streaming is out of the picture).
There are a couple third party packages out there trying to make this better (e.g. https://github.com/vmagamedov/grpclib) but I hit compatibility issues for a few cases when trying to use them for some prototypes.
For mission critical production usage, I think to use high performance systems/languages is pretty good starting point. With the assumptions that you update your model conservatively(not often), there are enough engineering resources to maintain and 'port' models from python, since most data scientists are trained with python. I think in this type of workload and context, it makes sense use Rust for deployment.
Another type of workload I think it is much more common. It is the experimental projects that data scientists are trying to discover does those have enough ROI to be part of the production system. Those projects and deployments are requiring a quick turn around on iteration cycle. I am not sure Rust or even Swift are good tools, when typical data scientists are not well versed in those. Not to mention, usually in this setting, they don't have a lot of engineering resources they can use. Python is still the go to option for this type of work.
I think the article has the right intention, speed up ML production. For the experimental work setting, I think we can have the cake and eat it too. Data scientists, still use python and generate production ready deployment service without help from engineers.
We create an open source python lib/platform called BentoML(www.github.com/bentoml/bentoml). BentoML makes it easy to serving and deploying ML models in the cloud, from ML model to production API endpoint with few lines of code. You can try it out at this Google Colab notebook(https://colab.research.google.com/github/bentoml/BentoML/blo...)
BentoML works with multiply ML framworks(Tensorflow/fastai/pytorch/etc) and could generate different distribution formats (docker/AWS Lambda/CLI/Spark UDF) for your serving need. We also support custom runtime backend. Feel free to ping me or ask questions in our slack channel. We are pretty active there.
Rust can't currently replace C or C++ at the back-end because it doesn't have good enough support for GPU computing yet.
Rust doesn't have to replace anything. It can be used to create complementary packages especially ones that use C/C++. The point of introducing Rust into your ecosystem is for safety + performance which is hard to achieve without discipline.
With Intel just releasing oneAPI (aka Data Parallel C++) last month, and Khronos pushing SYCL as alternative to CUDA C++.
It took 30 years for C++ to reach this stage, and in some domains (like embedded) it is still fighting for relevance.
That is something to keep in mind whenever to advocate Rust as replacement for Domain XYZ.
Rust has yet to define a memory model.
I also can't find any details on the CUDA project you mention, it seems counter-intuitive to me. At least with graphics data, it's mostly just large buffers of structs, defined with vertex attrib pointers or whatever. What advantages would a more complex memory model yield?
A language memory model is a mathematical specification on how the language semantics map to actual CPUs and the basis how to write lock-free algorithms.
If you bothered to follow the YouTube videos you would found the CUDA projects I mentioned.
Rust currently doesn't have such mathematical model.
Dude, you linked to two hours worth of video. Give people a break.
Just clicking on the links would show the info.
I'm not sure that I understand correctly - are you suggesting that people use Rust as an additional layer between Python and C++?
For single threaded applications, as fast is the goal. There is potential for it to be faster due to stronger restrictions around pointers.
Multithreaded code is slated to be faster mainly because rust provides safety for patterns that would be difficult to do right in C++ (see servo css handling).
That is to say, you could do the same thing in C++, but getting it right is harder to do.
The same environmental conditions don't apply to other software and it's perfectly possible to write blazing fast multithreaded software in C++. In fact that's SOP.
Mostly regarding using BLAS etc in Rust rather than C++. It seems a little pointless as the unsafe nature is within the underlying code, so it only santises input/output.
Adding a thin wrapper over an insecure library won't magically make it secure. That's why pure Rust or pure Swift versions of various algorithms and functionalities are worth so much - guaranteed memory-usage correctness.
Being compiled doesn't mean anything, it is a matter of tooling.
I think the future is Julia, as it's as easy to write as Python, is interactive, and can be compiled for fast speeds!
It will just takes time for Julia to have as many libraries, but at some point the tipping point will be reached, and Julia will just eat Python's lunch.
Python was dying before the latest wave of data science and machine learning craze saved it anyway. There are pretty good reasons to believe Python (and Ruby) will slowly wither away. I am careful not to savy that they will die out, because they won't as some computing problems do not require so much speed and hence Python and the like can still pass mustard. But in a post-Moore's-law-world, data is getting bigger, the demand for computing is larger, but programs aren't getting faster, and there is a limit to how much you can optimise Python. Eventually, a crop of speedy and easy to write programming languages will rise up and eat Python's lunch. The early signs are there with tools like Julia.
It warms my heart to see people don't read TFA. Like at all.
> But it was important to clean the air of any possible misunderstanding before getting started.
I don’t believe Rust will replace Python as the language of choice for ML - it just isn’t happening, it’s not a thing, neither today or tomorrow.
Your parent wrote detailed reasoning that's not present in the article.
Also this type of uncharitable comment is against Hacker News guidelines: "Please don't comment on whether someone read an article".
There is no expanding on topics barely mentioned in the article. As far as GGP is concerned there was just a headline and they Kanye'd with "Julia is the best". As far as I care, mods can delete the comment and subtree.
But your week-end project you need to write a bit of code for and want to practice a new language with/just want to code as quick as possible? Sure, the languages will come and go.
Likewise with Rust. Maybe not for iterative design phases, but I can certainly see it being used in production, especially if robustness/speed are needed.
Because the core is so brilliant at what it does I am sure that Julia will get there eventually, but it will be a painful way.
For crying out loud, we still don't have a sory for people to save their data...
Can you elaborate on what you mean by this? Does Julia not support writing files?
Beyond that there is a bewildering array of packages, and not really a clear consensus for which to use:
JLD2, which for a while seemed like an emerging consensus option has caused massive dataloss for a number of people:
The issue is also that Julia packages often use their own container types for convenient analysis. For example the solution type of DiffEq has a number of important features like interpolation built in. If I want to reliably save the data I got from the numerical integration, and don't want to rely on brittle/broken serialization packages, I have to extract the underlying arrays though. That would be fine if not for the fact that there is no documented way (that I've found) to initialize the solution objects from this raw data, so now I have lost access to the convenience functions.
Don't get me wrong, this is all growing pains. I am sure this will be sorted out eventually. But it's important to point out how the intersection of features that enable Julia to do things that are unheard of in other languages (e.g. DiffEqFlux, Zygote) also mean there are some things that still need to be figured out for this language (serialization, useful error messages, interfaces).
The only workaround is to use an undocumented alternative interface for working on the files. A pull request to at least inform people about the issue has been lying around for almost two years.
I am happy that activity has picked up again, but don't intend to recommend the use of JLD2 for expensive data for the foreseeable future...
Many researchers work on Windows, Swift has zero support there and when asked about it, they just kind of invite the Swift community to provide support.
So zero interest from either Apple or Google to make it work on Windows.
This is the latest status of Swift on Windows,
Then on Linux, Foundation support is still flaky, for basic stuff one still needs to do conditional compilation and directly import either Darwin or GLibc modules.
Swift is just like Objective-C, yes you can kind of use it outside Apple's ecosytem, but at expense of productivity and lack of adequate tooling.
Really I don't expect Tensorflow for Swift to ever reach mainstream adoption, maybe Google can sell it as Mac only and thus announce the project has having been a success.