Ruby (4.0)

This assessment applies the coupling account — coupling as access to a shared resource, and the coupling floor [1], [2] — and the knowledge-embodiment theorem [3]; the language is assessed against its official reference [4].

Analysis against Ruby 4.0 (December 2025). YJIT is production-ready since Ruby 3.2+.

1 Assessment

This page assesses Ruby in five parts: core coupling — what the language’s own constructs force; ecosystem coupling — what the surrounding platform, tooling, and community cost; engineering readiness — whether the artifact can be reproduced, verified, observed, worked in quickly, connected to other languages, and governed openly; the profile — the unscored facts a score cannot express; and the scoring detail — the mechanism marks and the arithmetic behind every score. A ✅ bullet marks a construct that helps. A ⚠️ or ❌ bullet marks a cost; the scoring model does not price every cost named here.

Core coupling 28/100 · Ecosystem coupling 58/100 · Engineering readiness 88/100

1.1 Core coupling

1.1.1 Type

  • ❌ Duck typing: No compile-time type checking, coupling invisible
  • ❌ Pattern matching (3.0+) is not exhaustive: A case/in with no else raises NoMatchingPatternError at run time rather than reporting a missing case
  • ✅ Mixins: Include modules for behavior without inheritance
  • ⚠️ Open classes: Can modify any class, creates action-at-a-distance coupling
  • ⚠️ RBS type signatures: External type system (.rbs files) — static checking via Steep/Sorbet, not built into runtime
  • ✅ Blocks/Procs/Lambdas: First-class functions decouple behavior
  • ❌ Method_missing: Dynamic dispatch hides coupling, runtime failures

1.1.2 Construction

  • ✅ initialize separate from new: Construction logic decoupled
  • ✅ Data.define (3.2+): Immutable value objects like records/kotlin data classes
  • ⚠️ Class methods for factories: Common pattern but not enforced
  • ❌ No validation enforcement: Constructor invariants not checked
  • ❌ Monkey patching: Can modify any class anywhere, global coupling
  • ❌ Global variables: $global creates pervasive coupling
  • ❌ Class variables: @@var shared across all instances, couples classes

1.1.3 Memory

  • ✅ Garbage collection: Automatic, no manual management
  • ⚠️ GC pauses: Non-deterministic, couples performance to runtime (improved by YJIT’s reduced allocation rate)
  • ✅ No manual deallocation: Can’t have use-after-free
  • ✅ YJIT reduces GC pressure: Faster execution means fewer long-lived allocations

1.1.4 Error

  • ❌ Unchecked exceptions: raise doesn’t appear in signatures
  • ❌ Broad rescue: rescue without type catches everything
  • ✅ Pattern matching with => operator (3.0+): Can destructure error objects structurally
  • ❌ Silent failures: Methods often return nil instead of raising

1.1.5 Concurrency

  • ❌ Global VM Lock (GVL): Like Python’s GIL, couples threads to single core
  • ✅ Fibers + Fiber Scheduler (3.0+): Cooperative concurrency with io_uring support for async I/O
  • ✅ M:N thread scheduler (3.3+, experimental → progressing): Lightweight userspace threads
  • ⚠️ Ractors: Actor-like concurrency (3.0+), still evolving
  • ❌ Shared mutable state: No protection, race conditions easy

1.1.6 Platform

  • ✅ No company owns the language: Ruby is developed by the ruby-core community under the Ruby Licence, dual-licensed with the two-clause BSD licence
  • ✅ Several implementations exist: MRI (Matz’s Ruby Interpreter) is the reference implementation, alongside JRuby on the JVM, TruffleRuby on GraalVM, and mruby for embedded use
  • ✅ The runtime is portable: MRI builds on Linux, macOS, Windows through RubyInstaller, and the BSDs
  • ✅ The JVM is an available target: JRuby runs the same language on the Java platform, so Ruby code is not confined to one runtime
  • ✅ Packaging is vendor-neutral: RubyGems and Bundler fetch gems from any repository, not from one vendor’s service

1.1.7 Trade-offs (not coupling)

  • Programmer happiness is the design goal: Ruby favours expressive code over enforcement, a deliberate trade of static guarantees for code that reads like prose
  • Parentheses are optional: The grammar treats a method call and a local variable alike, a readability choice whose cost is ambiguity in dense expressions
  • Everything is an object: Numbers, strings, and classes all respond to methods, a uniform model that removes special-case rules and adds method lookup to every value
  • Visibility is cooperative: private and protected can be bypassed with send, so encapsulation is a convention the language does not enforce — a deliberate openness rather than a dependency

1.2 Ecosystem coupling

