I recently published matten, a small Rust library for working with multidimensional arrays. This is the first of four short posts introducing it. This one is about why it exists.
Rust is a great language for numerical and data-oriented work. But starting that work — just getting to the point where you have a matrix and can add two of them together — takes more effort than it probably should at the prototype stage.
The established libraries are capable and well-maintained. If you need performance, reach for ndarray or nalgebra. They are the right tools for production numerical code.
But they come with a learning curve: generic type parameters, storage abstractions, view types, lifetime considerations. That overhead is often worth it. It is not always worth it on day one of a proof of concept.
The gap matten fills is narrow and deliberate: making early-stage numerical Rust work feel less ceremonial, so you can spend the first hour on the problem rather than on the type system.
The project description borrows a modest analogy: a family car. Easy to get into, predictable to drive, comfortable enough for most everyday trips. Not a racing car. Not trying to be one.
Concretely that means:
- One primary public type,
Tensor, with no generic parameters. - No user-visible lifetimes in ordinary usage.
- Human-readable error messages when shapes do not match.
- JSON and CSV support on by default, for moving data in and out without ceremony.
#![forbid(unsafe_code)]throughout.
What it does not mean: faster than the alternatives on hot paths. The library is explicit about this. When a prototype grows into something performance-critical, the right move is to migrate that part of the work to a more capable library. matten-ndarray exists specifically for that handoff, and the flat Vec<f64> storage makes the data easy to move.
P.S. — The name is from mathematical tensor NOT 😜 It’s from a Japanese charming dialect meaning “waited for”. We took our time, and so can you.
Links: crates.io · docs.rs · mdBook · repository