T-Ruby is Ruby with syntax for types

Original Article ↗ Hacker News Discussion ↗

Motivations for Types in Ruby and Other Dynamic Languages

  • Large, long-lived Ruby/Python/Rails codebases become hard to reason about; types help document function boundaries, clarify “what this argument/return value actually is,” and reduce “pinballing” through call sites.
  • Progressive typing lets teams add safety without rewriting into another language or retraining on a new stack.
  • Types improve editor/IDE/LSP features (autocompletion, navigation, inline docs) and help static analysis/LLMs understand APIs.
  • For some, static typing in other languages (Go, C#, TypeScript) proved to speed teams up on larger systems, especially by eliminating whole classes of tests for “what if this is the wrong type?”
  • Type info can also benefit Ruby JITs (YJIT/ZJIT) by enabling better specialization and optimization.

Critiques of Gradual Typing and Typed Ruby

  • Several argue gradual typing “combines the worst of both worlds”: added complexity and verbosity, but without the performance/lowering-of-abstraction benefits of a natively static language.
  • Dynamic Ruby with good tests, naming, and REPL use is seen as sufficient by some; type-related bugs are described as rare compared with the overhead and friction of annotations.
  • Aesthetic objections: inline annotations are viewed as making Ruby “objectively uglier,” undermining one of the language’s main appeals.
  • There’s concern that complex type definitions (unions, nested structures) slow development and encourage rewriting code to satisfy the checker rather than the domain.
  • Some see the push for types as cultural carryover from statically-typed backgrounds rather than an intrinsic Ruby need.

T-Ruby Itself: Design, Issues, and Comparisons

  • Positively received for:
    • Translating to standard Ruby plus RBS, integrating with existing tooling.
    • Clear documentation and a more unified, syntax-level approach compared with Sorbet/RBS separate files and DSLs.
  • Criticisms/questions:
    • Handling of keyword arguments is confusing/buggy in the playground; docs and behavior appear inconsistent.
    • Limited or unclear support for metaprogramming patterns (define_method, dynamic instance variables).
    • Playground currently accepts syntactically invalid input, suggesting tooling immaturity.
  • Compared frequently with Crystal (“Ruby-like with types”), Sorbet, RBS-inline, and low_type; consensus is that Crystal is not a drop-in “Ruby with types” but a different language with similar syntax.