Toward a Design for Ruby
summary
Ruby faces concrete engineering risks: MRI’s C-heavy implementation embeds semantics, encodings land on every object can have an encoding and cause latent bugs, the 1.8→1.9 rewrite spans ~seven years and leaves thousands of 1.8 Rails apps stuck, and the standard library/bootstrapping and C extension APIs differ across MRI, JRuby and Rubinius. Concurrency lacks a defined memory model, refinements arrive with zero RubySpecs for refinements, and the proposal is a design committee with RubySpec, multi-implementation ports (Oniguruma, Celluloid), implementation, debate and consensus vote.
AI-written summary · about
chapters (13)
- 0:00Welcome to Ruby
- 2:15Ruby in the job market
- 4:43Ruby’s competition and strengths
- 6:56Ruby community culture
- 8:09Ruby implementations beyond MRI
- 9:37MRI’s C challenges
- 12:33Ruby 1.8 to 1.9
- 15:45Ruby 2.0 issues
- 21:05Ruby 2.0 plans
- 24:59Refinements concerns
- 29:53Concurrency and security challenges
- 34:04Ruby design committee proposal
- 43:20Preserve Ruby’s unity
