num is a meta-crate that pulls six numeric crates into one dependency

One dependency over six crates

num is a collection of numeric types and traits for Rust, and it covers three kinds of thing. New types for big integers, rationals, which it also calls fractions, and complex numbers. New traits for generic programming on numeric properties like Integer. And generic range iterators.

The way it is packaged is the part to understand. num is a meta-crate, re-exporting items from sub-crates, and there are six of them in the table: num-bigint, num-complex, num-integer, num-iter, num-rational and num-traits. Each has its own repository, its own crate and its own documentation.

A seventh, num-derive, is listed in the table for reference but is not directly included in num. It is a proc-macro crate for deriving some of num's traits, and the note in the readme says so explicitly, which saves you from wondering why the derive is missing when you look for it in the meta-crate.

So the ecosystem is a family of small crates, each usable on its own, with a convenience crate on top for people who want the lot. The meta-crate is not the interesting part of the design; the split into focused crates is.

The implementation language is Rust, the licence is Apache-2.0 or MIT at your option, and the last push was on 2026-07-07. The package version is 0.4.3 on edition 2021.

Adding it is one line

The Usage section is the shortest possible instruction.

[dependencies]
num = "0.4"

That is the whole integration for a project that wants the standard library behaviour, which is the default.

The interesting part is what happens when you want less. This crate can be used without the standard library, with the no_std attribute, by disabling the default std feature, and the readme gives the Cargo form for that.

[dependencies.num]
version = "0.4"
default-features = false

And then the constraints on what you can have in that mode. The num-bigint crate requires the std feature, or the alloc feature may be used instead with Rust 1.36 and later, and other sub-crates may also have limited functionality when used without std.

That last sentence is the one to read carefully in a no_std project. The meta-crate itself builds without the standard library, but the individual pieces degrade, and a project that turns off std and then uses a big integer will find that num-bigint needs alloc.

The alloc feature is defined in the manifest as pulling in num-bigint and num-rational with the bigint standard library, and the libm feature enables the Float trait and the related Complex methods using pure-Rust floating point implementations.

The features, and the advice to depend on the sub-crates directly

There are five features, and their definitions in the manifest are more informative than their names.

The rand feature enables randomization traits in num-bigint and num-complex. The serde feature enables serialization for the types in num-bigint, num-complex and num-rational. The libm feature turns on the Float trait and the related Complex methods for builds with no standard library.

Then there is the sentence that changed the meta-crate's behaviour.

The num meta-crate no longer supports features to toggle the inclusion of the individual sub-crates. If you need such control, you are recommended to directly depend on your required crates instead.

That is a real behavioural change and it is the main practical thing to know about this crate. An older version of num let you ask for num-bigint and not num-complex, and now the flags are for behaviour, not for presence. If your dependency graph is trying to trim the sub-crates, the answer is to stop using the meta-crate and depend on num-bigint, num-rational and the rest by name.

The std feature in the manifest shows the coupling, listing dep:num-bigint along with the std feature of each sub-crate, and the alloc feature lists dep:num-bigint with num-rational/num-bigint, which is the arrangement that lets a no_std build keep the rational type without the big integer standard library support.

The rand and serde features are optional in the same way, using the question mark form so that they do not pull the sub-crate in if you have not enabled the feature.

What each sub-crate is for

The table in the readme is a list of names, and each one is a distinct problem.

num-traits is the foundation, holding the traits the others are written in terms of, the ones like Integer, Signed, Zero, One and the numeric primitives that let generic code be written once.

num-bigint is the arbitrary precision integer type, the answer to the fact that Rust's primitive integers have a fixed width.

num-rational is the exact fraction type, so a value like a third stays a third rather than becoming a float that is close to one.

num-complex is complex numbers, with the same generic treatment, so they work with the traits rather than being a separate island of the crate.

num-integer provides the integer traits, Integer and the related ones, and the generic range operations over them.

num-iter provides generic range iterators, which is the piece that lets you write a loop over a range of any integer type rather than only over the primitives.

The relationship between them is the usual one in a well factored Rust project. The traits do not depend on the types, the types implement the traits, and the iterator crate is generic over both, so a range of BigInt works the same way a range of i32 does.

For anyone deciding which crate to depend on, this is the whole decision: if you want a trait to write generic code against, take num-traits, and if you want a type, take the one that has it.

Compiler compatibility is tested per crate, not per meta-crate

The compatibility section is short and has a distinction that is easy to miss.

The num crate as a whole is tested for rustc 1.60 and greater. The num-traits, num-integer and num-iter crates are individually tested for rustc 1.8 and greater, if you require such older compatibility.

So the meta-crate carries the higher floor and the three older crates carry a much lower one, and the badge in the readme reflects the 1.60 figure for the crate you are reading about.

The practical implication is that a project pinned to an old compiler can still use the traits and the integer traits and the iterators, as long as it does not go through the umbrella. That is another reason the readme's advice to depend on the sub-crates directly is practical advice rather than a style preference.

The other version number in the readme is the alloc one. The num-bigint crate requires the std feature, or the alloc feature may be used instead with Rust 1.36 and later, so the floor for a no_std big integer is 1.36 rather than 1.60.

The build badge in the readme points at a GitHub Actions workflow for the main branch, and the documentation badge points at docs.rs, which is where the generated API documentation for each of the seven crates lives.

Licensing, releases and the CI directory

The licensing arrangement is the standard Rust dual licence.

Licensed under either of the Apache License, Version 2.0, or the MIT license, at your option. And the contribution note says that unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work, as defined in the Apache-2.0 licence, shall be dual licensed as above without any additional terms or conditions.

Both licence texts are in the repository, as LICENSE-APACHE and LICENSE-MIT, and the manifest records the choice as MIT OR Apache-2.0, which is the form Cargo uses to express a dual licence.

The contribution sentence is worth reading because it is more precise than the usual phrasing. It ties the default to the Apache definition of a contribution, and it says the dual licensing applies without additional terms, which is what lets a project accept patches under one licence and ship under both.

The release history is in RELEASES.md rather than in the repository's tags, and the top level listing is minimal. There is Cargo.toml, the two licence files, the README, RELEASES.md, a src/ directory, a ci/ directory, and the GitHub configuration. The exclude list in the manifest keeps the ci/ directory and the .github/ directory out of the published crate, so the published artefact is the library and nothing else.

The documentation metadata in the manifest is a nice touch for a library with optional features. The docs.rs metadata lists the features to build the documentation with, which are std, serde and rand, so the hosted documentation shows the types with their serialisation and randomisation support rather than a stripped build.

Editorial conclusion

Adopt num when you want big integers, rationals or complex numbers in Rust and would rather have one dependency than five, and you are happy with the standard library by default. Do not adopt it if you need to switch individual sub-crates on and off, because the meta-crate no longer supports that and the readme tells you to depend on the crates you need directly. Verify first which features you need, since num-bigint requires the std feature or alloc with Rust 1.36 and later, and that your compiler is 1.60 or newer for the crate as a whole.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. rust-num/num on GitHub