February 20, 2026
RubyKaigi 2024 — Historical Context
Although this presentation discusses Ruby 3.4–3.5 and the ecosystem has already moved forward to Ruby 4 by 2026, the strategic shift it describes — reducing the traditional standard library and externalizing functionality as gems — represents a fundamental change in Ruby’s philosophy rather than a version-specific roadmap.
Understanding this transition is essential for anyone designing systems, maintaining long-lived applications, or building libraries, as it reveals the long-term direction of Ruby as a platform and enables more informed architectural decisions.
At RubyKaigi 2024 in Kyoto, Hiroshi Shibata (hsbt) — Ruby core team member and maintainer of RubyGems and Bundler — presented one of the most technically significant talks for production Ruby systems: “Long journey of Ruby standard library.”
This was not a conceptual roadmap. It included concrete changes already affecting Ruby 3.3 and upcoming 3.4/3.5 releases.
🔧 The Core Change: Stdlib → Gems
Ruby is actively extracting libraries from the traditional standard library into:
• Default gems — installed with Ruby, updateable via RubyGems • Bundled gems — shipped with Ruby but treated as external dependencies
This reduces coupling between the interpreter and libraries, enabling independent releases and faster security fixes.
⚠️ Example #1 — Gemfile Requirements Are Changing
Bundled gems must be explicitly declared when using Bundler.
source "https://rubygems.org"
gem "rss" # REQUIRED (bundled gem)
# gem "openssl" # NOT required (default gem)
gem "bigdecimal" # REQUIRED from Ruby 3.4 onward
This behavior was explicitly demonstrated in the presentation.
🔔 Example #2 — New Runtime Warnings in Ruby 3.3+
Ruby now warns when a library you use will stop being a default gem.
require "csv"
# warning:
# csv will no longer be part of the default gems since Ruby 3.4.0.
# Add csv to your Gemfile or gemspec.
These warnings are migration signals, not noise.
🧪 Example #3 — Detecting Default Gems Programmatically
RubyGems can tell whether a loaded library is a default gem:
require "openssl"
Gem.loaded_specs["openssl"].default_gem? # => true
require "rss"
Gem.loaded_specs["rss"].default_gem? # => false
This distinction becomes operationally important for dependency management.
💥 Example #4 — Dependency Breakage in Real Gems (Rails Case)
The talk showed that even widely used libraries can be affected.
ActiveSupport depends on bigdecimal. When it stops being a default gem, Ruby warns:
bigdecimal was loaded from the standard library,but will no longer be part of the default gems since Ruby 3.4.0.Add bigdecimal to your Gemfile or gemspec. This means gem authors — not just application developers — must update dependencies.
🧱 Example #5 — Native Extensions Extraction Problem
Moving C-extension libraries out of core introduces deployment challenges:
• Some environments lack build toolchains • Cross-compilation issues arise • Production containers may fail to install required gems
bigdecimal was highlighted as a concrete example.
📊 Direction of Travel (Ruby 2.7 → 3.5)
Ruby is deliberately shrinking the traditional stdlib while increasing gem-based distribution.
Result: a smaller interpreter, larger ecosystem surface area.
🧭 Why the Core Team Is Doing This
Two explicit motivations were stated:
🔐 Security — patch via gem updates without waiting for a Ruby release 🛠️ Sustainability — reduce maintenance burden on a small core team
🚀 What This Means for Production Systems
If you maintain Ruby infrastructure, this shift affects:
• Rails applications • Internal services • CI/CD pipelines • Docker images • Offline build environments • Gem authorship practices
Implicit dependencies are becoming explicit responsibilities.
🏁 Bottom Line
Nothing is being removed — but nothing is guaranteed to be “just there” anymore.
Ruby is evolving from a monolithic runtime into a modular platform where the application controls its full dependency graph.
For teams running Ruby in production, this is one of the most important changes announced at RubyKaigi 2024 — even if it didn’t come with new syntax or shiny features.
#Ruby #RubyKaigi #RubyLang #RubyOnRails #SoftwareEngineering #OpenSource
Linking Ruby knowledge from the most remote places in the world. 