best-of-ml-rust: a ranked map of the Rust machine learning ecosystem
🏆 A ranked list of awesome machine learning Rust libraries.
At a glance
- What is it?
- best-of-ml-rust is a curated list of 230 open source machine learning projects in Rust, split across ten categories and ordered by an automatically computed project quality score rather than by hand. It is useful as a survey of the ecosystem and as a signal of which libraries have staying power, but it ranks by metadata scraped from GitHub and package managers rather than by any test of whether the code works.
- Who is it for?
- best-of-ml-rust suits a Rust developer who wants to know which libraries exist and which of them look worth an afternoon, since the per-project entries carry contributor, issue and dependency counts alongside a quality score, and the categories match the shape of most real projects. It does not suit anyone who needs a comparison of API design or performance, because the ranking is derived from repository metadata rather than from using the libraries.
- Can I use it commercially?
- Yes, with credit. CC-BY-SA-4.0 allows commercial use as long as you credit the authors and indicate what you changed. It is written for creative content, so check how it applies to any code.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A survey of 230 Rust ML projects, scored rather than curated by hand
best-of-ml-rust describes itself as a ranked list of awesome machine learning Rust libraries, and the interesting word is ranked. Most curated lists of this kind are ordered by a human deciding what deserves to be near the top. This one says its ordering is calculated: all projects are ranked by a project-quality score, which is calculated based on various metrics automatically collected from GitHub and different package managers.
So the list has two layers. The selection is curated, in the sense that someone decides which projects belong on it and in which category. The ordering within a category is computed, and the computation is not described in the README beyond the name of the score.
The scale is substantial. The list contains 230 awesome open-source projects grouped into 10 categories.
Ten categories is more granular than most ecosystem surveys manage, and the distribution is revealing on its own.
- [Machine Learning Frameworks](#machine-learning-frameworks) _88 projects_ - [Text Data & NLP](#text-data--nlp) _63 projects_ - [Image Data](#image-data) _12 projects_ - [Data Loading & Extraction](#data-loading--extraction) _24 projects_ - [Graph Data](#graph-data) _6 projects_ - [Model Interpretability](#model-interpretability) _1 projects_ - [MLOps](#mlops) _5 projects_ - [Applications](#applications) _25 projects_ - [Analysis](#analysis) _1 projects_ - [Other](#other) _2 projects_
The first two categories hold 151 of the 230 entries, so frameworks and text processing are where the Rust ML effort is concentrated. Model Interpretability has a single entry, and Analysis has a single entry, which tells you that these areas of the Rust ecosystem are effectively empty rather than merely smaller.
That single-entry row is arguably the most useful data in the whole list, because a gap with one entry in it is a much stronger statement than a category with five.
Every entry carries the metrics the score is built from
Each project entry in the list is a collapsible block with a summary line and a details section, and the details are where the machinery shows.
The summary line gives the combined project-quality score, the GitHub star count, the licence, and a one-line description, sometimes truncated with two dots, as in the entry for tvm which reads Open deep learning compiler stack for cpu, gpu and specialized.. The details line then gives the contributor count from GitHub, the fork count from GitHub, the number of dependent projects, the issue count with the share of those issues still open, and the last update timestamp on the package manager.
So the raw inputs to the ranking are visible on the page rather than hidden behind the score. A reader who distrusts the ordering can see the components: the contributor, fork, issue and dependent-project counts sit next to a package manager timestamp such as 31.10.2024 for nalgebra and 29.11.2024 for burn.
The dependent-project count is the most useful of these for an adoption decision, because it is a proxy for how widely something is used by other Rust projects rather than how popular it looks.
The legend also defines a small status vocabulary. A project less than six months old is marked as new, one with six months of no activity is marked inactive, and one with twelve months of no activity is marked dead. A warning marker is used for issues such as a missing or risky licence, and a separate marker identifies a project that is a binding for another project. Projects that are trending up or down, and projects that were recently added, carry their own markers.
That vocabulary is what makes the list usable as a maintenance signal rather than a popularity contest. The inactive and dead markers are the ones that matter when you are choosing a dependency, and they are derived from the same automated collection that produces the score.
One caveat worth stating plainly. Every one of those counts is scraped from a public API and stored as a snapshot, so they carry whatever lag and rate limiting the collection process had. The README does not document the refresh cadence for the individual project entries.
Reading an entry means reading the library's own README
The entries are deliberately thin. Each one gives you the repository link, the metrics, the licence and a truncated description, and then a clone command for the project. The nalgebra entry offers this.
git clone https://github.com/dimforge/nalgebraThat is the whole suggested first action for every project in the list, and it is a reasonable one: the list is a routing table, and the actual documentation lives in each project's own repository.
The licences are named per project rather than for the list as a whole, which is the right way to do it and is also a practical trap for a reader in a hurry. burn, nalgebra, Peroxide, candle, linfa, tvm and tch-rs are listed as Apache-2, statrs and mistral.rs as MIT, and rust-numpy as BSD-2. A Rust ML stack assembled from several of these will carry several different licences, and the combination is a question for whoever reviews dependencies in the organization.
There is also a small inconsistency in the entries themselves, which is worth knowing about before you copy a command. The statrs entry links to github.com/statrs-dev/statrs but its clone command points at github.com/boxtown/statrs, which is the project's earlier location. Similarly, the burn entry links to github.com/tracel-ai/burn while the clone command points at github.com/burn-rs/burn. The list is generated from a data file, and these details drift.
That leads to the part of the repository that matters most for anyone who wants to keep the list current. The README says to open an issue, submit a pull request, or directly edit the projects.yaml file. The repository layout shows the same structure at the top level: projects.yaml as the data source, a config/ directory for the list configuration, a history/ directory, a latest-changes.md file, and a CONTRIBUTING.md alongside the LICENSE and README.
What the entries say about the state of Rust ML
The top of the frameworks category is worth reading as a survey in itself, because it shows which approach to machine learning in Rust currently has the most support behind it.
The highest-scoring entries are burn, described as a new comprehensive dynamic Deep Learning Framework, nalgebra as a linear algebra library, statrs as a statistical computation library, and Peroxide as a Rust numeric library with high performance and friendly syntax. Some descriptions, such as the one for burn, are truncated in the README, which is a reminder that the summaries come from each project's own one-line description rather than from an editor.
The Hugging Face entry is candle, a minimalist ML framework for Rust, and mistral.rs is described as blazingly fast LLM inference. Then linfa, described simply as a Rust machine learning framework.
The pattern that emerges is that the frameworks category is split between general-purpose deep learning frameworks (burn and candle), a classical scientific stack (nalgebra, statrs, Peroxide), and LLM inference engines (mistral.rs), with linfa in between as a traditional machine learning framework.
The entries that are not Rust-native are also listed, and the list marks them. tvm is the Apache deep learning compiler stack for cpu, gpu and specialized targets, and tch-rs is Rust bindings for the C++ api of PyTorch. Both carry the binding marker, the legend entry that reads A binding for another project. rust-numpy appears in the same category as PyO3-based Rust bindings of the NumPy C-API. So the list does not pretend Rust ML is a closed world, and it flags clearly when a project is a wrapper around something written elsewhere.
That distinction matters when you read the ranking. A binding inherits the maturity and the release cadence of the project it binds to, and the list's own metrics for such an entry describe the wrapper repository rather than the underlying library.
Where best-of-ml-rust is the wrong tool
The first wrong-tool case is a decision that needs evidence about the libraries rather than metadata about their repositories. The ranking is a project-quality score computed from metrics collected automatically, and the README does not describe how those metrics are weighted or normalised. If your question is whether burn or candle will fit your model, this list cannot answer it, and neither can the contributor and fork counts.
The second case is a decision about API or performance. There is no comparison of interfaces, no benchmark data and no notes on which crate works with which. The list is categorised by problem domain, and within a category the ordering is by score. Two frameworks with an identical score can have completely different shapes.
The third case is a team that needs to know the current state of a specific library. The entries are snapshots. Several of them carry package manager update timestamps from late 2024, and the last push to the list repository was on 2026-10-01, so the list itself is being touched while the data inside it is not uniformly fresh. The release history makes the same point from the other direction: the most recent release tags are 2024.12.01, 2024.10.02 and 2024.04.03, so the automated update runs have not produced a tagged release in a long while. A project that died after those dates can still appear without a dead marker if the collection process stopped visiting it.
There is a fourth, quieter wrong-tool case, which is using the list as a dependency decision in a regulated context. The warning marker is described as covering issues such as a missing or risky licence, but it is one symbol in a legend of many, and it does not replace a licence review of each project you actually intend to depend on. Different projects in the list carry Apache-2, MIT and BSD-2 terms, and copying a dependency list from here without reading each licence is exactly the shortcut the licence marker exists to prevent.
The alternative approach, and the one worth naming, is to read the projects directly. Each entry here links a repository, and that repository's own README, changelog and issue tracker tell you more about whether the library will suit you than a score can. The list earns its place by telling you which libraries to look at and in what order to look at them, not by substituting for looking.
Contributing to the list is a pull request or an edit to one YAML file
The contribution path is unusually open for a curated list, and it is worth knowing about if you maintain a Rust ML project and want to be listed correctly.
The README asks contributors to open an issue, submit a pull request, or directly edit the projects.yaml file, and says contributions are very welcome. A projects.yaml file at the repository root is the data source, so a new project is a structured record rather than a prose paragraph that someone has to parse.
The file format is what makes the automated ranking possible. Each record has to carry the fields that get scraped and displayed: the name, the repository URL, the description, the licence, and the package manager coordinates from which the update timestamp and download count are collected. Adding an entry is therefore a matter of supplying accurate metadata, and the metrics are filled in by the collection run rather than written by hand. That is a good design for a list that expects to be regenerated, and it is also why the display values look uniform.
The top-level layout shows the machinery around the data. There is a config/ directory, which is where the list configuration lives, and a history/ directory alongside a latest-changes.md file, which together suggest the list keeps a record of what changed between generations rather than silently rewriting the README. There is a .github/ directory for the automation, a CONTRIBUTING.md with the house rules, and a .gitignore.
The badge links point at a best-of.org site that hosts other lists in the same family and explains how to create one, and the badge images in the README are served from that site as well. So this list is one instance of a template format with its own update pipeline, not a one-off hand-written page.
On licence, the repository is CC-BY-SA-4.0, which is the usual choice for a curated list: the text can be reused and adapted with attribution, and the share-alike clause covers adaptations of the list itself. The individual projects listed are under their own licences, and the list records them per entry rather than claiming any licence over them.
Editorial conclusion
best-of-ml-rust suits a Rust developer who wants to know which libraries exist and which of them look worth an afternoon, since the per-project entries carry contributor, issue and dependency counts alongside a quality score, and the categories match the shape of most real projects. It does not suit anyone who needs a comparison of API design or performance, because the ranking is derived from repository metadata rather than from using the libraries. Before you commit to a library chosen from this list, clone it and read its own README, and check the update timestamps in the entries, since several of them show a last package manager update from 2024 while the list itself was pushed on 2026-10-01.
Frequently asked questions
What is best-of-ml-rust?
It is a curated list of 230 awesome open-source machine learning projects written in Rust, grouped into ten categories and ranked by a project-quality score computed automatically from metrics collected from GitHub and various package managers.
How are the projects in best-of-ml-rust ranked?
All projects are ranked by a project-quality score calculated from various metrics automatically collected from GitHub and different package managers. Each entry shows those raw numbers, including contributor count, fork count, dependent project count, issue count with the open share, and the last package manager update timestamp.
How do I add a project to best-of-ml-rust?
Open an issue, submit a pull request, or directly edit the projects.yaml file at the repository root, which is the data source the list is generated from. The README states that contributions are very welcome.
What do the markers next to projects in best-of-ml-rust mean?
The legend defines a new project as less than six months old, inactive as six months with no activity, dead as twelve months with no activity, trending up or down, recently added, and a warning for issues such as a missing or risky licence. A separate marker identifies a project that is a binding for another project.
Which categories does best-of-ml-rust cover?
The ten categories are Machine Learning Frameworks with 88 projects, Text Data & NLP with 63, Image Data with 12, Data Loading & Extraction with 24, Graph Data with 6, Model Interpretability with 1, MLOps with 5, Applications with 25, Analysis with 1, and Other with 2.
What license is best-of-ml-rust released under?
The list itself is licensed under CC-BY-SA-4.0, with the LICENSE file at the root of the repository. Each listed project keeps its own licence, which the list records per entry, for example Apache-2 for burn and nalgebra, MIT for statrs and mistral.rs, and BSD-2 for rust-numpy.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/e-tornike-best-of-ml-rust)Was this useful?