Congrats. Vagrant deserves the recognition. It's an excellent tool!

I agree. When and how to load the railties file could use some explaination.

For gems, I'd assume you have lib/gem_name.rb load the railtie.rb file first off (e.g. http://github.com/dkubb/rails3_datamapper/blob/ma... This will go a fair way to making vendor/plugins redundent.

For plugins, would this be best in init.rb? From your post, is the :load_init_rb initializer example actually in Rails, or is this something the plugin itself specifies? And if that's the case, how does Rails load plugins now? Does it look for a vendor/plugin/your_plugin/railtie.rb ?

I was actually hoping for more indepth topics from Yehuda about those questions, to explain the API that is in Rails 3, not where to find it.

* How do plugins/gems hook into the router nicely in Rails 3?
* How do plugins/gems run initializers in Rails 3?
* How do plugins/gems add Rack middleware nicely in Rails 3?

Jaroslaw, DHH has estimated a beta release by end of January: http://twitter.com/dhh/statuses/7208225785 It may change, but at least it gives some indication of how close Rails 3 is

There is nothing stopping you from using it right now though. Rails master has been stable for some time now. All tests are passing. I've been able to generate and run an application off Rails 3 for some time now.

So rather than saying "RoR3 is not ready for serious usage", say exactly why it isn't ready so developers might be able to address the issues. Statements like that without explaination don't help anyone.

Several of the developers and a few of the community have been making blog posts or tweets about whats been going into Rails 3 for some time now. If you're following the right people, you'll know that the bulk of features are implemented. In no way is the following list exhaustive of what is already implemented in Rails 3:

* Increasing Performance and reducing overhead (this post)
* Separation of responsibility and Dependency declaration (previous post)
* ARel integration with ActiveRecord (no blog posts I know of, but a lot of commits for it recently)
* Rails router DSL improved - http://rizwanreza.com/2009/12/20/revamped-routes-... and http://yehudakatz.com/2009/12/26/the-rails-3-rout...
* Gem bundler (allowing references to Rubygems to be removed) - http://yehudakatz.com/2009/11/03/using-the-new-ge...
* Major cleanup / refactoring of internals (particularly around dispatching/respond_to)
* many many more….

As for timelines, while there isn't a specific one available, mainly because with project like this, it is very hard to accuratly predict them, DHH has estimated a beta release by end of January: http://twitter.com/dhh/statuses/7208225785

From what I have seen regarding plugins, Rails 3 will maintain backward compatability, but includes new features such as off loading the rake task loading to the plugin, and adding support for initializers within the plugin. As an example of this, ActiveRecord is now treated as a plugin of Railties (which should make swapping out the ORM a lot less painful). Example: http://github.com/rails/rails/blob/master/activer... . These added abilities should make development via gems a lot easier.

Re migration: I was refering to the update from Rails 2 -> Rails 3 would be eaiser than if they went with Merb as the base. I'm not sure about the state of Merb 1 -> Rails 3 migration.

Re gems: There aren't a lot I know of, but there are some. I was mainly thinking of ones like New Relic gem. If Merb were the base, I'm guessing they'd have had to rewrite their Rails adapter.

Re plugins: Right, I'm not saying plugins won't break between Rails 2 and Rails 3. But, until the plugin is written to use the new api, the code to make things work again should be easier to patch in than it would be to rewrite entirely (or wait for it to be rewritten) for Merb.

Merb is open source. If development has stalled, it was abandoned by the entire community, and not just the people who were working on it. It's the same for any other open source project. If you want something to keep going, you take over, and don't complain!

Another great post. Some awesome work. But I assume you're using a standard Ruby 1.8.7 installation? It would be nice to see how these optimization compare between that and an alternative implementation of the same version, namely Ruby Enterprise Edition version of Ruby 1.8.7. Would you be able to get this information?

Merb was still relatively new as well. While it might have had a better codebase and performance at the time, there were far more Ruby on Rails applications out there, compared to Merb ones. By expanding upon Rails 3, they made sure that the upgrade path for the majority of the users would be easy. Had they expanded upon Merb instead, many Rails applications would have had to be slowly migrated over, and many plugins/gems would no longer have worked (which many might have been resistant to do given the effort and cost involved, negating the effort put into improving it). And yes, while the same app/plugin/gem breakages are likely true for Rails 2 -> Rails 3 migration, it'll be far easier to fix the issues you find on a framework you're familiar with, that something you've probably never used before.