MLJ.jl VS swift

MLJ.jl is a good Julia ML framework. There's also a Scikitlearn.jl but its more of a wrapper around the sklearn I believe

MLJ is a machine learning framework for Julia, which you can kind of infer from the article but it's not super obvious IMO.

The Beta Machine Learning Toolkit is a package including many algorithms and utilities to implement machine learning workflows in Julia, with a detailed tutorial on its usage from Python or R (no wrapper packages are needed) and an extensive interface to MLJ.

You should definitely go with Julia. It has steeper learning curve than python, but it is way more powerful. As for the ecosystem, you shouldn't worry about that much: DataFrames.jl and friends is way better than pandas, MLJ.jl (https://github.com/alan-turing-institute/MLJ.jl) and FastAI.jl(https://github.com/FluxML/FastAI.jl) are great frameworks for regular ML and deepnet. And if at any point you get a feeling that you need some python library, you can always plug it in with PyCall.jl(https://github.com/JuliaPy/PyCall.jl).

Imho, Julia is more diverse in the sense that there is not a single popular ML library. Maybe the Julian equivalent for scikit-learn is MLJ.jl. There is also ScikitLearn.jl, which defines the usual interface of scikit-learn models, and specific algorithms then implement this interface.

Then you haven't looked at Julia's ecosystem.

It may not be quite as mature, but it's getting there quickly.

It's also far more interoperable because of Julia's multiple dispatch and abstract types.

For example, the https://github.com/alan-turing-institute/MLJ.jl ML framework (sklearn on steroids), works with any table object that implements the Tables.jl interface out of the box, not just with dataframes.

That's just one example.

I remember several years ago when differentiable programming was an object of interest to the programming community and Lattner was trying to make Swift for Tensorflow happen[1].

I'm of the opinion that it was ahead of its time: Swift hadn't (and still hasn't) made enough progress on Linux support for it to be taken seriously as a language for writing anything that isn't associated with Apple. However, as a result, Swift now has language-level differentiability in its compiler. I'd love to see Swift get used for projects like this, but I suppose the reality of the matter is that there are so many performant runtimes for 2D/3D physics that there just isn't much of a need for automatic differentiation (and its overhead) to solve these problems. The tooling nerd in me thinks this stuff is fascinating.

https://github.com/tensorflow/swift

there was a time when google attempted to integrate swift with tensorflow, but the project was abandoned, and the repo is archived now. I believe the swift community picked up some of the features, and they are still working on it.

Apple really is focusing on CoreML rather than differentiable swift, that was more of the vision of Swift4TF, which really was driven mostly by Google, until it was cancelled (I assume because of Chris Latner leaving google for SiFive): https://github.com/tensorflow/swift

to be fair, Swift for Tensorflow was dropped (Feb 21) way after this article was written (Aug 20) https://github.com/tensorflow/swift

Neat! This may have not been well known when they kicked off the project and wrote their reasoning. Here is what they had to say about Scala at the time of the document linked up-thread[0]:

"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."

If they were wrong about that, or if the state of the art has progressed in the meantime, that's great! You may well be right that Scala would be a good / the best choice if they started the project today.

[0]: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...

It was not in the README