Scholar: Traditional Machine Learning Algorithms on Top of Nx for Elixir

Classical ML in Elixir Without Leaving the Nx Ecosystem

Scholar occupies the space between Axon (Elixir's deep learning library) and raw numerical computation in Nx. Where Axon handles neural networks and gradient-based training, Scholar handles the classical ML repertoire: classification, regression, clustering, dimensionality reduction, metrics, and preprocessing. The two libraries are complementary and share the same Nx backend, so a project can use both without switching ecosystems.

The target users are Elixir developers who need statistical modeling or data preparation in their applications without reaching for a Python subprocess. Running ML in-process avoids serialization overhead and keeps the deployment footprint to a single runtime. This matters most for Elixir services that already use Nx for numerical work and want to add ML inference without a separate Python model server.

Scholar is maintained under the Apache License 2.0 by the Machine Learning Working Group of the Erlang Ecosystem Foundation.

How Nx Numerical Definitions Enable GPU Compilation

The central design constraint in Scholar is that all algorithms must be implemented as Nx numerical definitions using the defn or defnp macros. This constraint is not cosmetic: it is what allows the entire algorithm library to run on GPUs. When an algorithm is written as a defn, it can be JIT-compiled by EXLA to run on the host CPU, CUDA GPU, or ROCm GPU without any code change.

The README includes a warning that loop-heavy algorithms in Scholar are much more memory efficient when JIT compiled. Without a default compiler, the interpreter executes each numerical operation eagerly, which can create large intermediate tensors for algorithms like affinity propagation or k-nearest neighbors.

This same constraint is why certain algorithms are absent from Scholar. Decision trees and random forests depend on dynamic branching that is not expressible as a static computation graph in a numerical definition. The README directs users toward EXGBoost for those cases. New algorithm contributions to Scholar are accepted only when the implementation fits entirely inside a defn block.

Adding Scholar to a Mix Project or Notebook

For a standard Mix project, add Scholar and an Nx backend to the deps function in mix.exs:

def deps do
  [
    {:scholar, "~> 0.3.0"},
    {:exla, ">= 0.0.0"}
  ]
end

Then configure EXLA as the default backend and compiler in config/config.exs:

import Config
config :nx, :default_backend, EXLA.Backend
config :nx, :default_defn_options, [compiler: EXLA, client: :host]

The client key accepts :cuda and :rocm in addition to :host. For a Livebook or other code notebook, use Mix.install instead:

Mix.install([
  {:scholar, "~> 0.3.0"},
  {:exla, ">= 0.0.0"}
])
Nx.global_default_backend(EXLA.Backend)
Nx.Defn.global_default_options(compiler: EXLA, client: :host)

If setting a global default compiler is not possible, the README shows how to JIT-wrap a specific function call: EXLA.jit(&Scholar.Cluster.AffinityPropagation.fit/1). This applies compilation only to that call without affecting the rest of the application.

Algorithm Scope and Deliberate Exclusions

Scholar covers a broad range of classical algorithms across several categories. The README names classification, regression, clustering, dimensionality reduction, metrics, and preprocessing as the included areas. The benchmarks/ directory suggests performance comparisons are tracked, and the notebooks/ directory contains worked examples.

The exclusions are principled, not arbitrary. Any algorithm that depends on dynamic control flow (loops whose iteration count depends on data values at runtime) is excluded because it cannot be implemented as a static Nx computation. Decision trees are the canonical example named in the README. For Elixir developers who need tree-based models, the README specifically names EXGBoost as the appropriate library.

Contributions must also meet the defn constraint. The README points to a specific pull request (elixir-nx/scholar#314) as a reference implementation showing the expected code structure. Tests should verify that the implementation still works when wrapped in a Nx.Defn.jit/2 call.

Scholar vs. Python scikit-learn for Elixir Deployments

scikit-learn is the standard Python classical ML library, covering a similar algorithm set plus decision trees, random forests, and gradient boosting. For Elixir deployments, using scikit-learn requires running a Python process alongside the Elixir application, communicating over an inter-process boundary, and managing two separate runtimes and dependency trees.

Scholar runs in the same Elixir process, shares memory with the rest of the application, and produces Nx tensors that other Nx-based libraries (including Axon) can consume directly. The GPU execution path through EXLA is also shared with Axon, so a team that trains a neural network and then applies a preprocessing pipeline can use the same hardware without configuration changes.

The gap is the algorithm catalog. scikit-learn includes tree-based models, ensemble methods, and a larger set of preprocessing utilities. Scholar's catalog is narrower, constrained to algorithms that fit the defn model.

Apache-2.0 License, No Releases Tagged

Scholar is licensed under the Apache License 2.0. The repository does not have tagged GitHub releases; version tracking happens through Hex.pm, where the package is published as scholar with a current version of ~> 0.3.0 per the README installation instructions. The last push to the repository was on 2026-09-24, which is consistent with active development.

For teams upgrading, the CHANGELOG.md in the repository root is the most direct source of breaking-change information. The library is part of the elixir-nx organization, which maintains Nx and Axon alongside Scholar, so ecosystem compatibility is coordinated within the same GitHub organization.

Editorial conclusion

Scholar is the right choice for Elixir teams that need classical machine learning in the same process as their application code, with the option of GPU acceleration through EXLA. It is the wrong choice for teams that need decision trees, random forests, or gradient-boosted models: the README explicitly excludes them because those algorithms cannot be expressed as Nx numerical definitions. Before adopting Scholar, confirm that your algorithms are available in the library and that JIT compilation via EXLA is configured, since the README warns that loop-heavy algorithms are significantly more memory intensive without it.

Frequently asked questions

Official sources

1. elixir-nx/scholar on GitHub
2. Issues
3. License: Apache-2.0
4. README