Not to cry sour grapes here but there is not one mention of Merb in that entire blog post. I personally wrote merb in order to show that rails internals could be much better, modular and faster. I did heavy duty politicking to get the two teams to come together and I think the rails merb merger is one of the coolest open source success stories vie heard of.

But not a single mention of merb in this entire post. I'm not complaining but it seems disingenuous not to mention it as the sole reason I wrote merb was to push rails forward. And when it looked like merb might possibly overtake rails I went ahead and gave merb to the rails project and got the two teams together so there wasn't wasted effort. After all to have ruby and rails itself win we needed to compete with java and python and php. Merb was starting to fragment the ruby community as it became a more and more viable option and I did some personal heavy politicking to get it merged back into rails so we could take on the world instead of infighting within the ruby community.

I think it's been a great success story and most of the ideas of merb's architecture have made it into rails.

So I'm incredibly happy to see rails 3 finally come out. And I'm incredibly happy that my little experiment in making rails architecture better has paid off and the two projects merged. But I do think it's a bit weak that merb was not mentioned once in the article.

(Edit) all this being said I don't want to come across as co plaining. My work on merb ended up exactly as I wanted it to, it made rails better.

So huge congratulations to the rails team for making this happen!

(Edit) http://rubyonrails.org/merb

I just wanted to say a few things.

First of all, this is a huge milestone for Rails. From my perspective, this work is three or four years in the making, from the beginning of the Merb efforts, through the merge, and on until the final release of Rails 3.

From a personal perspective, this release is huge closure for me; I feel like I’ve been working on Rails 3 (and associated projects, like Thor and Bundler) for years.

When the Merb team merged into the Rails team, we very quickly got to work. The previous animosity actually melted away rather quickly, to be replaced with the somewhat tense, but productive give and take of a core team.

One of the really amazing things to come out of the last couple of years is a whole slew of new committers to Rails (in addition to Carl and me): José Valim, Aaron Patterson, Xavier Noria and Santiago Pastorino. Rails 3 would still be limping along if not for these guys, who really went above and beyond the call of duty in the past few months to get things past the finish line.

In light of all this, I really haven’t thought much about the old Merb/Rails party lines in a while. I’ve been too focused on Rails and Bundler, and the rest of the core team (old and new alike) have been busy helping.

"Merb was starting to fragment the ruby community as it became a more and more viable option and I did some personal heavy politicking to get it merged back into rails so we could take on the world instead of infighting within the ruby community."

Interesting, if disheartening, perspective.

I much prefer to see greater diversity within a language. I want to see more frameworks, more exploration, more choice. What some may call fragmentation is in fact rich and vibrant and valuable.

And the idea that there is some sort of battle going on among languages, that Ruby needs to "win" against Java or PHP or any language, is truly perverse.

I fear this battle mentality is by no means a minority opinion among Rubyists.

I prefer to use Ramaze for Web development, but I'm glad people can pick Camping or Wave or Wuby or IOWA or Sinatra or any of the dozen other options out there. There are interesting things being done, and not simply so they can be subsumed by some One True Framework.

I was disappointed not to see Nitro get the attention it deserved, to have Chad Fowler tell a conference audience that people working on Nitro should just stop, because "Rails won", was a turning point in how I viewed the larger Ruby culture.

There are many smart, adventurous people doing interesting things with Ruby, but there is also a pervasive cliquishness and neophobia regarding anything that is not somehow tied to Rails.

It's great to see progress made in Rails, but the solidification of Ruby === Rails leaves a bad taste.

It's also becoming an issue in the Python world, in job descriptions and among newbies, that Django == Python, as in questions like "how do I implement a sort in Django ?". Not helped by the fanbois who answer "just use Django" without qualification whenever somebody asks which web framework to use with Python.

While I'm happy that Django has helped promote Python, any monoculture is not only bad, but boring.

I really like web.py. It's small, lightweight, does exactly what you need it to do and then gets out of the way.

Can't help but notice the lack of Padrino (http://www.padrinorb.com/) on this list. Granted, it's a layer on top of Sinatra... It's really quite fantastic. Please do look, and run the stack on 1.9.2 :)

I think you completly missed the point of my comment.

you can always press the fork button :)

Also, Sinatra has really become the main competitor to Rails among Ruby frameworks...

    you can always press the fork button 

I have. I've forked my attention to Haskell and JavaScript, among other things.

Personally, I began using Sinatra for new projects fairly recently, mainly b/c I find sinatra + datamapper very elegant. I also love python, fwiw.

It needs to at least compete with Java/PHP ect. In order to create a big enough ecosystem to provide all the libraries and core features needed and keep them up to date. As well as have enough people explaining things that new people don't feel overly intimidated.

