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 never heard that Rails would make "programmers obsolete", in fact it seems to be the opposite; if you look at the official Rails site you'll notice that the biggest tag-line is "optimized for developer happiness".
Rails makes developers happier, not unemployed. What's more, anyone can write bad code in any language, so pointing to Twitter is hardly a conclusive argument. There are lots of big Rails sites out there, including Basecamp, the original Rails application.
For a better (and longer) write up on scaling Rails, I refer you to this article.
I'm glad first responses are so negative; now I don't have to bother trying ROR out.
Over at Ruby Inside we did (and are maintaining) a roundup of ~36 Rails 3.0 beta links/articles (it's up to about 40 now, I think). If you've got Rails 3.0 installed and want to know how to use X or Y or want to learn some of the back story/motivation, the links should come in useful. They're only things that are actually worth reading. Well, mostly.. :-)
Rails makes developers happier, not unemployed.
When you've had a lousy job, the two aren't mutually exclusive. I want assurances that they don't intend to make me happier BY making me unemployed ;-)
These posts express my own personal views, not those of my employer
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.
I can't say my experience matches yours. There are two testing modules shipped by default with Python. Django has integrated support for them out-of-the-box. Django itself has plenty of tests. There are plenty of good third-party testing modules and people are pretty vocal about using them.
On the other hand, I do very strongly get the impression that the lax attitude of "I tried it in my browser so it works" is omnipresent in the Rails community, coming right from the top. Witness the uproar over the Google web accelerator. Rails was just plain wrong to use GET for unsafe operations. But "it worked in a browser", so they didn't see anything wrong with it, even though it was out of spec. GWA came along and triggered data-loss bugs in Rails applications that used unsafe behaviour for GET requests, including 37signals' applications. Rails developers, rather than simply saying "whoops, our bad, we'll fix this ASAP", called GWA evil and wrote code to block GWA. Roll forward a year, GWA changes its behaviour and the blocks don't work any more, the same things happen all over again, and the Rails developers call GWA "scary" and "malicious". 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.
As for the word "professional" in particular, that's a dirty word in the Rails community.
Bogtha Bogtha Bogtha
It's a double-edged sword.
I've been involved with rails pretty extensively now for a few years, and i've enjoyed the platform for the most part. A few projects we've launched have grown pretty complex, and we too have had some problems with the code management, but discipline seems to help and a steady peer review.
Ive been working with Java pretty much exclusively since the late 90's, with exception of the last few years which have been focused on Rails projects. I've recently been working with Grails (Grails.org) which is a Java based stack taking the great concepts from RoR platform.
As someone who has never worked with Java, I believe that Grails might not be as easy to pickup and learn, but as someone who has an extensive Java background, it's a serious breath of fresh air. For a large scale project, I MUCH prefer grails code management to rails approach. Obviously with my Java background, i'm partial to Grails.
On the note of deployed code, a few of our rails projects have grown to be pretty large. I've had to implement a LOT of hardware to handle the scaling of usage. We've been able to do a lot of improvements to the code, but compared to the speed and efficiency of Java (Yeah, I never thought i'd say that) I'm a little bit 'burnt' on rails.
Comparing something like Passenger on Apache to Glassfish or Tomcat is like getting out of a 2009 BMW 5 series and jumping into a 1991 Kia.
The first time in YEARS i have had run-away processes take down an entire server, I've migrated all of our servers to Xen servers because i got tired of driving to the datacenter 1-2x a week or making a remote hands call to reboot a server because a zealous process took things down. (Did I mention i bought a load balancer to manage the traffic, i'm doing on 10 machines what i used to do on 3 machines w/my java apps)..
I'm sure that there are folks that know Rails better than I do, we're a do-everything group (4 guys managing a LOT of code and servers), not a large IT shop by any stretch, but on one hand we've hit epic levels of productivity. We've gotten projects out fast, and some of them have done well. We've had other projects we assumed would do great, but ended up failing due to marketing miscalculations. The lesson I'd say i've learned with Rails, is it's better to get a 'good enough' product out the door and then figure out how to tighten it down later than not even make it to the race.
I'm hoping that i can bypass that compromise with Grails, but time will tell. :)
Either way , Rails absolutely has it's place in the Open Source server software stack world. In the end it's just a matter of remembering that if you are doing rails programming, you better be doing it with a Test-Driven development style, as large projects can get out of control.
I've not looked at RoR 3.0, but i'm hoping that they have implemented a Service-style implementation for business logic, rather than encouraging to have it thrown into the Models.
Funny, my experience of the Rails community is that it attracts a lot of crackpots who don't believe in documentation--not even API documentation.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
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.
First, yes,
we probably should refactor our app, but we're not in a position to do so at the moment.
you should, and this would be biting you in the ass just as much with other technologies.
But keep in mind, "convention over configuration" is not "convention instead of configuration". The idea is that if you follow the conventions, things work better. If you need to go beyond them, you can still configure things.
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.
For what it's worth, I prefer Datamapper. I don't have especially bad memories of ActiveRecord, though -- but I probably wasn't doing especially complex queries.
But note, again, it's about convention over configuration. Nothing's stopping you from hand-coding raw SQL, or even going entirely around ActiveRecord in the few cases where you actually need that. The other lesson is, of course, that if your queries are your bottleneck, there are probably other tricks you could be doing, like memcached.
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.... It was cheaper just to buy more hardware.
That's part of the point of Rails, though. It usually is cheaper to buy more hardware than to optimize, Ruby just forces you to face that up front.
Sure, sometimes you can change your algorithm from O(n^2) to O(logn) and get a massive speedup, and it's worth it when you can do that. But an extra 5-10% likely isn't worth it until you're of sufficient size that 5-10% of your hardware is costing more than hiring an extra person to do those optimizations.
Don't thank God, thank a doctor!
That wouldn't be the only time that Rails has been sloppy in choosing the right HTTP method to use. When they implemented REST, they got PUT and POST backwards. Compare with CouchDB, which gets it right: PUT to create and POST to update a record.
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.
We tried JRuby.
We had various deployment problems, i'm sure that many people have managed to make it work, but we got about 2 days of trying to port in a medium-sized, high concurrent project, and we finally came to the conclusion that it's better to stay closer to the mainline c-based Ruby than diverge our project to JRuby and deal with the dangers of working on the bastard-project (when we talked to some of the guys at sun, back when we made the choice to give JRuby a try, there was only 3-4 paid employees working on it... it just felt too edgy for us, and we were looking to stabalize our project, not go down a lonely road of untested/unknown.... )
As they say, sometimes it's better the demon you know , than the ones you don't.
Disclaimer:
1. We have had a LOT more success with rails, than failure. And we're getting a LOT more done now than before when doing struts/JSP/JDBC style dev.
2. My lead developer wrote a book on Rails development for Oreilly, (rails handbook), he is leading our charge into Grails even having a substantial background in Ruby/Rails.
I'd never say I regret doing our projects in Ruby, nor do I feel like JRuby would of solved my problems. I'm happy with Grails, and it has well complimented our teams capabilities and experience. We write code to solve problems and generate revenue, we don't have the luxory of coding at a well funded public company, we pay our mortgages and car payments from code we write every week. Ruby has met the challenge for us, but it's silly not to explore our options to try and make our new projects even more robust and improve our development, and our current dilemma of ongoing maintenance.
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.
Thus they have made no allowance for dropping back to raw SQL queries.
Ignoring your inaccurate remarks about the core Rails developers, do you care to expand on the above mentioned claim?
count_by_sql: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M002276
find_by_sql: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M002267
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.
A case in point: Rails likes to give your database tables plural names...One of the reasons to prefer singular table names is that it improves Rails's interoperability with the applications that either want to supply data to or consume data created by Rails..
Another reason is that it gets you closer to relational thinking. Plural names come about because some think of tables as collections of records and it follows that said collection should get a plural name. So, your "person" record becomes your "people" table.
However, the table isn't really and formally a collection of rows. What you really have is a set of "person" relations; the plural on the end of relations there is where the plural belongs.
And I don't know how big of a performance hit pluralize yields, but it's doing something that doesn't have to be done: the convention could just as well be singular (and arguably would more properly be singular).
Tweet, tweet.
In fact this is supposed to be a central idea behind comments in Ruby. It is usually much more important to indicate WHY your are doing something than HOW. Ideally, the how should be self-evident.
Funny, I first read about ROR on Slashdot 3 years ago, back around the 1.0 release. The only negative things anyone said back then were quips about DHH's Danish accent. Now it's matured into the finest open source development web development stack available, powering many successful web apps and all I see here are the people who should be supporting it on principles alone talking smack about it.
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!
Just another example of someone putting down Rails for reasons that they only imagine because they have no idea what they are talking about.
.000300020001. The result is "Python".
Hey, I can make stuff up out of the air too!
(1) PHP still has a serious floating-point bug. Try multiplying 3.000001 and any number ending in
(2) Oracle is going to roll back the last 47 bug-fix commits to the Java repository, but only for the OSS version. Then it will sell the up-do-date version commercially.
(3) Microsoft has announced that it is just too much work to make all those separate compilers that turn its Visual Studio languages into intermediate Common Language Runtime code. It will henceforth be marketing C++, C#, J#, F#, and FU With A # Object, all as separate languages with their own compilers and IDEs. It will be selling the rights to its Visual Basic language to Delphi, who say they will turn it into what it was always supposed to be.
Give me a few minutes; I am sure I can imagine some more.
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.
Yes, Django does have testing support, and Django itself is quite well tested - so I agree with you. The point I was trying to make is just that testing wasn't really a priority amoungst developers in the way it is in the Rails world. Things may have changed now.
As for talking about professionalism, it's more just a case of being fustrated by developers not testing their code - and it happens in all languages (and I do it sometimes too). It's just less common a problem in Ruby/Rails in my experience.
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'!"
Mod parent tragically informative.
In fact, the Rails team always promoted the fact that you can drop down to pure SQL when necessary as a feature of ActiveRecord. It is like there is some kind of distortion field between Rails developers and the rest of the world.
What was said: We developed this handy framework to make web development more enjoyable for developers. We hope you enjoy it.
What was heard: We developed this handy framework to allow everyone and their brother to build a web application. Fire those expensive programmers! They aren't needed anymore.
What was said: We created a database abstraction library that simplifies common database operations. You can still drop down to the database level for the more complex operations, if necessary.
What was heard: We created a database library that makes accessing a database easy enough that your grandma can do it. If you have to do anything more complex than select a few rows from a table, forget about it. P.S. And don't even think about adding a second web server to the mix as your app grows, it just ain't gonna work.