Ruby 2.0 Refinements in Practice(yehudakatz.com)
yehudakatz.com
Ruby 2.0 Refinements in Practice
http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practice/
7 comments
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...
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.
http://shootout.alioth.debian.org/u32/which-programming-lang...
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.
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.
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.
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.
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.
Ironically compay is a huge Lua proponent, having brought over some ruby-born projects like HAML into Lua... :)
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. :)
In this case it doesn't even seem fair to say expressiveness would be sacrificed, because expressiveness is just as much about human comprehension as it is about powerful code modification. In the current implementation there are too many ways for refinements to leak out of their defined context, granted it could be argued that this makes refinements more powerful, but it also undermines their very purpose (ie. isolating code).
I'm not a Ruby internals expert, but I've done my fair share of meta programming and debugging of monkey-patch conflicts. A more static version of refinements will give 99% of the benefit while avoiding most of the landmines Charles is describing. The other 1% can probably be served by adopting some other technique rather than looking to refinements. Ruby is already such a dynamic and powerful language that it seems silly to say that refinements need to have this uber-flexibility. All they need to be able to do is isolate monkey patches within a library and they've already provided a huge practical benefit. Being able to inject refinements into someone else's code? That's just not very important, and if it is for some particular case there are other techniques Ruby affords you, all of which should be used cautiously.
Barring some flaw in Charles' analysis, I'd say it's a no brainer that refinements need to go back to the drawing board.
I'm not a Ruby internals expert, but I've done my fair share of meta programming and debugging of monkey-patch conflicts. A more static version of refinements will give 99% of the benefit while avoiding most of the landmines Charles is describing. The other 1% can probably be served by adopting some other technique rather than looking to refinements. Ruby is already such a dynamic and powerful language that it seems silly to say that refinements need to have this uber-flexibility. All they need to be able to do is isolate monkey patches within a library and they've already provided a huge practical benefit. Being able to inject refinements into someone else's code? That's just not very important, and if it is for some particular case there are other techniques Ruby affords you, all of which should be used cautiously.
Barring some flaw in Charles' analysis, I'd say it's a no brainer that refinements need to go back to the drawing board.
While I try to start all of my new projects in 1.9, there are still good reasons to stick with 1.8. There are still a bunch of incompatibilities with gems, certain distributions coughUbuntucough still distribute 1.8 under the 'ruby' package, and large amounts of legacy code that's not 1.9 ready, for example.
That said, even though 1.8 is slow as a dog, often, it's _fast enough_. Your last paragraph hits it on the head.
That said, even though 1.8 is slow as a dog, often, it's _fast enough_. Your last paragraph hits it on the head.
Anytime someone asks for help on installing Ruby on Ubuntu I tell them to avoid the package manager.
Use RVM, it's a small bit of overhead that greatly increases productivity and reduces headaches.
Use RVM, it's a small bit of overhead that greatly increases productivity and reduces headaches.
Absolutely, and with .rvmrc files, you don't even need to think about it.
God yeah, I just got introduced to .rvmrc files. Talk about insane awesome.
The next programming language I use full time will have to have all the RVM features and utilities built into their RubyGem like utility, or I'm not even going to bother.
The next programming language I use full time will have to have all the RVM features and utilities built into their RubyGem like utility, or I'm not even going to bother.
People use ruby-1.8 because nothing works against ruby-1.9. And by 'nothing' I mean not rails 2.3.
I have not had problems running Rails 2.3 on Ruby 1.9.2.
Also, we heavily share code and data between applications with symlinks. Symlink handling (especially the interpretation of ..) is different in all ruby-1.8, ruby-1.9 and jruby. Makes the whole ecosystem smell like different ghettos.
Perhaps they'll change that in 2.0 as well.
Perhaps they'll change that in 2.0 as well.
Other implementations you haven't mentioned like MacRuby are much faster. In my totally unscientific and completely biased benchmarks (small tests related to the type of work I do mainly - Machine Learning) MacRuby is now faster than Python (2.6) and is closing the gap on V8 (which, in the tests I wrote, was even faster than Go, and less than twice as slow as C).
Veto, no, but obviously the JRuby team are well worth listening to. Charles's post isn't really saying that refinements are a bad idea, but rather offering some, well, "refinements" to how he thinks they should be implemented.
It's taken a long time to get Ruby's performance up to the respectable levels it finally achieves with 1.9 and JRuby, so I'm glad to see Charles pushing to avoid letting features creep in which could seriously degrade it.
It's taken a long time to get Ruby's performance up to the respectable levels it finally achieves with 1.9 and JRuby, so I'm glad to see Charles pushing to avoid letting features creep in which could seriously degrade it.
I can't imagine them having an actual veto, but they are definitely worth listening to.
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.
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/
Nice to see it finally being implemented in the core language.
[1]http://www.wobblini.net/ruby/behaviors/
Looks very interesting and this could finally address the biggest gripe against Ruby, which is uncontrolled monkey patching leading to interactions between libraries.
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
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
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.
I don't know. I think it would be better to have ruby 1.8 and ruby 2.0 around and to state clearly that some code requires this or that version than having to deal with ruby 1.9 that is still close to 1.8 but not close enough not to break code.
Can anyone please explain why ruby-core prefer refinements over classboxes?
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.
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.
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.
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.
... 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.
http://groups.google.com/group/ruby-core-google/msg/7ccc3759...
JRuby seems rather important these days. I wonder if that gives the project an effective veto on (bad) language features?