"It needs to at least compete with Java/PHP ect."

Why?

And you know what? It never will. Rubyists need to give this up. It's a pipe-dream. Microsoft can set up large/local conferences, charge $75, and make a sales pitch. Dozens of vendors lined up to hand out schwag and pitch their product.

For management, they don't get the best tool, but if it meets requirements, then it's a no-brainer because the most expensive component license is (usually) cheaper than the dev time to meet the basic requirements in-house (those are usually a small subset of what the component might do).

The bigger issue is that that sort of buy vs build scenario manages risk very well.

Ruby has a lot of strengths, but providing a strong story for managing risk isn't one of them. Especially if you don't bill by the hour.

The world of software development isn't winner take all. The same things that can make Ruby and Rubyists great are some of the same reasons it likely won't ever be a good fit for some of the mass-market issues Java and .NET are a good fit for.

That's OK in my book. I die a little on the inside every time someone tries to sound smart by saying "use the best tool for the job" when often there are clear and obvious winners and losers in software. But in this case... Use the best tool for the job. Or maybe just the tool you like most. If Ruby works for you and your company, you're already doing the risk management thing very well. No reason not to use it.

A language community needs to be robust enough to look after these things. This is not the same thing as, nor does it require, "beating" other languages. Even accounting for limited time and attention from interested developers this is not a zero-sum situation.

Language communities do not need to push for a monoculture in tools and frameworks to be robust; cultures that avoid this are much healthier in the long run.

Ruby has a wealth of frameworks, due to Rack. They all have interesting bits... maybe Rails gets a lot of press, but Sinatra, camping, ramaize, padrino, and others would probably like to have a word with you.

Quite understandable, I sympathize. Seems he mentioned every major improvement except the Merb integration.

If it makes you feel any better, I was under the impression that everyone in the Rails/Merb community already knows that Rails 3 = Rails + Merb.

Anyway, great work, we all appreciate it.

Offtopic: when are you announcing your next project? We're already feeling the lack of your presence at EY as we move to AppCloud. A cool new project would do much to offset that general disappointment (not that it's your problem).

I'm working at Vmware now on a cloud operating system. That's about all I can say right now but it is what runs vmforce and vmware's partnership with google app engine to get spring running there very well. Multiple cloud multiple language paas.

> I'm working at Vmware now on a cloud operating system.

Will it be open source and how does it compare to OpenStack?

Go on ..

