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.
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.
Apple makes opinionated hardware. Rails is opinionated software. It's not surprising that the two fan bases act similarly. In fact, I would bet that there is a lot of overlap between the two groups.
Hmm, can you explain why? I haven't worked with Rails much, but in Django, if things are too slow like in a really complex query spanning so many tables that the PostgreSQL optimizer chokes, you can hand optimize it easily by either rewriting how you specify it in python, breaking it up into multiple statements. You can also choose to retrieve the data as plain tuples or map/dicts if you need to fetch thousands of rows (100k+, I've no problem with 20k/query the normal way at all). If all fails, plain sql is just 2 statements away, with an easy way to turn the results back into objects.
A good ORM recognizes that there are situations that falls outside of the common/simple use cases and should assist you in the harder things, not work against you.
I haven't actually used RoR, but you have to admit that this sounds like you're taking "ruby is really slow" and trying to spin it into an advantage.
"Most people end up having to optimize eventually. But that's hard. Ruby on Rails can't be optimized! You just have to buy more hardware! Isn't it great!"
Breaking Into the Industry - A development log about starting a game studio.
While it may not be your preference, applications written in Ruby are supposed to be written in such a way that they are self documenting. Contrary to other languages, the expressiveness of Ruby allows the developer to write code that means as much, if not more, than formal documentation.
Yeah, sure... I've inherited plenty of code by people who were religious about the "no comments" idea. Utter nonsense.
Yes, my own code is as self documented as possible. It shows HOW, but it can't show WHY. Code alone can 't describe the overall context of why that code, and now some other code, or how it fits into the whole. That's what comment blocks are for.
Otherwise, you're just doing like the current US government, and burdening future generations with the true cost of today's "short cuts." It's self-centered and short-sighted.
If it is truly "throw away" code, fine. Don't comment it. But that is about 0.001 % of all the code I've seen in the last 25 years.. Good rule of thumb is that all code lives forever, and will be read 100 times for every time it is read. Thus the ROI on comments is enormous and always worth doing.
Not true.
Model.find_by_sql sqlstring
or even more primitively:
ActiveRecord::Base.connection.execute( sqlstring )
Easy. Although you really shouldn't have to use it if you understand relations properly.
Also note that rails 3 is going to have Arel, an Object-Oriented interpretation of the Relational Algebra. It is a mathematical model for representing “queries” on data. It understanding relations this fundamentally means it can optimise easily.
Have a look at:
http://magicscalingsprinkles.wordpress.com/2010/01/28/why-i-wrote-arel/
I am a php developer that does a lot of small to medium sized apps using zend framework. I don't plan on doing anything enterprise scale, my niche is what it is. Do you see any advantage to zend framework over ROR?
I don't know Ruby or Rails well yet. But I do know PHP pretty well. And my answer is: no. Not as a framework.
Zend Framework isn't a web application skeleton / development system. It's an over-objectified library of barely related pieces. Yeah, there's a controller and a recommended directory layout, and you can pull it together with the rest of the library and a project or two elsewhere (say, Doctrine and Smarty), but it's not a thought-out whole. The job of creating an overall architecture for your app and getting the components to work together becomes yours.
Maybe that's what you want, and if so, then Zend Framework or doing things by pieces in Ruby (say, Sinatra + Sequel + HAML/SASS) could be for you. But if you want an actual web application framework, then I'd look at something like Code Igniter or Symfony (for PHP) or Rails or Merb (for Ruby) instead.
Tweet, tweet.
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!
What is the point of writing something that tries to look sensible and objective and then round it off with the utterly subjective "Python is for masochists, Ruby is cleaner"?
The only explanation: Your subconscious knows the obvious fact that Python is a beautiful language and thus subverted your entire comment.
Everyone knows the real ultimate enterprise database is Access.
If by "ultimate" you mean "last because it killed the enterprise stone dead through sheer crap-ness" then yes, everyone does indeed know that.
"Little does he know, but there is no 'I' in 'Idiot'!"