Native Physics & Units Support in Rust’s Type System for Safer System-Level Software

community
1

Modern system-level software increasingly interacts with the physical world — aerospace systems, satellites, robotics, EDA tools, high-performance computing, scientific simulations, and embedded control systems.

Historically, some major engineering failures were caused not by logic errors, but by unit mismatches or incorrect physical assumptions (for example, the Mars Climate Orbiter incident).

Rust provides strong memory safety and type guarantees, but physical quantities are still typically represented as plain numeric types (f32, f64, etc.), relying on developer discipline to ensure correctness.

Proposal: Dimensionally-Aware Numeric Types

What if Rust supported units-aware types at the language level (or via an officially supported approach)?

Example:

let distance: Length<meter> = 100.0;
let time: Time<second> = 9.58;
let speed = distance / time; // Velocity<meter_per_second>

Invalid operations could be rejected at compile time:

let invalid = distance + time; // compile-time error

Why This Matters

Such support could significantly improve safety and correctness in domains like:
Aerospace and satellite software
Robotics and autonomous systems
Electronic Design Automation (EDA)
Physics simulations
High-performance computing
Embedded control systems
Navigation and energy systems
Advanced graphics and engine mathematics
These areas are often dominated by C/C++ despite their weaker safety guarantees.
Rust could become a strong candidate for physically grounded, safety-critical computing.

Existing Approaches and Limitations

There are existing crates that implement units-of-measure systems, but they often face challenges:
Verbosity and ergonomics issues
Fragmentation across ecosystems
Lack of standardization
Integration friction between libraries
Adoption barriers
A widely accepted approach could improve consistency across projects.

Possible Implementation Directions

Not proposing a specific design, but potential avenues include:
Const generics for dimension tracking
Compile-time dimensional analysis
Zero-cost abstractions
Optional standard library support
Compatibility with existing numeric types
Support for SI and custom units

Long-Term Potential

If done well, this could help Rust become a leading language for:
•Safety-critical infrastructure
• Scientific and engineering platforms
• Hardware-adjacent software
• Mission-critical control systems

In short: software where physical correctness matters as much as memory safety.

I would appreciate insights on:
• Feasibility within Rust’s current type system
• Tradeoffs vs purely library-based solutions
• Ergonomic considerations
• Whether an official crate would be sufficient
• Relevant prior work or ongoing efforts
Thank you for reading, and I welcome any feedback or pointers.

2

What is wrong with crates that do this, such as uom and measurements? I would expect any serious proposal to list prior art and why those solutions aren't satisfactory.

8 Likes
4

If this is "optional", what's the other option? A library? We already have those. Baking this into std would come with a number of drawbacks:

  • A perma-stable API: it wouldn't be able to evolve with Rust
  • "One-size-fits-all": if you and I need different things out of the system... too bad! There would inevitably be months or years of bikeshedding and heavy debate around the specifics
  • Limited scope: depending on the exact implementation details, there would be a fixed number of available units and measurements available to use. If it allowed adding your own, then we're right back to your problem state of integration hell
  • Additional cost: every bit that gets baked into Rust as a language, instead of being left as a 3rd party crate, detracts from the very limited resources the maintainers have to spend on the rest of the language
1 Like