Slashdot Mirror
Restructured Ruby on Rails 3.0 Hits Beta
Curlsman informs us that the first beta of Ruby on Rails 3.0 has been released (release notes here). Rails founder David Heinemeier Hansson blogged that RoR 3.0 "feels lighter, more agile, and easier to understand." This release is the first the Merb team has participated in. Merb is a model-view-controller framework written in Ruby, and they joined the RoR development effort over a year ago. Reader Curlsman asks, "So, is version 3 of RoR going to be a big deal, more of the same (good or bad), or just churning technology?"
Please pick form the list below
Ruby and/or Rails sucks because:
1. It doesn't scale (Twitter)
2. It's slow
3. I read somewhere that Python was a better language
4. I write PHP, I can do everything Ruby/Rails can do better
5. My obnoxious younger coworker uses it
6. It's not lightweight enough
7. The ruby community is full of over-hyping zelous twits
Ruby and/or Rails is awesome because:
1. It scales within reason (Twitter, Lighthouse, Shopify)
2. It's as fast as Python and PHP
3. I read somewhere it was better than Python
4. I used to write PHP, Ruby's been a godsend
5. There are so many motivated and innovative people in the community
6. It's featureful
7. Pythonistas are over-hyping jealous twits
Photos.
It's praises are sung by the same group that think MySQL is the ultimate enterprise database.
Everyone knows the real ultimate enterprise database is Access.
I've used Rails on five projects now. To be honest, I think it has made me more and more miserable with each project.
First, I truly dislike "convention over configuration". The main problem there is that they "convention" they use is far too limited for any sizable application. It may be sufficient for a blog web app, or a bug tracker, or small-scale applications like that. But we now have one web app with over 900 controllers, and "convention" falls apart at this size. Sure, we probably should refactor our app, but we're not in a position to do so at the moment.
The same goes for ActiveRecord. It's great in simple cases, but falls apart rapidly when you're developing larger web apps, especially when you're performing complex data retrieval. It gets even worse if you need to optimize that data retrieval. At this point, ActiveRecord becomes a huge pain in the ass, rather than a useful tool.
And like it or not, the performance of Ruby is quite poor. We actually had to purchase some additional hardware to handle the extra load after converting an old Java-based web app to Ruby on Rails. We tried to optimize it, but were spending far too much time fighting with Ruby on Rails and its abstractions. It was cheaper just to buy more hardware.
you're taking "ruby is really slow" and trying to spin it into an advantage.
Nope, I'm saying Ruby is optimizing something else -- developer time. That isn't to say it will never be fast, and last I checked, the full Merb stack (and Rails 3.0 is also Merb 2.0) was on par with PHP.
It's also not that it's hard, it's that it's expensive, and a needless expense. Let me put it another way: Do you watch YouTube, ever? (Replace YouTube with Vimeo or any other Flash video website.) Do you ever bother to download a video just to watch it? I mean, you do realize that VLC takes a fraction of the CPU cycles that Flash does, for the same video, right?
But no, I bet you're just like 99% of the population -- it may burn more CPU, it may burn more battery, but you're going to just watch it in the Flash player until you have a good reason not to.
If it was really an issue, if your computer was so old and so slow that the Flash wouldn't play properly... Weigh the amount of time you'd spend in a video downloader against the cost of a low-end PC, and it's a no-brainer.
Ruby on Rails can't be optimized!
Nope, it certainly can, it's just hard, and may (in an absolute worst case) involve replacing parts of it with another language, like C extensions -- not an entirely alien idea to any game developer who's replaced bits of C++ with assembly. (No one would sanely claim that the next blockbuster game should be written in assembly for speed -- you optimize the tight loops that way, but the game logic should be higher level.)
And it's just an observation, I'm not sure if it's cultural or if it's the slowness, but it seems like Ruby people, especially Rails people, focus on horizontal scalability and optimizing their algorithms in the broad sense -- again, O(logn) vs O(n^2). Java vs Ruby is the difference between two servers and four, or a request taking 50 ms vs 100 ms. Your application logic is the difference between four servers and twenty (or not being able to scale at all), or between 100 ms and 2000 ms (or two days, or crash the server because you ran out of RAM).
These are good lessons for any system, but Ruby people seem to be especially conscious of it. Still, I think it illustrates something -- the language is going to be the least of your problems when it comes to optimizing any app, until you're at a much larger scale than 2-4 machines -- think hundreds. Eventually, it may be worth rewriting large chunks of your app, or doing a ground-up rewrite, in a more efficient language -- or it may be worth improving the interpreter of the language you've got (as Facebook has).
But you have to get there first. If you're busy doing Java because you want it to be efficient, and I steal all your marketshare because I write one line of Ruby for every five lines of Java, and I get to market while you've got a prototype with 20% of the functionality... I win. Even if I have to rewrite it all in Java later, I have the money to do that, because I've got the traffic.
Don't thank God, thank a doctor!