Interview with Yehuda Katz

Rupak: Will most of the appealing features of Merb be merged into Rails? Will the Merb framework be dropped after that? If not, what is the goal of the Merb platform now and in future? Yehuda: Pretty much everything that we knew and loved about Merb is slated to be a part of Rails at some point in the future or made available as a plugin. However, there are still a number of applications using Merb, and we will continue to support it as long as there is interest.  Rupak: With all the Rails + Merb development going on, what would your recommendation be for current Merb users: Move onto Rails or upgrade to Merb 1.1? Yehuda: Once we release Merb 1.1, you’re going to want to be on it. Hold off on upgrading to Rails until the transition story is complete and stable. Rupak: What are other features/concepts that will be shipped with Rails 3? Yehuda: There are a few categories of changes:     * Improved internals. Rails 3’s internals have gone through a major working over in an effort to make them easier to understand and extend. As much as possible, parts of the Rails internals have had their object boundaries solidified and well-defined. This means that if you want to understand how ActionController interacts with ActionView, there is a well-defined boundary. If you want to replace one of the components or instrument the boundary, it is now very easy. This will help with Rails maintenance into the future, and will also make it a lot easier for plugin developers to write plugins that work well with future versions of Rails.     * Performance. Rails 3 has significantly lower overhead compared with Rails 2. For instance, the overhead of rendering partials or collections is between 20 and 25% of the overhead of doing the same operation in Rails 2.3. One specific example: rendering a collection of 100 partials is down from 8 milliseconds to just 800 microseconds. This is possible because we can leverage the crisper boundaries between components to cache common costs. For instance, we do a much better job of caching the template lookup for a given path, format (html), and locale (en).     * New Paradigms. Probably the most significant new paradigm is respond_with, imagined last January by DHH, and written by José Valim. This brings conventionality to RESTful controllers, wrapping up the default logic in a Responder object. Instead of a bunch of logic to decide how to render an object (JS, JSON, or HTML – render or redirect) you simply say respond_with(@comment). Like I said, this will use the Rails conventions by default, but it’s possible to create your own Responder for a given controller or group of controllers that wraps up a different pattern. You can see a lot more about this in José’s blog post announcing the feature (http://blog.plataformatec.com.br/2009/08/embracing-rest-with-mind-body-and-soul/)     * Agnosticism. Finally, Rails 3 will make it a core principle to decouple its implementation from the ORM, JavaScript library, caching backend, template engine, testing framework and more. We still want to have a fantastic getting started experience, with defaults that can bring you from 0 to 60 in no time at all. We also want it to be possible for users with different needs to use the tools they need to use to get the job done. Rupak: Has the Rails Core team been looking at a possible release date for Rails 3? Yehuda: We don’t have a release date yet. A lot depends on how quickly we can get plugins running on Rails 3 and get through an RC period with most applications transitioning smoothly. Rupak: Will there be any backward compatibility issues with Rails 2.x projects upgrading to Rails 3? Any recommendations? Yehuda: Backwards compatibility has been a priority. However, it has been common for people to hack into Rails’ internals to get common things done. Since we’ve done so much work on the internals, most of those hacks will no longer work. The good news is that we’re committed to providing public, supported APIs for people to use to do the same things. There will also be some small changes. For instance, we have finally removed .rhtml, and clearly defined the semantics for template lookup in ActionView. This means that some things that may have worked accidentally before won’t work now. On the bright side, we have now clearly defined the intended behavior, so changes that you make should carry you forward into the future.. Rupak: What are your initial thoughts about accelerating the adoption of Rails 3 when it is released? Yehuda: I’d like to see plugins embrace Rails 3 so we can hit the ground running with a fully working suite of Rails plugins once we release. Rupak: To change the subject a bit, How was Ruby Kaigi 2009? What are your impressions about the content presented and the people you met? Yehuda: It was really great. I loved being able to meet some of the people I’ve heard about when doing Ruby work but never had the pleasure of meeting. The content was at a very high level – much higher than the average American Ruby conference. People understood Ruby well and weren’t afraid to push its boundaries. The talks by the maintainers of various branches of Ruby were all very interesting as well. Rupak: How did your presentation go? What was it about? Yehuda: My presentation was about how parts of Rails 3 can be used in other contexts. I showed how ActiveModel allows you to get validations on a standard Ruby object, how you build a controller from the ground up, and how you can use ActiveSupport safely as an extended Ruby standard library. Rupak: Anything that you would like to say to the organizers of Ruby Kaigi 2009?? Yehuda: Great job! I’d love to see you in the United States at some of our conferences. Rupak: What do you think are the main reasons for such slow adoption of Ruby 1.9? What features would you like to emphasize that would encourage it’s adoption? Yehuda: It has mostly been the lack of a stable transition path. Database drivers haven’t cleanly worked, various popular libraries have had problems with encodings, and there are missing tools (like ruby-debug) that people rely on. However, Ruby 1.9 is significantly faster than Ruby 1.8, is more memory efficient, and is generally built on more modern technology than Ruby 1.8. The problems that have caused slow adoption are, for the most part, resolved. Database drivers work, the popular libraries are encoding-aware, Rails 2.3 and above work on Ruby 1.9, and ruby-debug is finally ported. Rupak: Any recommendations for people trying to be compatible with both Ruby 1.8 and 1.9? Yehuda: The biggest current issue is constant scoping. You cannot assume that a constant available outside a block will be available inside it. This is because Ruby 1.9 changes the constant scope when a block is evaluated in a new context, unlike Ruby 1.8. For instance, when using RSpec, you cannot refer to constants that you created inside the “describe” block inside an “it” block. Additionally, String#[] now returns a single-character String; in order to get the Integer value, you’ll need to call .ord on the result. ActiveSupport has extensions to make forward-compatibility easier. For instance, we define String#ord on String in Ruby 1.8, so you can replace “Hello”[0] with “Hello”.ord and get an Integer in both Ruby 1.8 and 1.9. Rupak: What do you still miss in Ruby? Yehuda: Interesting question. Over the past few weeks I’ve been hurting for better caching primitives (the general purpose Hash isn’t perfectly suited for caching) but I was able to get satisfactory performance using some Ruby tricks. In general, what I like about Ruby is that even though there are things I’d like, I can virtually always implement a satisfactory version of what I’d like using pure Ruby. Rupak: You recently took part in a Ruby vs Python debate and whether Ruby is more suitable for Rails than Python. What is your opinion in brief? [Ref: http://stackoverflow.com/questions/1099305]? Yehuda: My argument was that Ruby’s elegant closures and powerful metaprogramming make it particularly suited for a framework like Rails. Ruby’s closures make it possible to implement a feature like Rails’ respond_to in a way that makes it almost analogous to a new language feature. Similarly, Ruby’s metaprogramming facilities make it possible to create new functionality, like before_filter or validates_presence_of, that appear to be extensions to the language itself. From the perspective of a Rails programmer, the “private” keyword looks identical to “validates_presence_of”. Ruby’s self-hosting nature makes it easy for Rails to provide high-level abstractions that are easy to use with low conceptual overhead. For more details, read my post.

2009-08-30T03:27:22Z

http://railsmagazine.com/forums/2/topics/69

4 Interview with Yehuda Katz

2009-12-24T20:51:18Z