1.2.1 Performance

  • ✅ YJIT (production-ready since 3.2): 3-5x speedup in many benchmarks; reduced GC pressure
  • ❌ GVL: Couples multithreading to single core (still present in Ruby 4.0)
  • ⚠️ The JIT is opt-in: YJIT must be enabled with --yjit or RUBY_YJIT_ENABLE=1, so a default run stays interpreted
  • ⚠️ High memory: Object overhead significant (partially offset by YJIT)
  • ⚠️ Optimization hard: Dynamic nature limits static optimization

1.2.2 Ecosystem

  • ✅ RubyGems: Massive ecosystem
  • ⚠️ Rails dominates the ecosystem: Most Ruby applications are Rails applications, so the framework’s conventions and release cycle set the pace for the rest
  • ✅ Bundler: Dependency management works well
  • ✅ IDE support: RubyMine, VSCode good
  • ✅ Rich ecosystem: Mature, well-established

1.2.3 Evolution

  • ✅ Backward compatible: Ruby 2→3→4 mostly smooth
  • ✅ Regular releases: Annual release cycle
  • ✅ YJIT: Major performance investment
  • ⚠️ RBS/Sorbet: Type signatures external, not core language
  • ⚠️ GVL: Still present, no removal timeline

1.2.4 Domain

  • ✅ Excellent for web: Rails is industry standard
  • ✅ Good for scripting: Clean syntax for automation
  • ⚠️ Improved for performance-sensitive: YJIT closes gap but still slower than compiled languages
  • ❌ Not for systems: GC, interpreted, GVL
  • ⚠️ DevOps tools: Chef, Puppet use Ruby

1.2.5 Learning

  • ✅ Very gentle: Readable, intuitive
  • ✅ Principle of least surprise: Design philosophy
  • ✅ Excellent resources: Why’s Poignant Guide, Rails tutorials
  • ✅ Quick productivity: Can build apps immediately

1.2.6 Syntax

  • ✅ Beautiful syntax: Minimal noise, readable
  • ✅ Flexible: Multiple ways to express intent
  • ✅ Blocks: Elegant for DSLs and callbacks
  • ✅ Optional parentheses: Clean, natural language-like

1.2.7 Testing

  • ✅ RSpec, Minitest: Excellent testing frameworks
  • ✅ Pry: Interactive debugger, REPL
  • ✅ Test culture: TDD/BDD strong in Ruby community
  • ⚠️ Runtime errors: No compile-time checks

1.2.8 Security

  • ✅ Memory safe: GC prevents memory bugs
  • ❌ Type confusion: Dynamic typing allows anything
  • ❌ Monkey patching: Can introduce vulnerabilities
  • ⚠️ Rails security: Framework helps, but language-level gaps

1.3 Engineering readiness

1.3.1 Reproducibility

  • ❌ Builds are not byte-reproducible by default.

1.3.2 Supply chain

  • ⚠️ The package registry is a flat name space.

1.3.3 Observability

  • ✅ No charged mechanism in this dimension.

1.3.4 Feedback

  • ✅ No charged mechanism in this dimension.

1.3.5 Interop

  • ✅ No charged mechanism in this dimension.

1.3.6 Governance

  • ✅ No charged mechanism in this dimension.

1.4 Profile

Unscored, and kept separate from every score on purpose. The profile records what a mechanism price cannot express: what a running program costs, how well a coding model and an agent work in the language, and whether a safety-critical path exists.

1.4.1 Energy and cost

What this axis asks: what does a running program cost in energy and time?

  • ❌ Interpreted by default: the slowest class in the energy and time benchmarks [5]; a causal re-analysis attributes most of the gap to execution time [6].

1.4.2 AI and agent readiness

What this axis asks: how well does a coding model and an agent work in this language?

  • ✅ A large training corpus and strong code-generation results: models write this language well [7], [8].

1.4.3 Safety certification

What this axis asks: is there a certified or standards-qualified path to a safety-critical system?

  • ⚠️ No certified or standards-qualified path for safety-critical systems.

1.5 Scoring detail

1.5.1 Core coupling Dimensions

Dimension Mechanism Description Present Cost
Type T1 dynamic no static check ✅ −15
T2 weak static — 0
T3 dynamic/duck dispatch ✅ −8
T4 no sum types ✅ −4
T5 no generics ✅ −4
T6 no namespaces — 0
T7 type erasure/reflection — 0
T8 operator overloading — 0
T9 inheritance required for polymorphism — 0
T10 no null-safety ✅ −8
T11 no module boundary — 0
T12 no effect tracking ✅ −8
T13 async/sync colouring — 0
T14 unchecked foreign boundary ✅ −4
Type subtotal −15 (−51)
Construction C1 global mutable state by default ✅ −15
C2 no immutability by default ✅ −4
C3 constructors coupled to allocation — 0
C4 no constructor/validation — 0
Construction subtotal −15 (−19)
Memory M1 manual deallocation — 0
M2 GC non-deterministic pauses ✅ −8
M3 no RAII ✅ −4
M4 no ownership model ✅ −8
Memory subtotal −15 (−20)
Error Er1 no structured path — 0
Er2 unchecked exceptions only ✅ −8
Er3 errors ignored/non-exhaustive ✅ −4
Er4 no composable result type — 0
Error subtotal −12
Concurrency K1 GIL/no parallel ✅ −15
K2 shared mutable state default ✅ −8
K3 manual sync no race detection — 0
K4 no structured concurrency — 0
K5 no primitives — 0
Concurrency subtotal −15 (−23)
Platform P1 cannot function outside one vendor/domain — 0
P2 single-vendor but other uses — 0
P3 legacy/discontinued platform — 0
Platform subtotal 0

