Rails 3.0 Released

An anonymous reader writes "After two years of gestation, 4 betas, 2 release candidates and thousands of commits by 1600+ contributors, the result of the succesful merge of the Merb and Rails frameworks (and teams) is now out and ready to transport your web applications on all new shiny tracks."

Comments

Too many changes?

[p0]

I find it a bit hard to keep up with rapid changes to Rails. But that's my problem anyway. I think the changes and additions in Rails 3 are wonderful and the team did a good job on this. Congratulations and thank you!

Re:Too many changes?

[Anonymous Coward]

2.3.x is still supported, actually they're working on 2.3.9 as we speak.
It's true that the Rails eco system moves forward at a good pace, but that's a good sign to me. it means ideas are brewing and accepted.
A sign of good health :)

Re:Too many changes?

[ojustgiveitup]

They've been working on Rails 3 for more than a year now... not really so rapid. For instance two versions of Ubuntu have come out since then.

It's a nice framework

[Anonymous Coward]

I've avoided Rails for years due to the community's reputation. So against my better judgement, I decided to build a project on the Rails 3 Beta, thinking that some of frameworks new features made it hard to ignore.

And you know what? It's a really nice framework. Nice enough that in the future, I'll probably be using Ruby on Rails instead of PHP or Python when the project allows.

But I do wish the community would grow up.

Re:It's a nice framework

[Anonymous Coward]

But I do wish the community would grow up.

But from my experience, I think the community is already big and grown up enough to base your serious application on Rails.

No, not grown up as in scale (*ahem* twitter, twitter) but grown up as in *not* arrogant ranting pricks.

Re:It's a nice framework

[ojustgiveitup]

Could you give some examples from your own experience where the community has been problematic or not "grown up"? I've been using Rails for awhile now and have yet to run into anyone besides people trying to get good stuff done for their clients or companies, just like everyone else. What I *have* run into is a willful ignorance on Slashdot surrounding Rails, and more seriously, Ruby, which is a great language and really very similar to perennial Slashdot favorites Python and Perl.

Re:It's a nice framework

[Anonymous Coward]

Not sure if you're aware of this but Rails isn't the only widely used Ruby web framework. There's also Sinatra, which is quite popular, and then there is Camping and a handful of other lesser know options. The really nice thing about all of them though is that they are all built on Rack which means they can all play nice together. That is the real beauty of the Ruby community, even our different projects can play nice together because we have common points of integration.

Re:It's a nice framework

[Bogtha]

This is something I wrote a while back: These are not the actions of people who care about writing the best code possible, these are the actions of people with egos chasing features and attention.

I haven't kept up with Rails development, precisely due to attitudes like these, but hopefully the injection of Merb will bring with it an injection of - yes I'll say that word - professionalism.

Re:It's a nice framework

[Anonymous Coward]

perhaps you should consider choking to death on a sack of dicks.

Yeah, how dare he say that the Rails community is immature!

Re:It's a nice framework

[DragonWriter]

Rail is a nice framework.

The major problem with Rails is that it's tied to Ruby. Historically, Ruby's interpreters have not exactly been speed demons.

That hasn't been the only big problem with Rails. Rails. Indeed, one of the problems with (pre-3.0) Rails is that was particularly inefficient in many key areas of how it used Ruby; one of the big motivations for the myriad other Ruby web frameworks that came out after Rails was using Ruby more efficiently than Rails (Rails 3.0 incorporates many of those lessons into Rails, so that should be less of a problem going forward.)

Rail, pre-3.0, actually had on its own the same kind of problems as pre-1.9.x Ruby had.

Re:It's a nice framework

[Anonymous Coward]

I'm not the parent; but statements to the effect by 37 Signals that they "don't hire people unless they use a Mac" probably have a lot to do with this.

That immediately alienated what, 90, 85 percent? I forget the market share stats; but it alienated a lot of people. Yeah, I really want to spend extra money for a proprietary white box so I can be cool like you.

Even if it weren't for the 'tude; I still wouldn't be interested. You pay a high performance price for the dynamic nature of Ruby whether you need it or not. It just doesn't seem like that great an idea. Combine that with the "tragicly hip" air of the community, and a lot of people find themselves just wishing Rails/Ruby would go away.

Re:It's a nice framework

[Anonymous Coward]

Wait, wait wait... somebody says that the Rails community is immature, and you respond with "I know you are, but what am I?"

Seriously?

Re:It's a nice framework

[DragonWriter]

I'm not the parent; but statements to the effect by 37 Signals that they "don't hire people unless they use a Mac" probably have a lot to do with this.

That immediately alienated what, 90, 85 percent? I forget the market share stats; but it alienated a lot of people.

37signals is a business. They do Mac-based development. Not hiring people that don't use Macs may not be the best business decision (simple litmus tests usually aren't), but its not an insane one, to be sure, and it has just about nothing to do with Rails, since even though there are personnel overlaps between Rails and 37signals, the two aren't the same thing.

Yeah, I really want to spend extra money for a proprietary white box so I can be cool like you.

Unless you are looking for a job with 37signals, I don't see how their preference for hiring Mac users affects you at all. And making something a job qualification isn't the same as making it part of the definition of "cool".

