
Ruby 2.0 Refinements in Practice - wycats
http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practice/
======
bensummers
It's worth reading Charles Nutter's thoughts on the performance of
implementing this language feature:

[http://groups.google.com/group/ruby-core-
google/msg/7ccc3759...](http://groups.google.com/group/ruby-core-
google/msg/7ccc375905dda23c)

JRuby seems rather important these days. I wonder if that gives the project an
effective veto on (bad) language features?

~~~
ekidd
Ruby is already the slowest widely-used programming language, by a fairly
significant margin. Ruby 1.8.7 routinely runs a 1/200th the speed of C code.
For comparison, other dynamic languages run at 1/2th to 1/60th the speed of C.
This is better in Ruby 1.9 (getting up into the 1/60th range). But Ruby is
still a painfully slow language. Some unscientific benchmark plots here (note
the log scale!):

[http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-
fastest.php?gpp=on&java=on&luajit=on&ghc=on&sbcl=on&racket=on&v8=on&jruby=on&python3=on&yarv=on&ruby=on&calc=chart)

JRuby and Rubinius have been working to improve Ruby performance. In theory,
it might possible for Ruby to run at 1/2th to 1/10th the speed of C using an
aggressive tracing and optimizing compiler similar to LuaJIT.

But this proposed feature really makes me cringe: If refinements require
frequently invalidating method caches, Ruby performance will _always_ be
horrible. I'd rather sacrifice a tiny amount of expressiveness and have my
code run 50x faster, thank you. :-)

EDIT: Note that there are some very cheap ways to implement a similar feature,
including the way Common LISP supports package-scoped symbols.

~~~
compay
It amazes me when I go to conferences and I see how many people are still
using 1.8 rather than 1.9 or JRuby, which may not be comparable to LuaJIT but
offer __much __more respectable performance.

I also really sympathize with the notion of sacrificing some degree of
expressiveness for performance. If this feature is to be added, it __needs
__to be done in such a way that it does not set back the hard-earned
performance improvements of the last few years.

Then again, expressiveness __is __Ruby's niche, and DHH's famous quote about
"sacrificing CPU cycles in favor of developer cycles" is quite valid, IMHO. If
you need raw performance you should look to another language because I don't
think that will __ever __be too high a priority for Ruby.

Github uses Node and (IIRC) Erlang for some stuff, and Twitter uses Scala - if
you're lucky enough to have the kinds of problems those guys have, then the
best bet is usually to use Ruby where it gets you a developer speedup and
another language for the parts of your app where performance is absolutely
critical.

~~~
ekidd
_If you need raw performance you should look to another language because I
don't think that will ever be too high a priority for Ruby._

I reject this philosophy: Lua is also a highly expressive programming
language, and LuaJIT runs 75 to 100 times faster than Ruby 1.8. There's no
reason why the Ruby community should settle for lousy performance.

I'm trying to track down a bug in the Rubinius JIT as I speak. Rubinius may be
faster than 1.9, but I can still see dozens of really obvious optimization
opportunities. If nobody screws up method caching, Ruby will eventually be 10
times faster than it is today.

~~~
rubyrescue
Ironically compay is a huge Lua proponent, having brought over some ruby-born
projects like HAML into Lua... :)

~~~
compay
Well, I'm very glad there are people who are willing to do the hard work to
improve Ruby's performance. If ekidd can help bring it up to a significant
fraction of LuaJIT's, I'll line up in the pouring rain to be the first one to
buy him a beer. :)

------
SlyShy
Part of my interest in _why's project Potion was the use of scoped mixins.
Seeing that Ruby will have a similar capability soon is exciting to me, as I
can think of several instances where I've wanted to avoid leaking a localized
monkey-patch.

------
riffraff
I remember the proposal of "ruby behaviours" from david black about ten years
ago[1] which allowed doing the same.

Nice to see it finally being implemented in the core language.

[1]<http://www.wobblini.net/ruby/behaviors/>

------
adambyrtek
Looks very interesting and this could finally address the biggest gripe
against Ruby, which is uncontrolled monkey patching leading to interactions
between libraries.

------
pilif
What interests me personally, also in light of this snarky comment here
<http://news.ycombinator.com/item?id=1924487> is whether Ruby 2.0 will do away
with reopening classes and only allow the much better Refinements.

This will break most of the code out there, but in light of doing it cleanly,
it would probably need to be done. On the other hand, a change like that will
make sure that we might never see significant adoption of Ruby 2

~~~
pygy_
I don't think that editable classes and modules will go away, since they allow
to spread the definition of a class to multiple file and/or serve as
namespaces.

------
davnola
Can anyone please explain why ruby-core prefer refinements over classboxes?

~~~
steveklabnik
I'm no expert on classboxes, but there's some info here:
<http://timeless.judofyr.net/refinements-in-ruby> (control-f for 'classb')

I'd imagine that some of the reason is due to the fact that this is already
implemented, but classboxes are not. I don't know anything about ruby-core, so
I don't know how much that'd matter to them, but an almost identical but
implemented feature seems much better than a more pure but unimplemented one.

~~~
davnola
The proposer suggests here <http://goo.gl/4P4Wa> (slide 39) and here
<http://goo.gl/p7ReQ> that local rebinding violates the expectations of the
callee, but it just seems to me to be very unintuitive.

------
CoffeeDregs
I recently and very reluctantly switched from Ruby+Rails to Python+Django. I
really preferred Ruby's syntax: to me, it's just prettier and cleaner than
Python. I really preferred Rails' organization: less flexible than Django
means faster development when my projects fit into Rails' organization...

... but YKatz's article gives me comfort that I made the right decision. While
you can accomplish many of the same bits of magic in Python, it's much harder
to do so. Clearly, I'm not a Ruby ninja, but I am someone trying to get stuff
done and the pervasiveness of monkey-patching in Rails bit me a number of
times (track down some function only to find out that I was looking at the
wrong, un-monkey-patched version). I hadn't really realized how much I _don't_
miss Ruby until reading through YKatz's article on how Ruby 2.0 will handle
monkey-patching. How about just making monkey-patching harder?

Python has plenty of complexity, but you __don't need __to know about it: you
can use Django just fine without paying much attention to the richness of
Python. Ruby also has plenty of complexity and you __need __to know about it:
use Rails or add a plugin to Rails and you'll quickly be reading through
complicated Ruby classes that monkey-patch Rails.

