Crates and workspaces in Rust

lib.rs and main.rs

A crate can hold both a library and a binary. Library code lives in lib.rs with public functions, and the binary in main.rs calls into it.

This split lets tests and other binaries reuse the same core while each entry point stays thin.

pub fn double(n: i32) -> i32 { n * 2 }

The double function is library code open to every caller. Binaries import it by crate name and focus on arguments, output, and exit codes.

Workspace sketch

A workspace groups related crates under one root manifest. Members share a lock file and a target folder while keeping their own sources and tests.

Reach for a workspace when a tool and its library evolve together but should version and build as neighbors.

[workspace] members = ["app", "tools"]

The sketch lists two member crates side by side. Cargo commands at the root can build, test, and check every member at once.

No deps yet

No third party code is needed for this course stage. The standard library covers vectors, strings, maps, and tests, so the manifest lists zero dependencies.

Learning std first builds judgment for later picks, when each added crate must earn its place in the build.

fn main() { let v = vec![2, 1, 3]; println!("stdlib only"); }

Every lesson so far runs on std alone. Add outside crates only when a real task outgrows these built in tools.

crates.io concept

The crates dot io registry shares libraries across the Rust world. Publishing wraps a tested crate with docs and a version number so others can depend on it.

Browsing well known crates teaches naming and API habits, and local practice comes first before any publish step.

For now treat publishing as a finish line: clean code, clear docs, steady tests, and only then a shared release.

Next: Testing

Article author: Arthur Isaev