Rust workspaces and dev containers help tame growing codebases

When a Rust crate stops being tidy

The first thing that breaks in a successful Rust project is usually not the compiler. It is the mental model. Once a crate turns into a multi-contributor codebase with more than one executable, the real job is no longer “make it work,” but “make it obvious where everything lives.” Sylvain Kerkour’s point is blunt: if someone opens the root folder and does not feel at home right away, the project is already accumulating friction.

That is why the strongest Rust teams treat structure as a feature. The Rust Book says organizing code becomes increasingly important as programs grow, and that advice lands harder once a repository starts carrying feature work, maintenance, and review churn at the same time. Rust gives you strong building blocks, but it does not automatically impose order on a sprawling repo.

Start with a reproducible environment

The cleanest way to keep a growing Rust project from becoming tribal knowledge is to make the build environment boring. Kerkour recommends starting with a development container, or at least a Dockerfile, so contributors and automated agents are working in the same controlled setup. Dev containers are meant to provide a full-featured, consistent development environment, and they can also support CI and testing, which makes them a practical answer to the usual “it works on my machine” drift.

That matters more than it sounds. A repo that depends on undocumented local setup becomes harder to review, harder to debug, and harder to hand off. Visual Studio Code and the Development Containers community have made this pattern familiar enough that it no longer feels exotic, which is exactly the point: if the environment is predictable, the codebase can stay focused on code.

Use a workspace before the repo turns into a pile

Once the project grows past a single crate, workspaces are the natural next step. Cargo’s workspace model is a collection of packages managed together, with one shared Cargo.lock file and one shared target directory across workspace members. The Cargo Book also makes it clear that workspace-wide commands can run across every member, including cargo check workspace, which is a simple but powerful way to keep the whole tree healthy.

That is why the typical layout in larger Rust systems tends to look familiar: executables at the top level, with reusable libraries living in a libs or crates directory. The shape is boring on purpose. It separates the things that are shipped from the things that are shared, and it keeps responsibilities visible instead of scattering them across one giant crate with a long module tree.

A layout that scales without surprise

A good workspace does not just reduce compile pain. It makes the repository navigable. When the top level contains the binaries and the shared code is gathered into obvious library crates, contributors spend less time hunting through source and more time understanding the boundaries between products, shared logic, and internal helpers.

That boundary is especially useful when a project has multiple executables. If each app reaches into the same pile of modules, the codebase starts to depend on memory instead of structure. Split crates force harder decisions, which is usually what a project needs once more than one person is shipping into it.

Let dependencies inherit, instead of copy-pasting them

Dependency hygiene becomes a real maintenance issue once a workspace passes a dozen crates. Hand-syncing versions across member crates is tedious, and tedious is just another word for drift. Cargo now supports [workspace.dependencies], and member crates can opt in with workspace = true, which gives the whole repository one place to define shared dependencies.

The payoff is not only less repetition. It is consistency. If the same dependency version is declared in one place, review gets easier and upgrade work becomes much less error-prone. The same idea applies to the rest of the workspace settings: Cargo’s documentation says [patch], [replace], and [profile.*] sections are only recognized in the root manifest, so the root file should carry the policy and the members should consume it.

Resolver rules are part of the contract

Cargo’s resolver behavior is also a workspace-level concern. The Rust Edition Guide says resolver is a global setting for a workspace, and in Rust 2024, writing edition = "2024" in Cargo.toml implies resolver = "3". That is the sort of detail that only becomes important when a project crosses the line from “small and obvious” to “large enough that one crate’s settings can affect everybody else.”

For maintainers, the practical lesson is simple: treat the root manifest as the control plane. If the root is messy, the workspace will be messy. If the root is disciplined, individual crates can stay focused on their own jobs.

Error handling needs the same discipline as layout

The article’s larger warning is that code organization and error strategy tend to fail together. Rust’s Error Handling Project Group was announced on September 18, 2020, with Jane Lusby and Sean Chen named as shepherds, Andrew Gallant as an advisor, and Ashley Mannix as the library team liaison. That is a signal that the ecosystem has been thinking about this problem seriously for years, not just at the style-guide level but as part of the language’s growth.

The takeaway for a multi-crate codebase is to avoid improvising error patterns crate by crate. Once teams start duplicating ad hoc error enums and inconsistent recovery paths, review gets harder and failures become harder to reason about. A shared approach to error types, naming, and propagation keeps the architecture legible, which is exactly what you want when the codebase is large enough that no single person can hold it all in their head.

Review hygiene is how structure survives contact with reality

Good structure only matters if people keep using it. That means reviews need to enforce the boring conventions the workspace depends on: shared dependencies belong in the root, new crates need a clear place in the tree, and modules should follow the boundaries the repo already advertises. Kerkour’s deeper argument is that teams should pay down this kind of technical debt before it compounds, because a codebase that is easy to understand stays easy to change.

That is the real value of the dev container plus workspace combo. The container makes the environment reproducible. The workspace makes the repository legible. Together, they give teams room to split responsibilities without turning the project into a maze of local setup, duplicated versions, and brittle assumptions.

When a Rust project succeeds, the first danger is not that it becomes too big to compile. It is that it becomes too big to recognize. The root folder should still feel like a place you know your way around, and the best time to protect that feeling is before the crate stops being neat.