Show HN: Kotlin Money

Original Article ↗ Hacker News Discussion ↗

Kotlin as a Language / Paradigm

  • Multiple comments debate whether Kotlin is “multi‑paradigm” vs “Java but nicer.”
  • Some see it as balanced OOP + FP, comparable to but less functional than Scala; others say it’s primarily OOP/imperative with some functional features bolted on.
  • Kotlin’s syntactic features (infix functions, extension methods, DSL‑like code) are praised by some for expressiveness and by others criticized as hard to read and prone to bikeshedding.
  • There’s concern that Kotlin’s many optional features complicate team code style, especially compared to Java.

Design of the Money Library / API

  • Uses BigDecimal for internal calculations; focus is on a clean, domain‑oriented API first, optimization later.
  • Supports operations like percentage increases/decreases, allocation of amounts with remainder distribution, and configurable rounding using currency minor units and a default HALF_EVEN rule.
  • Mixing different currencies in arithmetic throws at runtime; some suggest encoding the currency as a type parameter to catch this at compile time.
  • Several commenters dislike the heavy use of infix and numeric extension functions (1.25.percent(), 100 money "USD"), preferring more conventional constructors or operators.

Rounding, Minor Units, and Edge Cases

  • Cash rounding rules (e.g., to nearest 5 cents, 1/100 vs 1/1000 units, gas prices with extra decimals) are highlighted as complex and often country‑ or payment‑method‑specific.
  • Current library does not model cash‑only rounding schemes, but allows custom currencies and configurable minor units.
  • Parsing preserves extra digits; rounding is applied when performing operations, not on input.

Currencies, Localization, and Data Sources

  • Library embeds ISO currencies and cryptocurrencies, using CLDR/ICU datasets; future work is planned for proper localization of symbols and formats.
  • Maintaining up‑to‑date currency lists and rules is seen as hard; some argue this belongs in libraries, not the language core.

Comparison to Other Money / Decimal Solutions

  • Thread references JSR‑354/Moneta, Joda Money, Evans’ Time & Money, C# Decimal, Java BigDecimal, various language “money”/decimal/units systems, and crypto‑oriented libraries.
  • Consensus: decimal/BigDecimal is necessary but not sufficient; a good money library must also encode currency, rounding, allocation, and often FX logic.