Paul Battley
Ranked 13 in Phase 2 with a weighted final score of 223

About the author

My first Euruko was in 2005, but even after using Ruby for all this time, I hope (and expect!) to come away in 2013 having learnt something new.

What should we take out of Ruby?

When a new version of Ruby is released, discussion usually focuses on what's been added. However, what if we took advantage of the next major Ruby version to drop some features?

The question I'd like to ask is: could we increase programmer happiness by removing features from Ruby? And, assuming that the answer is yes, what might we consider removing?

I have several candidates in mind, including:

Some of these will be more controversial than others; some more practical than others. Some may already be shunned by the majority of Ruby developers; others may be dearly beloved. Some might be completely impractical!

For each candidate, I'll:

  • Explain the rationale for dropping it
  • Show the alternatives
  • Report on how often it's actually used in Ruby's standard library and popular gems.

Finally, I'll explore whether we as Ruby programmers might unilaterally cut out use of some features, how we'd practically achieve this, and what benefits it might give us. As a comparison, the asm.js subset allows JavaScript engines to make some performance optimisations and precompile code. Is there something similar hiding at the heart of Ruby? That might be going a bit far, but dropping some features might be useful, as in the case of JRuby, which disables ObjectSpace by default to improve performance.

Previous Next


  • The proposal author responded 8 months ago

    Andrew: do you mean this flip-flop operator? I think that's a good addition to the list!

  • 009db5cc6efe8ac73e8158977acf4faf?d=retro Andrew Grimm suggested 8 months ago

    I currently use the first five features! ^_^

    Are you going to talk about the flip flop operator as well?

  • The proposal author responded 8 months ago

    Hi Filip, thanks for your suggestion. I'd like to try to persuade you otherwise! I know that some of my ideas might be impractical or a hard sell, but I think that's what makes them provocative and interesting to discuss.

    I think there are some architectural downsides to relying on autoload, but, on a more prosaic note, it poses problems for multi-threaded applications. Matz himself has said that autoload might be dropped in Ruby 3.0 for this reason.

  • 1f392637e1819fd9adb80da68ebfb44c?d=retro Filip Kostovski suggested 8 months ago

    I dont think that autoloading should be dropped. I have php experience where autolading is used very much to provide IoC container, speed up (reduce loading of files that are not required) etc.