In this write-up, I'm going to make a core assumption: the ndarray should be the basis of any general machine learning program moving forward. While commits aren't necessarily an indicator of quality or interest, the fact that ndarray has almost 20x the number of commits as rulinalg, has multiple consistent contributors, better documentation, and a wider base for extension into multiple domains. As a result, I'll be assuming that of the two-and-a-half projects I'm discussing here, all would need to be significantly re-written, or at the very least, a well-designed shim layer built for converting between the ndarray data structures and the Matrix or Tensor structures currently used in rusty-machine and leaf/juice.
I'll lay out some of my reasoning below, but I'll make my primary point here so people don't have to go searching: while I think that they've done some really great and interesting work, I'm not particularly interested in using a fork of any of the three as the basis for a machine learning project moving forward.
Obviously, these aren't the only ML libraries of their kind, but I believe that they are the most popular, and after a cursory search, currently the most-developed of as well. Using Github stars as a proxy, Leaf has believe it gained the most attention, with a total of well over 4000 stars. rusty-machine also gained some attention, with a total of just under 1000 stars, and juice seems to have lost a little of leaf's initial steam with under 600 for it's core fork.
Obviously, after some discussion in this blog post, leaf is no longer under current development. rusty-machine does have a periodic maintainer, but is no longer active. However, the original author and current maintainers have also seemed open to the potential of transferring maintainership to others in the past, so actually forking the project might not be entirely required. However, although I do like some of the design decisions for non-neural net related aspects of machine learning (it's KMeans implementation is actually quite nice), I don't think that the neural net implementation seems nearly as robust as the design patterns in leaf/juice. To me, it feels like it qualitatively leaves room on the table for building more complicated models, which I'm not sure is something that can be easily fixed by switching libraries or adding a couple of functions.
I recently tried building both leaf and juice, in both cases with no success. To start, leaf doesn't seem to want to compile, and I got stalled out on trying to solve the problem after a while. Using rustc 1.41, I needed to upgrade the capnpc up from 0.6.2, make sure to use edition = "2015" in the Cargo.toml file, and add a use std::borrow::Borrow; statement to five or six files, and then ran into a type annotation issue seemingly related back to the capnpc build system that I banged my head against for a while. Trying to move to using edition = "2018" results in over 200 errors, most of which seemed to be due to changes in how dependencies are called, while others are due to changes in updates to error-catching syntax. My experience with porting between editions makes me imagine more would get caught once those top-level errors were taken care of as well. In any case, it seems that while it would be possible to get a fork of leaf up and running again, the four years since the last commit have seen fairly significant changes to both the language and ecosystem that might make working off a direct fork undesirable.
There's also a line in the examples/benchmarks.rs file that states "Examples run only with CUDA support at the moment, because of missing native convolution implementation for the Collenchyma NN Plugin," which seems like the first hurdle that would need to be overcome to enable contributions by anyone without an NVIDIA-enabled development setup.
juice is a different situation. The compilation here went smoothly, until the end when the system needed to link to system libraries. Now, the README very clearly states a disclaimer which says that both CUDA and cuDNN are required to run the examples. What it doesn't say is that they are required to build the project to begin with. Obviously, that's the choice the the maintainers of the project have made, and it's absolutely their prerogative to do so. I also realize that the based on the design of Collenchyma, the two are intertwined, but since CUDA technically has the potential to be used without necessarily using cuDNN, I'll address them separately.
My primary development machine doesn't have an NVIDIA GPU, but I do own a laptop that does, and have access through my workplace to other compatible machines aside. CUDA installation isn't always easy (I've spent far, far too many hours debugging compatibility issues with libraries that need different CUDA versions on the same machine), but there are tools to make it manageable, including ones that are free software that I can get through and apt-get install command or five. However, especially with the recent improvements in AMD's chip offerings, I generally feel that any requirement to use a system with NVIDIA-specific hardware isn't the right move. One of the features that attracted me in Rust in the first place was the ability to write code in one system, then cross-compile for another architecture with very few issues, and losing that feature in the machine learning space is something I feel would be detrimental.
However, while I might be able to get over the current explicit dependency on CUDA, the cuDNN dependency has a huge problem, and it's one that I personally consider a dealbreaker: in order to download it, you are required to create an account with NVIDIA. I don't consider myself a free software zealot, but a de-facto requirement to register one's self with an organization in order to use a library is not in line with my comfort level, or the values I'd like to see in a working group to which I'd be willing to contribute.
All of that said, there's enormous value in the work that Autumn did on leaf, and that the maintainers of and contributors to juice have added. In particular, their network configuration build patterns seem very intuitive to me (layer-based design), as well the way various backends (choosing between CUDA or OpenCL or just a multithreaded CPU) can be called looks really useful. All of those things, as well as some of the organization of those projects seem like they would merit serious attention when starting to build something new. But I do think that based on the work that's been done in the meanwhile with ndarray and the ecosystem surrounding it for actions like pre-processing, the current difficulties involved with getting developers up and running on either version of the project, leaf's missing functionality with respect to native backends, and and the dependencies requiring CUDA/cuDNN all make it such that I'm not particularly interested in using either one as a basis for a machine learning project.
Note: I'm very to hearing thoughts from the community about this subject! In particular, if I missed something or misinterpreted some of the facts about the current state of any of the projects, either in a trivial or materially important manner, please file an issue and let me know.