He did, indirectly: "So if you want to get in touch with me my new email address is ez@vmware.com ;)" (http://twitter.com/ezmobius/status/21954080229)

I thought the big thing about Rails 3 was the merging of Merb and Rails. Would it have really hurt DHH to include a sentence of acknowledgement in his long post? I am disappointed.

They've been yammering about that for two years already. Maybe it just slipped his mind, as it hasn't been news for two years now.

Not a single mention of Merb in the entire blog post.

A comment from DHH in the comments of the post:

it long since stopped being about a Rails and a Merb team. Today there’s just a Rails 3 team where everyone is working together for the improvement of the framework.

See http://contributors.rubyonrails.org/contributors?window=this... for work done this year. More than 350 people who has commits this year. No factions, just collaboration.

Does AR really work like this?

    users = User.where(:name => "david").limit(20)
    users.where("age > 29")
    
    # SELECT * FROM users 
    # WHERE name = "david" AND age > 29 
    # ORDER BY name
    # LIMIT 20

It seems a bit counter-intuitive to me. I'd expect that

    User.where(:name => "david").limit(20).where("age > 29")
    =/=
    User.where(:name => "david").where("age > 29").limit(20)

Yeah - just nitpicking, but it caught my attention.

It may seem counter intuitive at first but here's the thing to understand:

> users = User.where(:name => "david").limit(20)

Does not actually do any calls or create any kind of sql by itself. When you follow it up by

> users.where("age > 29")

all you're telling the users object is that you want to add a condition to your next query. You are not telling it to refine the previous query.

To get what you want, you'd need to do:

> users = User.where(:name => "david").limit(20).all

> users.where("age > 29")

Sure - I know how it works and that it's useful. Still - it breaks the no-surprise rule for me...

You could always have stacking functions with both .where and .combine_where, so that:

    User.where(:name => "david").limit(20).where("age > 29")

gives you (with second where starting new level of query):

    SELECT * FROM (SELECT * FROM user WHERE name = 'david' LIMIT 20) WHERE age > 29

and this (combine_where folding into the same expression):

    User.where(:name => "david").limit(20).combine_where("age > 29")

gives you:

    SELECT * FROM user WHERE name = 'david' AND age > 29 LIMIT 20

Just like you don't expect `map()[range].map()` or whatever the equivalent in Ruby is, to combine the map calls and move the range to the end.

Well, you could do it the django way, where you can't filter a queryset after a slice has been taken (eg. limit has been used)

This is ten times more logical if you ask me.

It's very convenient to be able to pass a partially built query, including a limit, into a function which adds more conditions. Why would you not want to be able to do that?

Because the meaning of it is totally counter intuitive, for one ?

It depends on whether your mental model is "applying a sequence of filters to a result set" or "editing attributes of a query". If the latter, you'd expect them to be equal and the opposite would be surprising.

Just from the point of view of a Rails user, generally I want to do the latter. This will replace things I use .with_scope() for right now, which a "sequence of filters" model wouldn't work as well for.

The query is lazily generated, so that's why they're equal.

Why should a lazy lookup behave differently than any other one, except that it happens later?

You're assuming that execution happens on a limit, and it doesn't.

Or even:

  User.where(:name => "david",  :age => "> 29").limit(20)

Although this way you'd have to parse the '>' out of the second K-V.

Parsing the value is not the best idea (you have to watch the types and still cannot apply the comparison query to string columns).

DataMapper resolves the issue via :age.gt => 29 and Sequel got its stylish filter{age > 29} syntax.

You have to keep in mind that unspecified elements of SQL are not guaranteed to be random. There is no situation in which the two queries you supplied, executed sequentially as you "expect", would be guaranteed to produce different results. For any possible set X of 20-or-fewer Davids who are 29 or older, there exists a set of Y of 20 or fewer Davids of unspecified age such that X is the subset of Y obtained by filtering out the Davids in Y who are younger than 29. If your query allows this result, the DBMS is permitted to return it if it deems it more efficient.

You cannot assume anything about your result sets. It's best to just pretend every database functions something like the Monkey's Paw: it will grant your wish to the letter, but always in the most horrifying manner that your wish permits.

>Say goodbye to encoding issues

And good riddance! Utterly thrilled to hear this.

Bold words. I can guarantee that encoding issues will prevail. They may be of another sort, but they will never go away magically.

Certainly. But you can remove the ones you create (to reach "zero"), and patch some of the ones you don't (to reach... "-zero"?).

Anybody have more in depth details on how this was achieved? K thx bye!

Well, the first thing is like the post said: Ruby 1.9's string encoding support is much, much better. For more on this, see wycats' post here: http://yehudakatz.com/2010/05/17/encodings-unabridged/

Secondly, Rails 3 has some tricks up its sleeve, with things like the Rails Snowman: http://railssnowman.info/

Thanking you kindly sir.

Me too, this is perfect for the literature website site I'm working on.

We've designated a release charity for people to show their appreciation of Rails 3. If you're going to use it, please help us bring clean water to 5,000 people with Charity:Water.

You can donate on http://mycharitywater.org/rails3

    Status: 500 Internal Server Error

Maybe not quite yet?

Fixed the issue. The weblog is a prime example of cobbler's shoes. I think it's running Rails 0.5 on a machine that hasn't been updated in 6 years.

Hey come on, it's running Mephisto. It's got to be at least Rails 1.0 :)

Speaking of, you might want to get rid of the mephistoblog.com link since it is no longer valid.

I want to nuke that entire installation from orbit. It's the only way to be sure that it's gone.

I mean, it should only take 15 minutes to build a new one, right? ;)

And at least one "WHOOPS!"

How the rails team will celebrate this milestone? really, it's an amazing work guys, thank you and congratulations

For anyone using Rails 3 with haml, upgrade haml to 3.0.18...

  bundle update haml

I lost a few hours looking for the issue where form_for was silently failing.

Great support though. Here is a discussion of the issue and resolution.

https://rails.lighthouseapp.com/projects/8994/tickets/5493

It's 500-ing, so here's a pastie of the text: http://pastie.org/1125097

I just realized this going through the API docs when I noticed the docs for 3.0.0 were now live on api.rubyonrails.org. Finally! (Of course, just two hours after converting one app from rc1 to rc2.)

I'm about to learn Rails 3, please, which parts of it you think are complex, over-designed and over-engineered?

I'm using rails 3. OP is full of crap. Rails is a full stack framework complete with ponies, unicorns, and rainbows. Asking it to be minimal is a joke, but you can get rails pretty slimmed down if you work at it. You wouldn't want to build a full app on ActionController::Metal but you can.

The redesign has made the internal code of rails much simplier and ActiveModel is simply brilliant. I'm using CouchRestModel and having ActiveModel means I can use plugins like Formtastic right out of the box.

Rails 3 decoupled the major components. It's more modular now. I can disable ActiveRecord without the plugins I'm using getting upset that it's missing. If anything, this makes the framework less complex because you don't have to worry about interplay between the components.