Even if it weren't for the 'tude; I still wouldn't be interested. You pay a high performance price for the dynamic nature of Ruby whether you need it or not.

That's a legitimate concern, though there are good reasons that performance of the runtime isn't the overwhelming concern when choosing a platform for a project, but the speed with which something can be developed, tested, and deployed is more critical, and the Ruby ecosystem and Rails have features that lots of people find attractive in that direction.

Combine that with the "tragicly hip" air of the community, and a lot of people find themselves just wishing Rails/Ruby would go away.

AFAICT, the "tragicly hip" air of "the community" is something that exists largely in the minds of people who have minimal if any active contact with either the Rails community or the broader Ruby community (often, people who fail to recognize that the two groups are distinct), and who therefore see only the interactions in the community that create controversies visible outside of the community.

Re:It's a nice framework

[SanityInAnarchy]

One assumption is that the Rails community -- as you said, "straight from the top" -- embraced unsafe GETs and tried to block GWA in order to keep using unsafe GETs.

I don't know if this was ever true, but it hasn't been true for at least two years, probably longer. Rails has embraced REST to an obsessive degree, which means not only are GETs never used for unsafe operations, but if your UA supports PUT and DELETE, Rails will accept those. (If not, PUT and DELETE are emulated over POST -- still not GET.) I met all kinds of fascinating people at Railsconf this year, and we disagreed on all sorts of things, but I seriously don't remember a single person arguing that REST was a bad idea, certainly not that unsafe GETs are a good thing.

jemmyw was the reply which pointed this out to you, though not in as much detail.

So, anyone who was calling GWA "scary" because of this was wrong and either not representative of the Rails community, or you're telling us a story from at least 3-5 years ago, which is a long time in Rails development time.

Re:It's a nice framework

[Per Wigren]

and significant challenges making it play nice with Apache in a manner comparable to mod_php. (has mod_ruby come of age, yet? ;3)

Passenger is what you're looking for.

Re:It's a nice framework

[Jane Q. Public]

First, I apologize for getting you mixed up with the person who wrote that Rails had implemented PUT and POST backward, which simply isn't the case. That's what I was mainly referring to when I wrote that you were wrong. But do have another issue with the things you wrote.

You equated one or maybe a few specific people with the "Rails community". David Heinemeier Hansson might be the original author of Rails, but he is not -- even remotely -- the "Rails community", nor is 37 Signals. And you made that error not once, but twice.

First, you describe how GET was often used for unsafe operations (a good description of that is available HERE). However, using the link_to method as described is hardly "standard practice". In fact it is anything but, regardless of whether DHH and 37 Signals have used it that way. In general, link_to was designed simply for navigating among web pages. The fact that it allows GET to be used for unsafe operations is unfortunate, but the fact is that I know few people who would ever actually use it that way. As someone else mentioned in one of the replies to that post, any framework can be abused. That is generally the fault of the developer, not the framework.

Further, the "rails developers" you accuse of being immature for complaining about it consisted of -- who else? -- David Heinemeier Hansson. Not the "rails community". If you were not aware of this already, then let me inform you: that was 5 years ago and since then the "rails community" itself, on more than one occasion, has derided DHH for his frequent immature behavior.

Your last point, about the word "professional", was again a reference to DHH personally and not "the rails community". Further yet, what he was referring to was the way the word "professional", like some other phrases, has been abused... he was not insulting professionals. In fact he made no references at all to "professionals" or "professionalism".

In summary, you are guilty of accusing a whole multitude -- thousands of people -- of being immature, almost entirely because of the actions of one person. Remind me again... who is being immature here?

Re:It's a nice framework

[xiong.chiamiov]

Ruby 3.0 is a long ways off. You probably want Rails 3.0 and Ruby 1.9.

Great release

[jgeiger]

A lot of the changes have made the code much more modular. You don't need to include everything if you don't need it. This also allows you to plug in other database adapters if you want. One of the nice routing changes allows you to call Rack or Sinatra applications from within your Rails application. I'm really looking forward to using this going forward.

Re:Too bad

[MarkRose]

And just what do you hope to achieve by railing against it?

Re:Just upgraded from 3.0.0.rc2

[Anonymous Coward]

When RC2 was released they said that they had to work on the ORM layer to speed things up before final release, less than a week later and the final release is here without any significant speed-up...

Community issues

[gwolf]

I am a long-time Rails user - Started playing with it before 1.0, and have applications in production since the 1.1 days.

Rails is _great_, and it helps lots to productivity. However, its community is too young - the whole "latest version or deep-fried" attitude really hurts.

A community of assorted modules' authors has sprung around Rails and its Agile practices, which is good. However, most of those modules (gems) have (contrary to Rails, which at last has grown and is a mature project by now) very unsound practices - Say, API-incompatible changes in minor versions, or announcing major versions every month or two. And then telling you that via Gems you can keep several co-installed version. Oh, but please, do not bother them to fix bugs in older versions. Or gems adding other gems as dependencies, even when said gems are nowhere near production quality.

I maintaining for Debian several Ruby modules. And believe me, while I try to do a decent job, it gets harder, and I have ended up maintaining a lot of crappy modules that were at some point dependencies... Or the "flavor of the day" which was superseded by a new, "faster, DRYer, nicer, better!" implementation... which gradually builds up cruft and gets replaced as well.