Show HN: Numbat – A programming language with physical dimensions as types
A new language called Numbat aims to treat physical dimensions and units as types, enabling compile-time checks that catch errors like adding meters to seconds or misusing constants in physics formulas. Commenters compare it to unit systems in F#, Rust, Julia, C++, Nim, Ada, and tools like GNU Units and Frink, weighing the benefits of a dedicated, statically typed DSL against libraries embedded in general-purpose languages. They also probe harder edge cases—such as calendar vs. chronological time, currency conversion, and unitful linear algebra—highlighting where the approach is powerful today and where the type system and libraries would need to grow.
Scope of “physical” units and dimensions
- Debate over whether light, temperature, and time are “physical” vs only spatial; consensus in thread leans toward “physical” meaning “described by physics,” not just 3D space.
- Relativity and four-vectors are mentioned to argue that time is tightly coupled to space.
- Some push back on fringe physics claims that challenge spacetime, noting they’re not mainstream.
Existing ecosystems and “reinventing the wheel”
- Many point out similar unit/dimension systems: Python (Pint, astropy.units), F# Units of Measure, Rust’s
uom, Julia’s Unitful.jl, Scala’s Squants, Nim (Unchained), GNU units, Ada’s dimensionality analysis, C++ template-based units, Frink, and previous project Insect. - Some argue Numbat is redundant; others note that being purpose-built, static, open source, and targeting WebAssembly gives it a niche.
Type system, math functions, and angles
- Trig and transcendental functions in Numbat only accept dimensionless scalars; passing unitful quantities is treated as likely an error.
- Angles are treated as convertible to scalars (radians, degrees, turns); there is explicit acknowledgment that whether angles are dimensionless is debated.
Time, months, and years
- Months and years are modeled as averaged durations (e.g., Gregorian year ≈ 365.2425 days).
- Several commenters call this ambiguous “unit confusion” and distinguish “chronological” vs “calendrical” units, noting leap days, leap seconds, DST, sidereal vs tropical year, etc.
- Others defend the simplified approach as pragmatic and warn against dragging full calendar complexity into the type system.
- Numbat currently treats time as durations, not calendar dates; no “today + 14 days” style calendar API exists yet.
Linear algebra and heterogeneous units
- Classic difficulty: vectors/matrices where each component has different units (e.g., economic input–output models, derivative operators).
- Numbat currently lacks aggregate types (vectors, matrices). The problem is acknowledged as solvable but “tricky.”
- Discussion notes that many static type systems assume homogeneous units per container, which clashes with real-world linear algebra.
Currency and real-world modeling
- Currency is supported as a unit with live exchange rates from the European Central Bank.
- Some see this as a neat feature; others view it as shallow compared to the complexity of real finance/economics.
Ergonomics, syntax, and enthusiasm
- Positive comments on the interactive CLI, rich unit catalog, Unicode operators (×, ⋅, ÷), and readable introduction.
- Some users express strong enthusiasm and support, including sponsorship, and see Numbat as an excellent calculator/DSL for unit-aware computation.