Core Dimensions score: 28/100 — total cost = −72 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.2 Ecosystem coupling Dimensions

Dimension Mechanism Description Present Cost
Performance R1 interpreted no AOT/JIT ✅ −8
R2 GC pauses — 0
R3 JIT warmup — 0
Performance subtotal −8
Ecosystem Ec1 no package manager — 0
Ec2 fragmented tooling — 0
Ec3 small/niche/discontinued — 0
Ec4 proprietary — 0
Ec5 platform-locked tooling — 0
Ec6 monoculture ✅ −8
Ec7 legacy burden ✅ −8
Ecosystem subtotal −15 (−16)
Evolution V1 breaking changes — 0
V2 frozen — 0
V3 discontinued — 0
V4 glacial standards — 0
Evolution subtotal 0
Domain D1 domain/vendor lock-in — 0
D2 poor domain fit — 0
D3 framework forces architecture — 0
Domain subtotal 0
Learning L1 steep — 0
L2 large surface/multi-paradigm — 0
L3 sparse docs — 0
Learning subtotal 0
Syntax S1 verbose — 0
S2 inconsistent — 0
S3 punctuation-heavy — 0
Syntax subtotal 0
Testing G1 weak tooling — 0
G2 poor debugging — 0
G3 runtime-only errors ✅ −4
Testing subtotal −4
Security Q1 memory-unsafe — 0
Q2 dynamic/weak typing risk ✅ −8
Q3 known vulnerability/injection ✅ −8
Security subtotal −15 (−16)

Meta Dimensions score: 58/100 — total cost = −42 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.3 Engineering readiness Dimensions

Dimension Mechanism Description Present Cost
Reproducibility Y1 build not reproducible ✅ −8
Y2 dependencies not pinned — 0
Reproducibility subtotal −8
Supply chain Y3 no signed provenance — 0
Y4 registry without namespacing ✅ −4
Supply chain subtotal −4
Observability Y5 no stable tracing standard — 0
Y6 no structured logging — 0
Observability subtotal 0
Feedback Y7 slow build — 0
Y8 no fast in-editor analysis — 0
Feedback subtotal 0
Interop Y9 no foreign-function interface — 0
Y10 no portable target — 0
Interop subtotal 0
Governance Y11 single-vendor governance — 0
Y12 closed specification — 0
Governance subtotal 0

Readiness Dimensions score: 88/100 — total cost = −12 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

Verdict: Ruby prioritizes developer happiness over low coupling by language design. Pattern matching (3.0+) and Data.define (3.2+) add structured data handling. YJIT transforms performance. Main strength: readable, expressive syntax makes intent clear. Main weakness: all coupling detection deferred to runtime, metaprogramming creates invisible dependencies, GVL persists.

The formal development. The definitions, theorems, and proofs behind this page are published in:

All published papers

References

[1]
Y. Loth, “On the nature of coupling: All coupling as shared resource access.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925122.
[2]
Y. Loth, “Coupling as a consequence of cohesion: Decomposition, the coupling floor, and domain-imposed coupling.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925201.
[3]
Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.
[4]
R. Language, “Ruby language documentation.” Ruby, 2024. Available: https://ruby-doc.org/
[5]
R. Pereira et al., “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN international conference on software language engineering (SLE), 2017, pp. 256–267. doi: 10.1145/3136014.3136031.
[6]
N. van Kempen, H.-J. Kwon, D. T. Nguyen, and E. D. Berger, “It’s not easy being green: On the energy efficiency of programming languages,” in Proceedings of the 40th IEEE/ACM international conference on automated software engineering (ASE), 2025. doi: 10.1109/ASE63991.2025.00131.
[7]
S. Joel, J. J. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025, doi: 10.1145/3770084.
[8]
Y. Qing et al., “EffiBench-x: A multi-language benchmark for measuring efficiency of LLM-generated code,” in Advances in neural information processing systems 38 (NeurIPS), datasets and benchmarks track, 2025. doi: 10.48550/arXiv.2505.13004.