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

oh

[omidaladini]

I can hear my 2.3.8 app breaking!

Re:oh

[SanityInAnarchy]

Theoretically, if your 2.3.8 app ran with no warnings, it's also a valid 3.0 app.

Re:oh

[telekon]

it is for now... but it will be a deprecated 3.1 app, and a completely borked 3.2 app: http://m.onkey.org/2010/1/22/active-record-query-interface

Re:oh

[Per Wigren]

...unless one installs the official plugin with support for the "old style" query interface that they will supply, as noted in the article you linked to.

Re:oh

[telekon]

you could do that... but it would be better just to refactor and take advantage of lazy-loading queries using the new finder methods.

Re:oh

[SanityInAnarchy]

Point is, while there are distinct advantages to keeping up with Rails development, no one's forcing you to, which is a common point of FUD for people new to the Ruby community.

Re:oh

[Anonymous Coward]

Is the other common point the bizarre cult-like mentality you people have?

Re:oh

[SanityInAnarchy]

Yes -- that is another common point of FUD.

Re:oh

[telekon]

Very true. I started the new app I'm developing at work on Rails 3/ruby 1.9.2 b/c I needed newer features... but there are no plans to stop developing Rails 2.3.x or Ruby 1.8.x for the immediate future.

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?

[halfaperson]

Agreed. Rapid changes are also more expected since it is a (comparatively) new framework. Development of fancy features is likely to slow down as the code base matures.

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

[omidaladini]

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.

Re:It's a nice framework

[Anonymous Coward]

That's why I use Grails. It's RoR for grown ups. FLAME ON!!!

Re:It's a nice framework

[Anonymous Coward]

That's why I use Django. It's Grails for people who don't want to try to figure out how many GB they need to allocate on the JVM commandline.

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]

grown up as in *not* arrogant ranting pricks.

I didn't realize DHH had left the Rails community.

Re:It's a nice framework

[Ukab the Great]

But I do wish the community would grow up.

You're preaching to the choir, but I seriously doubt that the Python or PHP community you're referring to will grow up enough stop the needless and harmful proliferation of ORM frameworks (Django, Turbogears, Zope, PHP Cake, Symfony, Codeigniter) that wastes developer time and store bookshelves and instead learn from Rails and Merb's excellent example of putting community ahead of ego's and redirecting the entire community's programming and documentation efforts into a one single excellent framework.

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

[Anonymous Coward]

Python a favourite of slashdot? Woa, where did the whitespace-as-indentation haters go? Where are the pry-my-curly-braces-from-my-dead-fingers people? Is this some sort of alternative universe I'm in?

Re:It's a nice framework

[VGPowerlord]

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.

No, seriously, when a JVM-based Ruby interpreter can outperform the C Ruby interpreter, the C version has speed problems.

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.

If you're still butthurt about something that happened 3 years ago, perhaps you should consider choking to death on a sack of dicks.

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

[Anonymous Coward]

then use the JVM-based Ruby interpreter. JRuby works great with rails and you get access to a huge amount of java libraries .

Re:It's a nice framework

[Anonymous Coward]

I'm mostly referring to experiences on the Rails support forums, when questions received snarky responses often as not. I understand that "Rails is opinionated software," but that shouldn't result in a Spanish Inquisition when you question how or why the Rails "magic" works the way it does. Just because Rails is opinionated doesn't mean that it is always right.

But like I said: The 3.0 framework is really nice, and some of its new features (ORM- and JS library-agnostic, for example) seem to suggest that the needs of enterprise developers are being taken more seriously now than in the past.

Re:It's a nice framework

[wmac]

Not for me. As a programmer of 25 years, I developed a relatively big website (a shop) using Rails. But it was such a pain for me. I was spending a lot of time just to find workarounds and to see how can I do a simple thing in Rails (which I would do in PHP in 10 minutes).

It is not flexible enough for me. If I really want to force myself into a framework I'll stick with Zend. For smaller websites I just use my own small framework.

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

[Jane Q. Public]

