GoMLX: an accelerated machine learning framework for Go, with XLA, ONNX and pure-Go backends
GoMLX: An Accelerated Machine Learning Framework For Go
At a glance
- What is it?
- GoMLX gives Go programs a differentiable operator set, three interchangeable execution backends and HuggingFace model loading. It is the closest thing Go has to a Jax or PyTorch, and it comes with the usual cost of working in a compiled language.
- Who is it for?
- Adopt GoMLX when your model has to live inside a Go service, when you want a single static binary instead of a Python runtime, or when you need to fine-tune a HuggingFace checkpoint and ship the result as .onnx. Do not adopt it if you need the breadth of the PyTorch ecosystem, if your team cannot read Go, or if you expect a stable API across minor versions: the v0.28.0 release notes describe a large API update.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap GoMLX fills for Go services that need a model
Go has a long list of libraries for calling a model. It has very few for building one. The README positions GoMLX as "a PyTorch/Jax/TensorFlow for Go", and that framing is the honest one: the project is not a wrapper around an inference runtime, it is a differentiable operator set with a training loop on top.
The intended user is a Go engineer who already has a service and does not want to add a Python process to it. The README states the project was developed to be a "full-featured ML platform for Go, productionizable and easy to experiment with ML ideas", and it is explicit about the trade-off: it strives to be simple to read and reason about, "at the cost of more typing (more verbose) at times".
That verbosity is a design decision, not an accident. A framework that hides its graph behind implicit magic is hard to debug when gradients go to zero. GoMLX opts for code you can step through in a debugger. The repository layout reflects the split: core/ for the graph and operators, ml/ for training and model layers, backends/ for the execution engines, and examples/ for runnable models. The README also notes the project is "still only a slice of what a major ML library/framework should provide", which is a fair self-assessment.
Three backends behind one API, and what each one costs you
The central architectural claim is a common backend API. GoMLX defines the computation once and hands it to one of three engines.
The pure Go backend is portable and, per the README, also runs in WASM in a browser. It has been heavily optimized: the release notes claim it "closely matching xla:cpu speeds for FNN models", with improved buffer management, reduced synchronization costs and broadened SIMD support using go1.27 portable simd. The README is candid about the limit: matrix multiplications are architecture dependent, and only AVX2 and AVX512 were optimized so far, with the microkernel written in assembly because of pending go simd issues. Apple hardware is not covered, and the README asks for donations to add Neon kernels.
The xla backend is the optimized path, built on OpenXLA with just-in-time compilation to CPU, Nvidia GPUs, likely AMD ROCm, Intel, Macs and Google TPUs. It is the same engine behind Jax, TensorFlow and PyTorch/XLA. Distributed execution for multi-TPU or multi-GPU uses XLA Shardy, and the README flags it as "new, still being actively improved".
The onnx backend runs computations through ONNX Runtime with onnx:cpu, onnx:cuda and onnx:rocm variants, plus onnx:wasm, webgpu and an experimental webnn for the browser. It can also write a model to a .onnx file, which is the escape hatch: you can train in GoMLX and serve the artifact with a different inference system entirely.
Getting GoMLX into a Go module and running a first example
The module path is github.com/gomlx/gomlx and go.mod declares go 1.27, so the toolchain requirement is the first thing to check. The README points readers to the documentation site at gomlx.github.io, the pkg.go.dev reference for the module, and a tutorial notebook, rather than to a package manager command.
The repository ships runnable examples under examples/, each with its own module. The README links the MNIST demo as the library and command-line example, and the examples directory also contains linear, cifar, imdb, gpt2, gemma3, bert-base-ner, inceptionv3, mxbai-rerank and others. Those directories are the concrete starting points; open the one closest to your problem and read its go.mod and main file before writing your own architecture.
For the notebook workflow, the README links a Docker image at janpfeifer/gomlx_jupyterlab, which is how the published notebooks are meant to be run. If you only want the plotting and progress tooling that the training loop uses, the relevant dependencies are already in the module graph rather than something you install separately.
For a model that already exists, the README states GoMLX reads models from HuggingFace with a growing list of supported architectures. The examples directory is where those architectures appear as runnable code.
Where GoMLX is the wrong tool
The pure Go backend is the sharpest limitation, and the README states it plainly. Matrix multiplication optimization covers AVX2 and AVX512 only. On an Apple Silicon laptop you are running unoptimized kernels, and the project is asking for hardware donations to fix that. If your workload is dominated by large matmuls on ARM, the xla or onnx backend is not optional.
Distributed execution is a second soft spot. The README labels multi-GPU and multi-TPU support as new and still being actively improved, which is not the same as production-hardened. Anyone planning a multi-node training run should treat that as a research path, not a supported one.
The API itself moves. The v0.28.0 release is titled "Large API update; Lots of new features", and v0.28.11 changed backends and dynamic shapes. Pinning a version and reading its release notes is not optional hygiene here. And the framework is a slice, not a superset: the README says so directly. If your project depends on a specific PyTorch layer, a niche optimizer from a research repo, or a data pipeline from the Python ecosystem, you will be reimplementing it. GoMLX is the wrong choice when the model is the hard part and the language is incidental.
GoMLX against Gorgonia and the Python-first frameworks
The closest Go-native comparison is Gorgonia, which also builds computation graphs in Go. The difference in approach is the backend. Gorgonia carries its own execution engine and does not target OpenXLA, so it does not inherit JIT compilation to TPUs or the Shardy distribution work. GoMLX treats the engine as a swappable component and ships three, which is why the same model code can run in a browser through WASM and on a TPU through xla.
Against Jax, TensorFlow and PyTorch the difference is inverted. Those frameworks have the ecosystem, the pretrained model zoo and the hiring pool. GoMLX has the deployment story: a Go binary, no Python runtime, and the option to export .onnx so inference can happen somewhere else. The README's own comparison is that GoMLX uses the same engine as those frameworks "and it has the same speed in many cases", with an asterisk the README does not expand on. Treat that as a claim about the engine, not a benchmark you can rely on for your model.
The ONNX backend is the pragmatic middle ground. It lets GoMLX act as a training and authoring front end while ONNX Runtime handles serving, including through third-party Go inference libraries that accept .onnx files.
Licence, release cadence and what upgrading costs
GoMLX is Apache-2.0, which permits commercial use, modification and redistribution with the usual notice and patent terms. That is a permissive licence and it is the same one used by much of the Go ecosystem, so it rarely blocks adoption. This is not legal advice; check the LICENSE file in the repository for the binding text.
The maintenance picture is concrete. The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.27.3 on 2026-04-16, v0.28.0 on 2026-07-21 and v0.28.11 on 2026-09-08. The version numbers are still below 1.0, and the release titles say why that matters: v0.28.0 is described as a large API update. Upgrading across a minor version can mean touching call sites.
The dependency surface is another cost. go.mod requires github.com/gomlx/compute, github.com/gomlx/compute-onnx, github.com/gomlx/go-xla and github.com/gomlx/bsplines, plus plotting and terminal libraries. Those are maintained under the same organization, which keeps version skew manageable, but it does mean a GoMLX upgrade can pull a chain of related modules. Budget for reading the release notes on each of them, not just the top-level tag.
Editorial conclusion
Adopt GoMLX when your model has to live inside a Go service, when you want a single static binary instead of a Python runtime, or when you need to fine-tune a HuggingFace checkpoint and ship the result as .onnx. Do not adopt it if you need the breadth of the PyTorch ecosystem, if your team cannot read Go, or if you expect a stable API across minor versions: the v0.28.0 release notes describe a large API update. Before committing, check that the backend you intend to use is the one whose tests you can run, and read the release notes for the version you pin, because the backend set changed in v0.28.11.
Frequently asked questions
Which ML library is made by Google?
GoMLX is not a Google product, but its xla backend is built on OpenXLA, the same engine that powers Google's Jax and TensorFlow. The README describes that engine as using just-in-time compilation to CPU, GPUs and Google's TPUs.
Is Go worth learning in 2026?
GoMLX is written in Go and declares go 1.27 in its go.mod, and its README argues that keeping the framework simple to read and reason about is aligned with Go philosophy, at the cost of more verbose code. Whether the language is worth learning is outside what the repository documents.
Can I learn ML in 3 months?
The repository does not make claims about learning timelines. It does provide a tutorial and a guided Dogs vs Cats example at gomlx.github.io, plus runnable examples under examples/ such as linear, mnist and cifar, which are the entry points the project offers.
Is Go harder than C++?
The README says GoMLX aims to be simple to read and reason about, leading the user to a correct and transparent mental model, at the cost of more typing at times. It does not compare Go with C++.
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/gomlx-gomlx)