Ruby 3.5 Feature: Namespace on read

Purpose of “namespace on read”

• Introduces a new way to load code so that constants, modules, and monkey patches live inside a separate “namespace” instead of the global object space.
• Intended to let applications safely combine libraries that assume the global namespace, or that clash on constant names, without modifying those libraries.
• Shipped as an experimental, off-by-default feature, which some see as a reasonable compromise after a contentious design and integration process.

Perceived benefits and concrete use cases

• Safely using poorly namespaced or “polluting” gems, including those redefining core classes or global constants.
• Isolating monkey patches and other global modifications so they don’t leak across an app.
• Allowing users, not authors, to decide how libraries are namespaced, rather than hardcoding MyGem::MyClass.
• Specific examples: multi-tenant apps needing separate gem configuration per tenant, benchmarking multiple versions of the same gem in one process, avoiding accidental “helpful” requires from test dependencies (e.g., ostruct being brought in by a transitive test gem).

Ecosystem and dependency concerns

• Strong worry that this normalizes having multiple versions of the same gem loaded, pushing Ruby toward the “npm-style” world many explicitly want to avoid.
• Fear that gem authors will feel free to define globals or patch core types, then tell users to “just load it in a namespace” when conflicts arise.
• Some argue that existing conventions (each gem exposes a single top-level module matching the gem name) already make name conflicts rare in practice.

Complexity, philosophy, and opposition

• Longtime Rubyists say they’ve rarely or never hit the problem this solves, and see the feature as complexity with marginal benefit.
• Criticisms that it undermines Ruby’s simple, single global object space and “convention over configuration” ethos, and continues a trend of bolting on features (RBS, namespaces) to match other languages.
• Concerns about surprising semantics when objects change behavior across namespaces, and about mental overhead and tooling complexity.

Ruby performance and relevance side-thread

• Some commenters would prefer core effort go to performance; others counter that Ruby 3.x already improved performance significantly.
• Side discussion compares Ruby/Rails vs Elixir/Phoenix, JS, Go, etc., with mixed views on long-term employability but broad agreement that Rails remains widely used even if it’s past its hype peak.