If you are basing your development decisions on the perceived attitudes of other people who use it, what does that make you? (Hint: "rational" isn't it.)

And if people who use Rails are "ranting pricks", what does that make the Pythonistas? Not to mention that's supposedly a more "mature" environment.

Re:It's a nice framework

[Jane Q. Public]

Sure. The only problem being that, as replies to that post show, you were wrong in your assumptions.

Re:It's a nice framework

[XorNand]

Python and Ruby are in no way similar, other than the fact that they're both open-source OOP languages. They have completely opposing design philosophies: Python's "one right way to do it" vs. Ruby's "give the developer enough rope to hang himself."

Re:It's a nice framework

[Jane Q. Public]

The fact that you don't know how to do something with a framework (especially on your first real project) does not mean that the feature isn't there. If you were to give me specific examples of what you were trying to do, I suspect that I could show you how it is already implemented in Rails.

Seriously. "Not flexible enough" is not an objection I have ever heard from ANYBODY who knew much about Rails.

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 might explain the high concentration of assholes in the ruby community. I wouldn't hire anyone that uses Mac or iPhone

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

At the rate Ruby is fading, it won't take for long. It will never go away completely, but relevance is pretty much done for.

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

[Bogtha]

Which assumptions and replies are you referring to?

Re:It's a nice framework

[nvrrobx]

Except the fact that Django, TurboGears, Zope, etc are not ORM frameworks. They're entire web frameworks, that happen to have an ORM inside them.

The work on multiple frameworks helps to innovate and drive the others - one monolithic technology stack as the only option is double-plus-ungood. Sure, it's good for those who can't do research and choose the right tool for the job.

I was personally turned off by the attitudes I saw on the mailing lists for Rails. Granted, this was a few years ago, and I hope things have changed, but I'm sure they haven't. It's almost like expecting the JBoss team to grow up. Nice in theory, probably won't happen.

Re:It's a nice framework

[Anonymous Coward]

> I wouldn't hire anyone that uses Mac or iPhone

This demonstrating to everyone that you have never hired someone nor ever been in a position to influence a decision to hire someone.

Re:It's a nice framework

[Anonymous Coward]

Where ever there is criticism of Ruby or RoR, Jane Q Public is there with his misinformation campaign!

Re:It's a nice framework

[hesaigo999ca]

As a ruby newb and future ruby web developer, what did you find better in terms of programming versus the usual python or PHP? What would you also consider telling someone starting off with ruby3.0 to avoid any unnecessary lost time (setup,modules,etc...) and help a newcomer start programming quickly.

Re:It's a nice framework

[bonch]

One of my biggest issues with Ruby on Rails at the beginning was how difficult it was to find real documentation. Everything was a tutorial or "screencast" about scaffolding. They were so obsessed with doing CRUD in 5 minutes that it was hard to find out how to go outside the bounds and write anything real. There was a ton of hype over the framework until everyone found out how slow it was and how rigid things were if you didn't follow its conventions. But the community was just so into the very idea of Ruby on Rails that you couldn't communicate this to them.

Re:It's a nice framework

[Anonymous Coward]

I regularly interview job applicants.

I usually expect them to run Linux at home (and boycott iPhone ;-).

Re:It's a nice framework

[Samus]

Just curious, if Ruby is fading what do you see taking its place? My opinion is that it is just coming into its own. YARV and other proper vms are maturing at a rapid rate and Rails 3 seems to be a pretty nice framework. The testability with Cucumber and/or the other types of frameworks is beyond most anything I've seen lately. This is all coming from one who has been exploring Ruby and Rails for the last couple months.

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

[not-my-real-name]

What if they run Linux, MacOS, Windows, OpenBSD, etc at home?

Re:It's a nice framework

[SanityInAnarchy]

Nah, he just grew up a bit.

Re:It's a nice framework

[SanityInAnarchy]

That's a pretty standard political move -- though I would like to think our development communities are more mature than American politics, I'm not sure it has to be.

Re:It's a nice framework

[SanityInAnarchy]

The same place the perl-is-line-noise people went -- nowhere.

Bring up pretty much any language on Slashdot, and you're going to get hate.

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

[SanityInAnarchy]

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.

Erm, so what? I use Rails, and I have no ambitions to ever work for 37signals.

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

I showed up to Railsconf with a Dell running Ubuntu. I wasn't the only one, and I noticed another one of the conference-goers had set up a wireless access point called "I Hate Mac Fags."

Even if it weren't for the 'tude

Problem is, the Rails community is getting a little too diverse for this "tude" you describe to apply to any significant chunk of it.

You pay a high performance price for the dynamic nature of Ruby whether you need it or not.

You do. Or, specifically, Rails does -- it wouldn't be the framework it is without a language like Ruby to support it. Even if you didn't need it, it's surprisingly useful.

That said, it's not nearly as high as you think it is. What are you using instead? PHP? Show me a Rails-like framework in PHP, and I'll bet money it'll perform worse.

If you can find areas where you can prove you "don't need" that dynamism, you can always rewrite that chunk in C -- or Java, if you're running JRuby. Most of the time, it's just not worth it -- your time is more valuable than CPU time, and Rails can scale horizontally.

Re:It's a nice framework

[Anonymous Coward]

Linux + Windows makes sense (can't discriminate against gamers), as long as Linux is there *somewhere*, getting significant desktop use.

Re:It's a nice framework

[SanityInAnarchy]

But these serve different purposes. The kind of app you'd use Sinatra for is the kind of app Rails would be worse at, and vice versa. Sinatra is more in the same space as Camping, and I don't know if anyone still uses Camping.

The others to compare would be things like Ramaze.

Re:It's a nice framework

[SanityInAnarchy]

No, seriously, when a JVM-based Ruby interpreter can outperform the C Ruby interpreter, the C version has speed problems.

Or the JVM runtime is better?

Hint: It's not an interpreter. It's a JIT-compiler which translates Ruby to Java bytecode. It's no surprise that this performs better than the C version, which is a bytecode interpreter -- the Java bytecode will be JIT-compiled again by Java into native code.

I don't disagree that there's room for improvement, but this whole "Ruby is slow" meme has got to stop. Slower than what, at doing what, and why do you care? Answer those questions, and we'll have something to talk about.

Re:It's a nice framework

[SanityInAnarchy]

"Not flexible enough" is not an objection I have ever heard from ANYBODY who knew much about Rails.

I'll say it, then: Rails 2 wasn't as flexible as I wanted it to be. More than once, I had to monkey-patch things to make it do what I wanted. It was flexible because of Ruby and in spite of Rails.

Rails 3 changes a lot of that, but it's not a completely baseless accusation -- though the "I would do in PHP in 10 minutes" makes me a little scared of what kind of PHP code it would be.

Re:It's a nice framework

[Jane Q. Public]

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

No, I did not call you immature at all. Maybe you should work on your reading comprehension a bit. What I wrote was that you were not being rational.

And I did not refer to myself at all. Why do you include me in the "Rails community"? Just because I have some familiarity with it? Hey, I can program using .NET, too... that doesn't make me a Microsofty... or even a regular user of Windows.

Re:It's a nice framework

[jesset77]

Show me a Rails-like framework in PHP, and I'll bet money it'll perform worse.

Umm, CakePHP. A quick google doesn't show me any comparative benchmarks less than 2 years old though.

I'll take another look at Rails now. Haven't tried in 3+ years, and at the time I had trouble with inconsistent library calling conventions (same gripe I have with Java Swing and AWT before it) and significant challenges making it play nice with Apache in a manner comparable to mod_php. (has mod_ruby come of age, yet? ;3)

Re:It's a nice framework

[Per Wigren]

Yes, it's true that historically, Ruby has been slow. Ruby 1.9.x is a LOT faster than Ruby 1.8.x though, and Rails 3.0 is fully compatible with the latest Ruby 1.9.2.

There are also other Ruby implementations under way, most notably Rubinius which is often even faster already and has potential to become REALLY fast once they start optimizing it.

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

[Anonymous Coward]

Just curious, if Ruby is fading what do you see taking its place?

More "conservevative" and mature stuff - Java, Python, PHP (unfortunately), .NET.

It's not because of any specific problem in ruby as such, but general cooling down of the initial RoR craze. It's all a bit more level headed now.

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

[Jane Q. Public]

But neither of you has supplied an example. That's what I was asking for: an example, not just another opinion.

Re:It's a nice framework

[Jane Q. Public]

"Where ever there is criticism of Ruby or RoR, Jane Q Public is there with his misinformation campaign!"

Interesting comment, considering that I have mainly been asking questions here, not "informing" anybody... much less misinforming.

I suspect that the comment was made more for personal than factual reasons.

Re:It's a nice framework

[xiong.chiamiov]

But these serve different purposes. The kind of app you'd use Sinatra for is the kind of app Rails would be worse at, and vice versa. Sinatra is more in the same space as Camping, and I don't know if anyone still uses Camping.

Sure, but hasn't the Python community kinda imbraced Django as the One True fullstack framework?

Re:It's a nice framework

[xiong.chiamiov]

Embraced, dammit.

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.

Re:It's a nice framework

[Jane Q. Public]

I would start HERE. It starts from the beginning, and covers Rails 3.

You'll probably find, though, that most developers aren't that familiar with Rails 3.0 yet, even though most of the features have been known for some time and betas have been out, because what they're actually doing at work is still in 2.3.5 or earlier. So you might actually get a leg up on some of the established developers if you get to know 3.0 early.

Re:It's a nice framework

[DragonWriter]

It's a JIT-compiler which translates Ruby to Java bytecode. It's no surprise that this performs better than the C version, which is a bytecode interpreter -- the Java bytecode will be JIT-compiled again by Java into native code.

The only current benchmarks I've seen (which can't be trusted any further than most benchmarks, but what else are you going to use) show the current, bytecode interpreting, C-based Ruby (Ruby 1.9.2p0) outperforming JRuby 1.5.1 everywhere where the two aren't approximately equal.

Earlier versions of JRuby outperformed, across the board (except when using the obscure features that JRuby doesn't implement at all, like continuations which, at the time, were pretty poorly implemented in the C-based implementation) Ruby 1.8.x, which didn't compile to bytecode and run on a VM, but was a plain old AST-walking interpreter. Ruby 1.8.x was notably slow, even among dynamic "scripting" languages. Ruby 1.9.2 is far from fast, but seems to be roughly in the same ballpark as current Perl and Python implementations.

Re:It's a nice framework

[SanityInAnarchy]

One example was the ability to override controller_path on a controller instance, or with at least some context from the current controller, rather than only on the class. I was using this to have one controller masquerade as another, depending on the context.

I don't remember why I was doing it that way, and it's entirely possible there's a better way. That's one thing I like about Rails being rigid sometimes, and about working with a framework at all -- it sometimes forces me into doing things the right way, instead of the sloppy way.

But this one, I had to monkey-patch Rails, and the only way to do so was incredibly ugly -- I had to override all of ActionController::Base#default_template_name, at least, just to make a one-line change.

I did get that one-line patch back into rails-core, so this isn't much of a complaint. All I'm saying is, to suggest that Rails has no limitations is naive and almost missing the point of Rails.

Re:It's a nice framework

[binary paladin]

Of course... why bother using Apache when we have nginx?

Re:It's a nice framework

[Forbman]

or, another translation, "I can't wrap my brain around Rails/Ruby, and wish I could do things the way I would do them in [fill in the blank]".

If I didn't like SQL joins, and all my experience was with non-SQL databases, I'd probably feel at home using cursors. Doesn't make it right (but they do have a few uses, but they don't call those edge cases without reason...).

Re:It's a nice framework

[Forbman]

And, plenty of companies won't hire you if you know how to use SharpDevelop or Eclipse for C# programming, because everyone else there uses Visual Studio.

What 37Signals chooses for its internal development environment is its choice.

Re:It's a nice framework

[Anonymous Coward]

Over nginx instead of apache if you can.

Re:It's a nice framework

[hesaigo999ca]

thank you for this

Re:It's a nice framework

[SanityInAnarchy]

or, another translation, "I can't wrap my brain around Rails/Ruby, and wish I could do things the way I would do them in [fill in the blank]".

While that's often the case, I've got a patch in rails-core, I've got over a year of Rails experience, and I've written a few Sinatra toys which run on Google App Engine.

So yeah, I think it's reasonable to say that I know Rails and Ruby.

Re:It's a nice framework

[John_Booty]

You pay a high performance price for the dynamic nature of Ruby whether you need it or not.

I don't think that's accurate at all. Typically, your choice of web framework/language is never even close to being your performance bottleneck anyway - it's the data storage layer that's doing all of the heavy lifting. MySql isn't any faster or slower whether you're calling it from Ruby, C#, COBOL, or hand-tuned machine language.

When I say "typically," I realize that's a nebulous term and that there's no "average" web application. What I'm thinking of as typical is a small/medium server that's serving up to several million page views a month, several database calls per page view, with a database perhaps 50MB-10GB in size.

Re:It's a nice framework

[John_Booty]

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.

This is absolutely true. Developer time is in shorter supply than CPU cycles. Additionally, in most web applications, it's the data storage layer that's doing the heavy lifting anyway. In my experience with small/medium sites, about 90-95% of the time it takes to generate a response is tied up just waiting for database calls to complete. If a page takes 50ms to generate I'm usually looking at about 5ms spent in the framework and 45ms in the database.

Re:It's a nice framework

[John_Booty]

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

Non-rhetorical question: when you write web applications, do you ever do anything performance-intensive in the framework/application layer?

I don't know about you, but in my experience with small/medium sites, the execution time of the ASP.NET/Ruby/whatever code is absolutely dwarfed by the execution time of the database calls.

Usually, all the framework/application layer is really doing for each page request is grabbing some data from the database and spitting out some markup. It's not rocket science, and no matter how slow my framework is (including like, VBscript-powered ASP "classic" ...yuck) I've never found it to be a performance bottleneck.

I am sure that there are web applications where perhaps it would come into play. Sites that do heavy manipulation of images or other media types in the application layer are obvious candidates. I am sure there are others.

Re:It's a nice framework

[Anonymous Coward]

"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."

Now, I'm not really interested in Ruby, Python, or Perl, I prefer to stick to more prominently used languages in business like Java, C++ and C#, but this comment strikes me as perhaps an example of a lack of maturity, it sounds purely like fanboy reasoning- "Slashdot doesn't like Ruby because they're Python fans" or whatever.

If this is an example of trying to show off the Ruby community in a good light, then it's failed. You were doing well until you made this childish jibe- personally I too was wondering about some examples of immaturity in the community because it may be that I will be involved with Ruby at some point and I wanted to know what I might expect if I ever do. Adding this jibe to the end of what would otherwise be a perfectly fair comment doesn't help fill me with confidence about the Ruby community.

Re:It's a nice framework

[mini me]

That immediately alienated what, 90, 85 percent?

I believe that was their intention. Many companies use university degrees to filter out 90% of their potential application base, but 37Signals have stated on many occasions that they do not hold a degree to any kind of standard (it is not good to have one, and it is not bad to have one, it just doesn't matter). Therefore, they need to find some other way to scare off people who are not really serious about the job, so to speak.

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:So...

[haystor]

You just need to convert more Java guys to keep telling everyone it's not slow.

Just upgraded from 3.0.0.rc2

[alkaloids]

I just upgraded an app we've been developing in 3.0.0.rc2 and it went smoothly. Looking forward to actually having the docs in place. It's really been a lot of fun implementing the new changes and I'm excited for everything - hopefully the performance issues will get there, though, I've heard (though not personally observed) that the ActiveRecord in rails3 is something like 50% as fast as 2.3.5 was...

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...

Re:Just upgraded from 3.0.0.rc2

[Anonymous Coward]

Just use the Sequel ORM.

http://sequel.rubyforge.org/

Allow me to be the first to say....

[FooAtWFU]

choo choo!

Re:Too bad

[Anonymous Coward]

Perhaps put everyone back on the right track.

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.

Re:Community issues

[Jane Q. Public]

Agile and Rails do not necessarily have anything to do with each other. Lots of Rails coders do not work in Agile environments, and vice versa.

Re:Community issues

[DragonWriter]

Agile and Rails do not necessarily have anything to do with each other.

Other than the fact that the main purpose of Rails around which many design decisions are made is enabling Agile web development, sure, they don't have anything to do with each other.

Sure, you can use any toolkit with any development approach, but that doesn't mean that the toolkit is approach agnostic.

Re:Community issues

[Jane Q. Public]

"... the main purpose of Rails around which many design decisions are made is enabling Agile web development..."

Can you give me a specific example of a design decision that enables Agile development more than it enables other development paradigms?

Re:Community issues

[DragonWriter]

Can you give me a specific example of a design decision that enables Agile development more than it enables other development paradigms?

I can certainly name design decisions that appear to be directed at enabling Agile development (or, perhaps more specifically, iterative development around evolving specifications) -- migrations, scaffolding, and much of the "convention over configuration" approach which is are all obvious examples.

These things that reduce the workload to get something working when some aspect of the intended behavior is specified and others aren't, and which keep the cost of change was something is working low, is essential to agile development, but less essential (up front) in some other approaches (particularly big-bang waterfall development.)

OTOH, I would say that in the end they are Agile-specific, because Agile development is, itself, largely an outgrowth of the observation that adaptability to change is essential in real systems, so that is something that should be baked-in from early in the development process. But the necessity of that doesn't go away if you use a different development methodology, though the importance of the features that reduce the cost of change may get pushed out to the maintenance & operations phase of the traditional lifecyle as opposed to the development phase.

Re:So...

[SanityInAnarchy]

have they made it stop be slow as shit?

If I pretend that's a complete sentence, then yes, for some time now.

Comparison against Grails

[invalid-access]

I've been a C/C++ programmer for a fair bit, and am starting to dabble in some web-dev for a startup idea a couple friends have. Can someone tell me how the newer versions of Rails/Ruby compare against the newer versions of Grails/Groovy? I don't want intend for this to be a troll/flame fest, I'm just under-informed on the tradeoffs. Thanks in advance for any info.

Rails 3 vs. a weird OS 10.6 configuration...

[Money for Nothin']

It might just be my configuration (installed Ruby 1.9.1 via MacPorts). Here's my Rails 3 install attempt:

bash-3.2# /opt/local/bin/gem1.9 install rails --version 3.0.0
Successfully installed rails-3.0.0
1 gem installed
Installing ri documentation for rails-3.0.0...
ERROR: While executing gem ... (Errno::ENOENT)
        No such file or directory - lib

The gem installed, but without docs. WTF.

I spent the last month fighting with Ruby 1.9.1 + RoR 2.3.8 on OS 10.6, trying to get it to connect to MySQL, Postgres, or Sqlite. The database connectors (mysql, pg, etc.) for all 3 failed. I wish I knew how to start fresh with Ruby and RoR on OSX, but I don't know where gem and MacPorts have installed everything. I might consider it again if:

1) I can use Ruby 1.9.[12], not the OSX-installed 1.8.7.
2) I had any idea how to wipe all the Ruby/RoR stuff without wiping/reinstalling OSX. I'm sure it's perhaps only a dozen commands, but I'm so tired of fighting with RoR dependencies that I gave-up a week ago.

In its place, I got Python + Django + Postgres working together in about 1 hour, including time required to find a couple nice tutorials, download the Django source, build it, install it, and configure it. I don't like the double-underscore "magic method" syntax I'm finding for e.g. filtering methods though, and prefer Ruby's lambda expressions instead (blame my C# + LINQ experience professionally)...

(Waiting for somebody to tell me to go with what I know and use C# in Mono on OSX instead. :P )

Re:Rails 3 vs. a weird OS 10.6 configuration...

[lunatic77]

I think RVM is exactly what you're looking for.

Re:Rails 3 vs. a weird OS 10.6 configuration...

[binary paladin]

I do my Rails dev in OS 10.6 and, frankly, stopped using MacPorts some time ago. I try to keep my machine as vanilla as possible but...

I install a few special libraries and other things by hand to /usr/local using --prefix= and make sure that everything in /usr/local takes precedence over /usr. I just upgraded to Ruby 1.9.2 today to go with Rails 3.0 (since it complained about my 1.9.1 install) and this setup has worked for for me since 10.6 was released.

Apple's 1.8.7 sits where it's always sat and, whenever I want to start over I can just blow away everything in /usr/local.