I guess there are lots of uses in optimisation problems, and in sampling algorithms for statistics. I don't know how easy it will be to sell Swift to people who now use Stan or Stata (or R) and don't think of themselves as programmers.
> In a language with extensible syntax(ex: proc macros), this would sit in a library.
And this would allow easier iteration of different designs.
Is the idea here that Swift is a more approachable language and thus this is to lower the barrier of entry to TF?
* Speed, ML learning pipelines are often bottlenecked by the data load and transformation. TF had new mechanisms (the last I've seen was TF.data). But a language compiled to native is much more flexible in that regard.
* Type safety. Sometimes issues with the models can pop long after they have been running. The hope is that typed API's will show simple errors at compile times
* Auto differentiation built into the language. If I'm not mistaken, this is more powerful than backpropagation in TF, wich also has autodiff. The idea is that this would allow for more custom models without a performance penalty. My knowledge here is limited, since it's been over 2 years since I've implemented back propagation. I've successfully forgotten most of the things I knew about ML/DL.
I don't have any experience with R, but from what I've heard, it was known to be slow. But that might have changed or I may have misunderstood the situation.
Number types are first class which is a big part of it and you can add extra custom passes to the JIT compiler in regular library code.
You could write autodiff in say C++ but it is a user unfriendly language not well suited for machine learning and scientific computing.
Swift is a nicer high level language you can do autodiff in. But honestly I don’t see the point with Swift either.
Julia already does AutoDiff extremely well and outperforms Swift and pretty much everybody else.
And I think you're right, there is a low chance that this gets traction. Especially since Chris Lattner is at SiFive, they probably will have some kind ofAI accelerators, but TF is for training rather then execution. So not sure they'll find a reason to push it.
Jeremy Howard from fast ai might be able to convince people to give it a try. But without people working on it full time, the chances are not great. Especially with a compiler fork that requires constant merges/rebases. But, who knows.