Ruby On Rails 1.2 Released

Scooter[AMMO] writes "David Heinemeier Hansson sent a post to the Rails 1.2. This new version adds a slew of buff and polish to the rest of the system, as well several new features like RESTful interfaces, response formats, improved multi-byte support, and more. If you haven't checked out the web application framework that aims to renew joy within its users, give it a look. You may be amazed at how easy it makes things without sacrificing power or functionality."

Comments

Improved multi-byte support?

[VGPowerlord]

I would think that improved multi-byte support would need to be in Ruby, not in Rails.

Re:Improved multi-byte support?

[jrumney]

If you'd RTFA instead of rushing to get first post, you would have seen this:

So since Ruby won't be multibyte-aware until this time next year, Rails 1.2 introduces ActiveSupport::Multibyte for working with Unicode strings. Call the chars method on your string to start working with characters instead of bytes.

Re:Improved multi-byte support?

[VGPowerlord]

I did read the article. The problem is, the Rails team has created a module that, by their own admission, will be obsolete within a year.

This alone is a bad engineering practice, but there's also the possibility that the two multibyte systems are incompatible. What if one uses UTF-8 and the other UCS-2? Or UTF-32? All of those are multi-byte. All of them are Unicode. None of them use the same encoding.

Since Rails is commonly used with a database backend, any incompatibilies will cause major upgrade headaches in the future.

This is the sort of thing that gives developers a bad name.

Re:Improved multi-byte support?

[dwerg]

Thanks for the vote of confidence. You might be surprised to know that we thought about all this before we started working on AR:Multibyte.

AR:Multibyte is currently mostly used internally in Rails to make methods multibyte safe. It will be really easy to phase it out when internal support arrives.

Ruby is getting more multibyte support 'in a year', which means that it's at least going to take a few years for everyone to actually get the new version in their OS.

Re:Improved multi-byte support?

[d00ber]

I'm especially surprised because the creator is Japanese and Ruby apparently has a big following there.

I would have thought that multi-byte languages would have been a big deal from the start.

Re:Improved multi-byte support?

[tcopeland]

> I would have thought that multi-byte languages
> would have been a big deal from the start.

Yup, they are. Ruby supports UTF-8, JIS, and various other multi-byte encodings. It just doesn't have support for all the Unicode encodings.

Keep in mind that other languages have to change as Unicode changes as well. For example, Java's char primitive is 16 bits, which for a while was enough to store all the Unicode characters. But with Unicode 3.1, supplementary characters can be 21 bits. That's why Java 1.5 introduced a bunch of new Character methods that accept an int, not a char.

Re:Improved multi-byte support?

[thrillseeker]

The problem is, the Rails team has created a module that, by their own admission, will be obsolete within a year.

Let me guess - you're one of those that would have waited for jet powered air travel to be invented instead of taking the luxurious ocean liner?

Developers need to choose the tools they feel will best help them get the job done in the time allotted and in their estimation will also allow them an upgrade path at an acceptable level of pain as things (inevitably) change.

Re:Improved multi-byte support?

[aldheorte]

If I remember correctly, there is a cultural issue here in that Unicode is apparently considered with some disdain in Japan and local multi-byte encodings are used, one of which Ruby supports. If you do some searches, you can probably find the full background story.

Re:Improved multi-byte support?

[iluvcapra]

There was a good AC post about it in the "Ruby as a Lisp" posting a few days ago:

It basically has to do with the fact that Unicode uses Han Unification to cause Chinese and Japanese ideograms to share codepoints, and Japanese aren't down with that, so they use Shift-JIS. Check the postings that reply to it for a big digression on the issue ;)

Re:Improved multi-byte support?

[iluvcapra]

http://it.slashdot.org/comments.pl?sid=216794&cid= 17605432

Damn autolinky didn't work!

Re:Improved multi-byte support?

[VGPowerlord]

Let me guess - you're one of those that would have waited for jet powered air travel to be invented instead of taking the luxurious ocean liner?

That analogy falls flat on its face, because:
1. Ocean liner travel and jet travel came out over a century apart. I'll be dead in a century, but probably not in a year.
2. Jets are considerably faster than ocean liners, taking hours instead of days. As far as we know, Ruby's multi-byte support will be faster than ActiveSupport::Multibyte, but we have no idea on the order of magnitude that it's faster.
3. The world didn't know about jets when ocean liners were introduced. On the other hand, we know Ruby is gaining multi-byte support in the next major release.
4. There are other benefits for taking a luxurious ocean liner, particularly if it's a cruise ship. What's the advantage to using ActiveSupport::Multibyte? Release date. That's it.

Developers need to choose the tools they feel will best help them get the job done in the time allotted and in their estimation will also allow them an upgrade path at an acceptable level of pain as things (inevitably) change.

Yes, and I'm free to point out in a public forum that the method presented will be obsolete within a year. The difference is that mine is (afaik) a fact, not an opinion.

Re:Improved multi-byte support?

[Schraegstrichpunkt]

What if one uses UTF-8 and the other UCS-2? Or UTF-32?

Using UCS-2 would be a bug, since it can't encode all Unicode characters, and UTF-32 (more properly, UCS-4) would probably be unnecessarily wasteful. Furthermore, any code that supports Unicode is going to have to support UTF-8 at some point, not least because UTF-8 has become the way of encoding Unicode on Unix, as well as on the Internet.

Re:Improved multi-byte support?

[Schraegstrichpunkt]

Well, I appreciate the multi-byte support. I think I might actually start using Rails, now.

Re:Improved multi-byte support?

[VGPowerlord]

I actually mentioned UCS-2 because Microsoft has historically used it, although it has been superceded (and replaced in newer Windows versions) by UTF-16. Side note: Java also uses UTF-16 internally.

Re:Improved multi-byte support?

[angst_ridden_hipster]

Actually, it's probably Good Engineering.

Ruby (the language) doesn't support Unicode yet.

Rails needs it. So they write a module to support Unicode. Yes, in a year, that module will be obsolete. But then, presumably, the module will then become a pass-through to the native Ruby support.

No code will need to be changed.

That's encapsulation. That's Good Engineering[tm].

Or I could be confused and totally missing the point :)

Re:Improved multi-byte support?

[Anonymous Coward]

Yup, they are. Ruby supports UTF-8, JIS, and various other multi-byte encodings. It just doesn't have support for all the Unicode encodings.

If it doesn't support UTF-EBCDIC and UTF-9, it's no good to me.

Re:Improved multi-byte support?

[tcopeland]

> If it doesn't support UTF-EBCDIC and UTF-9, it's no good to me

Yeah, and what about UTF16LE? C'mon!!

Re:Improved multi-byte support?

[VGPowerlord]

Changing it to be a passthrough only works if ActiveSupport::Multibyte and the Ruby implementation are identical. dwerg has implied that they are, but since he's not part of the Rails Core Team, I have to take what he said with a grain of salt.

Encapsulation is good, yes. However, all classes should be encapsulated, so that when their internals change, their external interfaces do not.

OK, the problem presented here is what happens with ActiveSupport::Multibyte when Ruby 2.0 comes out. Since you can't force everyone to upgrade Ruby when it comes out, you have to do one of the following:
1. Support two versions of ActiveSupport::Multibyte
2. Write additional code to determine if multi-byte support is present in Ruby
3. Not use Ruby's multi-byte support in ActiveSupport::Multibyte at all

That's why it's a Bad Engineering(tm) decision. Even if the final decision is #2, ActiveSupport::Multibyte then becomes an Unnecessary Layer of Abstraction(tm)/Indirection(tm) of Ruby's multi-byte support on systems that support it, serving no purpose than to slow nice, compiled language calls with calls to Ruby code.

Pandora, you can open that box if you want, but I'm not touching it.

Re:Improved multi-byte support?

[kisielk]

As someone who works at a software company in Japan, I've never seen any resistance to Unicode here or from any of our partners. In fact we use it all the time.

Re:Improved multi-byte support?

[jrumney]

What if one uses UTF-8 and the other UCS-2? Or UTF-32? All of those are multi-byte.

No, they're not. UCS-2 and UTF-32 are fixed width encodings, not multi-byte. And if UTF-8 is not eventually supported natively by Ruby, then the Rails implementation will still be needed. The rest of the internet is not going to drop UTF-8 just because Ruby does not support it.

Re:Improved multi-byte support?

[VGPowerlord]

No, they're not. UCS-2 and UTF-32 are fixed width encodings, not multi-byte.

UCS-2 was a bad example, as it has been phased out in favor of UTF-16.

The technical introduction to Unicode states "The Unicode Standard defines three encoding forms that allow the same data to be transmitted in a byte, word or double word oriented format (i.e. in 8, 16 or 32-bits per code unit)."

You'll notice that only the first is listed as byte? That's because a word as they have defined it is two bytes long. Two bytes is, of course, more than one byte, thus the term "multi-byte." The UTF-8, UTF-16, UTF-32 & BOM FAQ has a nice table with the minimum and maximum bytes/character that each encoding takes.

(For reference, the Unicode standard refers to the full size of a character as a "code unit" or "code value," rather than a byte.)

And if UTF-8 is not eventually supported natively by Ruby, then the Rails implementation will still be needed. The rest of the internet is not going to drop UTF-8 just because Ruby does not support it.

This slide, from a presentation given by the Ruby's author, Yukihiro "Matz" Matsumoto, indicates upcoming support for UTF-8.

Renew joy?

[Dr. Photo]

I code web apps in rails for work. I come home and play in Django. There is my renewed joy...

Re:Renew joy?

[dthable]

Is it the python language that brings you joy or the framework? I've been looking into all these frameworks for a corporate research assignment and there are many things rooted in the languages that are making bigger differences and each language has it's problems.

In all honesty, what framework you use doesn't matter. YouTube was developed in python, facebook in php, /. in perl, myspace in .net, on so on... If you can bend the framework, you can make wonderful websites.

I, personally, will be lined up in the python camp. It's just my preference.

Re:Renew joy?

[jallen02]

MySpace is developed in ColdFusion. NewAtlanta communications developes software that MySpace uses, which allows it to run ColdFusion ontop of a .NET CLR.

Re:Renew joy?

[Anonymous Coward]

I thought MySpace used Cold Fusion ? I see .cfm in most of their links.

Re:Renew joy?

[dthable]

http://www.baselinemag.com/article2/0,1540,2082921 ,00.asp

According to the article, it started in Perl, then to ColdFusion and now it's using the .Net stack. I guess they pushed the limits of each platform to the breaking point. To me, it sounds like Tom needs to spend more time thinking about his code instead of worrying about being everyone's friend.

Re:Renew joy?

[jallen02]

That is interesting. The article implies they still have some code running in CF using BD.NET (BlueDragon .NET). I wonder how much of it is C# vs. CF at this point.

Re:Renew joy?

[Dr. Photo]

Is it the python language that brings you joy or the framework?

Both. Imagine a Venn diagram of (Joyful for Hackers ( ) Smart for Business). Python and Django (IMO) both hit that sweet spot, the rare, tiny sliver where both circles intersect.

If it were just Python by itself, then I'd be using either TG or pylons, but both of those are attempting to be rails (in pylons' case, rails on steroids), which, after becoming much too familiar with rails, is not what I want.

A lot of the things we've been doing in rails made me realize that django would be a much better fit, and is a much better-designed system.

Note that I feel that Django's simple templating system is itself an advantage, as I've had to (a) remove logic from too many views ("templates" in django parlance), and integrate too many html/css designs from our web designers into too many web apps. The django template system (and the fact that it can live elsewhere from the main app) is designed to achieve clear separation of concerns in both these areas.

No Mongrel

[Gunark]

It's too bad Rails 1.2 wasn't released with mongrel (a very nice app server designed to run Rails apps, among other things). Currently deploying a production-ready server capable of running Rails is a uncomfortably unrails-like experience. Mongrel makes things a bit nicer, but even with that running under virtual hosts and/or with SSL requires some seriously heavy lifting (think Mongrel running behind Apache acting as a reverse proxy).

Until we get a quick and easy way of deploying Rails apps -- especially at the shared hosting level for ISPs (along the lines of PHP hosting, which is now standard), Rails will continue to have a difficult time finding a niche. The only place where Rails really belongs right now, and the only place where I'm using it (and loving it) is the corporate intranet, where putting up dedicated mongrel servers for internal web-based apps is not an issue.

Re:No Mongrel

[dam.capsule.org]

Maybe you can have a look at JRuby: http://jruby.codehaus.org/.

They aim for 100% Rails compatibility (I think they are nearly there) and there are developments to allow deployment of your rails application using Java's war web archive system to a Java application server.

Re:No Mongrel

[dwerg]

Mongrel works fine with Rails. Just gem install mongrel and ./script/server will automatically use it.

Capistrano is a great project to make deployment easy.

Re:No Mongrel

[tcopeland]

> It's too bad Rails 1.2 wasn't released with mongrel

Well... maybe. I agree, Mongrel rocks, we use it for indi and it's quite solid.

But does Rails really need to depend on it? I think the current solution - using Webrick for development and then deploying to a full-up Apache+mod_proxy_balancer_Mongrel - works pretty well.

Re:No Mongrel

[lewp]

That's the way I feel about it as well. We use Mongrel for our intranet and it rocks, but I don't need it at all to code on my laptop. I'm glad that Rails doesn't require me to install it, and equally glad that it's basically drop-in when I do want to use it.

OT: I've been looking forward to 1.2 for a while now. I'm glad they got it out the door. Rails and Ruby really do make a lot of tasks much more enjoyable.

Re:No Mongrel

[typhoon007]

Check out Capistrano (Formerly switchtower) It's a very nice automatic deployment script built in Ruby... Pulls from SVN, multiple uploads, rollbacks, etc. Takes a bit of getting used to, but once the script is setup, it works great.

Re:No Mongrel

[I Like Pudding]

I saw 75% given as a number by the head dev maybe a week ago. Not quite ready for prime time.

Rails 1.2 & Engines

[What the Frag]

For all guys currently using engines, you might want a look at this:

http://rails-engines.org/news/2007/01/03/engines-a re-dead-long-live-engines/

I never quite understood the benefit of Rails

[mwvdlee]

And after looking at some presentations on their site, I still don't.

All it seems to do is offer a way to do very similar and simplistic web apps without any real-world functionality. I also wonder about the performance and memory profile; seems that the way it handles databases is exactly what DBA's hate to see. Sure, I understand Rails offers you the ability to create websites at high speed, but none of the websites it can create is worthwhile.

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

I slightly remember that amazon/a9 rails application showing the bulk 500 internal server error page.

Re:I never quite understood the benefit of Rails

[tcopeland]

> All it seems to do is offer a way to do very similar
> and simplistic web apps without any real-world functionality.

You may want to look closer; it offers ways to do very complex web apps with lots of real-world functionality.

> I also wonder about the performance and memory profile; seems
> that the way it handles databases is exactly what DBA's hate to see.

In practice, ActiveRecord works out very well.

> none of the websites it can create is worthwhile.

To the contrary, the websites a programmer can create with Rails are very worthwhile.

Re:I never quite understood the benefit of Rails

[BlackPignouf]

I really didn't understand either before I decided to invest some time and try tutorials.
It's already been 15 years I've been programming (Logo :), Basic, C++, Fortran, Caml, Java, Ruby ...) and I now have the impression that I never really understood programming before having known rails.
So please, try it at least 2 hours, and you'll be amazed by how fun, efficient and beautiful it is.

Everytime I heard someone talking about REST, migrations, rake, capistrano, scaffolding, ActiveRecord, AJAX, routes & nice URL's, I just thought "Whatever! Those are just buzz/hype words without any meaning, and it won't change my programming life".
But it sure did, and I think noone can ever understand it before giving it a fair chance.

Thanks a lot DHH and keep up the good work!

PS: You might want to check http://backpackit.com/ if you look for a "real-world functionality".

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

Like any other systems, performance can be good or bad depending on knowledgeable and careful is the person building it. Rails apps will take a lot of memory. Yes, DBA's will hate a lot of things that people do with Rails. Same with most every other framework that actually saves or simplifies any developer time. Fortunately they are probably already comatose from the fact that the app uses MySQL.

Maybe none of the web apps that you can think of creating are worthwhile, but there are plenty of very large, innovative applications out there written using the Rails framework. It's a framework, and makes advances by adopting conventions. You will always be able to look at Rails and complain that it is "too restrictive" or that "there's only one way to do x". That doesn't mean it's not a very useful tool in its own realm. Think of it as a sort of domain-specific language. It's domain is web applications, and it rocks at them.

Re:I never quite understood the benefit of Rails

[tcopeland]

> To the contrary, the websites a programmer
> can create with Rails are very worthwhile.

I should add - it's working very well for us (getindi!), and there's a lot more to our site than the glittery front end.

Re:I never quite understood the benefit of Rails

[partenon]

And after looking at some presentations on their site, I still don't. Some time ago, I was presented to Rails by a friend. I was skeptical at first, but after watching the video, I realize it is a powerful tool. Then, Rails was /.ed by the first time. And the second. And so on. And people still think Rails is only for "database input/output without customization". Can't they see the power behind it?? Something that was so clear to me at very first sight can't be that difficult for others to see. My only explanation to it is that people is afraid of change. And no technology can change that.

While it is very simple to build applications via scaffold (automatic screens base on database schema), it is only *one* feature in Rails. Try it for a week. *Then* you'll see the real power of Rails. Sustainable development speed*, a very nice language (Ruby), nice documentation (it could be better, but it is ok) and so on.

seems that the way it handles databases is exactly what DBA's hate to see DBA's may hate the way Rails uses databases. The framework isn't focused on "computer ease of computing", but on "developer ease of developing". So, it may not fit for a huge company, w/ hundreds of offshore developers, SA's and DBA's. It is specially useful for small companies/teams, where speed of innovation is their key to get into the market. Example: to start building Rails applications, one just needs to download the ruby interpreter (port install ruby), rubygems (port install rb-rubygems), install rails (gem install rails), and start the application (rails MyApplication). Try that :-)

I also wonder about the performance and memory profile Its footprint on memory isn't any bigger than a similar application developed in Java. Have you ever looked how much memory the app itself + application server uses? And as for performance, it is ok. This is an old discussion, and rails folks usually says it is better to develop an app in 2 months than 12. And the money for the other 10 months can be used to buy more servers, if needed (but I can tell you that you can handle 4GB of transfer/day in a serverpronto.com entry level machine... warning: it is not a benchmark, just an idea).

All it seems to do is offer a way to do very similar and simplistic web apps without any real-world functionality. I really hope you aren't serious or you just don't want to open your eyes... Should I send you some examples of sites built using Rails?

So, instead of seeing the presentations, try to put your hands on it w/ rose-colored glasses** . If you don't like it, at least you'll learn new way to do things, which can help you in your next project ;-)

* try to keep a sustainable development speed w/ one of the standards in the market: struts/spring + hibernate. It is almost impossible to achieve.
** sorry, I'm not a native english speaker... I hope it was used in the right context :-)

Re:I never quite understood the benefit of Rails

[VGPowerlord]

DBA's may hate the way Rails uses databases. The framework isn't focused on "computer ease of computing", but on "developer ease of developing". So, it may not fit for a huge company, w/ hundreds of offshore developers, SA's and DBA's. It is specially useful for small companies/teams, where speed of innovation is their key to get into the market. Example: to start building Rails applications, one just needs to download the ruby interpreter (port install ruby), rubygems (port install rb-rubygems), install rails (gem install rails), and start the application (rails MyApplication). Try that :-)

The last time I used Rails (0.9ish), it wouldn't let you connect to more than one database per application. This is unacceptable in my environment, so I had to throw it out as a prospective tool.

Rails (or rather ActiveRecord) has all the same problems that all ORMs do. The first of which is optimizing for ease of development, not memory footprint. Even medium size applications can suffer from this.

A second problem is the "more information than I asked for" problem. SELECT * should be used sparingly in favor of just grabbing the information that you need. ORMs have no idea of what information you want, so they just grab everything. The more information in your table (i.e. large text fields), the bigger problem that is.

There are other problems as well, but it's 7am here and I need desperately need my morning caffeine fix.

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

Not just Rails, Ruby is already a poor performer for real world apps. The benefit of Rails is that bloggers who only ever dabbled in javascript or PHP can hype it, them limiting their crappy code to Ruby benefits us all.

Re:I never quite understood the benefit of Rails

[CowboyBob500]

Absolutely. Any website built on-top of a language that can't handle UTF-8 natively is destined for trouble somewhere down the line. OK, to they've mamanged to hack in support into the web framework. That's the beginning of a huge WTF right there. When the language gets the capability natively you're going to get a real mix and match and a whole world of pain. No thank you...

Bob

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

> it's working very well for us

"working"? That Word, it does not mean what you think it means.

If the benefit of Rails is that hyperlinks don't work without javascript, the world is better off without it.

Re:I never quite understood the benefit of Rails

[Stalyn]

Sure, I understand Rails offers you the ability to create websites at high speed, but none of the websites it can create is worthwhile.

Well penny-arcade.com and alistapart.com both run on Rails. Those are two sites I deem worthwhile. Then wtf do I know.

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

Hi,

First of all, thank you for your long and enthusiastic answer; I apologize in advance for the criticism I'm going to lay against it.

I think you are making a fundamental mistake in your approach: you express your interest in RoR as something that improves over known-bad technologies, or at least, not-as-good-as-previously-thought (Java is often brought up in comments such as yours, for whatever reason *cough*), while entirely disregarding the whole ecosystem of modern Web development frameworks that exists beside RoR.

I think this is what the general sentiment of the comments thus far are trying to express.

It's not that RoR is not a good tool. It is. Simply, there are tools out there that are better than it on almost all counts: faster development, more maintainable code, more extensive set of third party libraries, faster serving of pages, better i18n and actual Unicode support, better support of varied pre-existing environments (less 'opinionatedness', if you will), better scalability in terms of page views and in terms of application complexity.

This being said, I don't think RoR deserves all the bad press it's getting on technical sites. I think this is mostly the reaction of very technically-oriented people lashing out at a project that seemingly attempts to gain first place status through hype rather than technological superiority. But I want to say, at least, RoR was succesful in attracting more public attention on modern Web development frameworks as a whole, and for this, we should all be grateful.

Re:I never quite understood the benefit of Rails

[Paulrothrock]

No worthwhile RoR web apps? Check out BackPack, BaseCamp, or TaDa List. Finally, RoR can do anything that PHP can do from blog engines to a photo gallery to web stores. So to say that Ruby on Rails can't create any worthwhile websites shows a lack of knowledge of the abilities that Ruby on Rails has.

Re:I never quite understood the benefit of Rails

[MilwaukeeCharlie]

So, instead of seeing the presentations, try to put your hands on it w/ rose-colored glasses** . If you don't like it, at least you'll learn new way to do things, which can help you in your next project ;-)

** sorry, I'm not a native english speaker... I hope it was used in the right context :-)

You have a great command of the language, but since you offered that caveat, I thought I'd try to clarify this metaphor for you.

The phrase "looking through rose-colored glasses" is usually used perjoratively, and directed at an optimist by a realist. Nobody encourages others to look at something through rose-colored glasses, nor would someone with an idealistic outlook on something admit to doing so. If I understand what you were trying to say, a better phrase in the context above would have been, "keep an open mind."

Re:I never quite understood the benefit of Rails

[arevos]

You have a great command of the language, but since you offered that caveat, I thought I'd try to clarify this metaphor for you.

The phrase "looking through rose-colored glasses" is usually used perjoratively, and directed at an optimist by a realist. I suspect that the majority of native English speakers wouldn't know what the word "perjoratively" means, and since you have an extra "r" in there, looking up a definition for the word might be difficult (the correct spelling is "pejoratively").

Re:I never quite understood the benefit of Rails

[Marcus K]

Hyperlinsk works exactly as hyperlinks usually work when developing in Rails. You don't have to use JavaScript at all.

Re:I never quite understood the benefit of Rails

[MilwaukeeCharlie]

I suspect that the majority of native English speakers wouldn't know...

Perhaps, but I expect more from slashdot readers.

(the correct spelling is "pejoratively").

Thanks, I stand corrected.

Re:I never quite understood the benefit of Rails

[jadavis]

DBA's may hate the way Rails uses databases.

This is true, but it's understandable also. Rails uses databases as persistent object storage, and nothing more.

The benefits of relational databases are that they can enforce constraints with simple declarations, and abstract the logical from the physical storage. You can try to do some basic checking before you put something into a database, but it's very hard to do constraints on the application side.

I understand why developers at smaller companies don't like using relational databases as relational databases. For a long time relational databases weren't really meeting the needs of smaller shops, and they have their own learning curve. But now with good databases like PostgreSQL that have proper constraints and can do powerful relational manipulations, it's a great time to get involved in relational databases. I encourage you to try them out, they can be a godsend when it comes to application development speed.

It's a wonderful thing when you get an error from your database, and you know exactly which part of the application tried to do something wrong. The alternative is waiting until the bad data gets in, and finding out a week later when you try to do a report (try to find the bug now that you have no idea how the data got that way).

Re:I never quite understood the benefit of Rails

[telbij]

faster development, more maintainable code

Please cite some examples. A lot of Rails' technical sacrifices are in the name of speed of development and maintainable code. Obviously I haven't used all web frameworks, so I don't know. Maybe you're right. But I'm suspicious you're just pulling that out of your ass.

more extensive set of third party libraries, faster serving of pages, better i18n and actual Unicode support

Yes, Ruby is slow, has fewer libraries, and no unicode support. However these issues don't really speak to Rails itself. Yes, they may showstoppers in some instances, but Ruby was chosen for other reasons which greatly affect the usability and development performance of the framework. Yeah, you could do most of the same in Python or SmallTalk, but certainly not in most popular languages.

better support of varied pre-existing environments (less 'opinionatedness', if you will)

The opinionatedness of Rails is what makes it so powerful. There is plenty of support for dealing with legacy schemas. Of course Rails encourages database constraints in the application code, which is distasteful to some, and definitely precludes the use of outside applications directly writing to the database safely. However, if you have the means to use Rails conventions then you get an awful lot for free, and I don't really see how you can have it both ways (ie. faster to develop, more maintainable, and more flexible) unless of course the Rails architecture is just garbage and it can easily be replaced by a more powerful architecture which is better in all ways.

better scalability in terms of page views and in terms of application complexity.

See Rails is more focused on the complexity side and maintainability side. Sure there's a computational cost there. For one thing you're on Ruby which is fairly slow to begin with, then you provide all the request hooks to keep the application organized, finally you add a basic ORM layer that is great for 95% of queries, but is maybe a bit naive. However if you need to optimize those things, by all means write your own queries and do your fragment caching. At some point, yes, you should be looking at other languages and frameworks.

However, Rails does what it does very well, and what it does is a huge market niche. Anyone using Rails should be aware of its philosophy and shortcomings, but it's not poorly designed from a technical standpoint. Maybe its design goals don't go over well with you (it pretty much pisses all over the idea of database-level data integrity, which is a pretty controversial idea at best), but don't mistake that for poor technology.

Re:I never quite understood the benefit of Rails

[Fweeky]

"The last time I used Rails (0.9ish), it wouldn't let you connect to more than one database per application. This is unacceptable in my environment, so I had to throw it out as a prospective tool."

That's an ActiveRecord thing.. use a different ORM (Og looks quite nice), or no ORM; convention isn't a gun to your head, and it's not really a lot of effort to keep most of the benefits without actually using AR (my last Rails app used descript.ion files, heh). It's also not been true for a long, long time; each model can have it's own seperate connection, a feature added for ActiveRecord 1.0 (it's at 1.15.1 right now; 1.0 is 90% of the way down the changelog, sometime in 2004).

"Rails (or rather ActiveRecord) has all the same problems that all ORMs do. The first of which is optimizing for ease of development, not memory footprint."

Er, right. Can't say I've noticed ActiveRecord's memory footprint being much of a problem; if I'm loading huge result sets, it's generally enough of a problem that I just use a cursor, no matter what library I'm getting them via -- removing the few additional objects AR throws in doesn't really make much of a dent. Besides, developers generally cost more than memory.

"A second problem is the "more information than I asked for" problem. SELECT * should be used sparingly in favor of just grabbing the information that you need. ORMs have no idea of what information you want, so they just grab everything."

Bla.find(:all, :select => "title,body") -- :select was added in 1.12.0, about 14 months ago.

Re:I never quite understood the benefit of Rails

[g1zmo]

try to put your hands on it w/ rose-colored glasses**

** sorry, I'm not a native english speaker... I hope it was used in the right context :-)

Nope. You butchered it, but in an oddly pleasant-sounding way. I give you points for (unintentional) creativity.

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

All applications created by the people who created RoR. I have never met anyone who used those applications; have you?

Re:I never quite understood the benefit of Rails

[marcello_dl]

> A second problem is the "more information than I asked for" problem. SELECT * should be used sparingly in favor of just grabbing the information that you need. ORMs have no idea of what information you want, so they just grab everything. The more information in your table (i.e. large text fields), the bigger problem that is.

You've already been replied to, but don't forget that Rails "find by sql" lets you query the db using plain ol' database dependent (but optimized) and have the selected fields returned in handy AR instances. I guess rails developers start building their app using normal AR facilities, then when they got familiar with the required data structures to solve the problem think about replacing AR queries with SQL without touching much the rest of the code.

Re:I never quite understood the benefit of Rails

[Paulrothrock]

Mephisto and Gullery aren't by people who made RoR. They're the RoR equivalents of Wordpress and Gallery 2.0. And I use Backpack and TadaList a lot. Tadalist is particularly useful for listening to Pandora at work and documenting which songs you liked so you can download them later.

Re:I never quite understood the benefit of Rails

[Nataku564]

Yeah, you could do most of the same in Python or SmallTalk, but certainly not in most popular languages.

Like Perl? I have yet to get a Ruby guy to answer me why Rails shouldn't be ported to a faster, more standard and more prolific language like Perl. From everything I have seen the languages both have the exact same capabilities. Class-DBI instead of AR, etc. Rails seems to have a purpose, but Ruby just seems to be the product of some devs ego and hatred of '->' instead of '.'.

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

> Obviously I haven't used all web frameworks, so I don't know. Maybe you're right. But I'm
> suspicious you're just pulling that out of your ass.

I actually debated linking the specific articles I had in mind when writing that post, then decided not to: see, the thing that really annoys me, at heart, in comments such as the one I initially replied to, is how they quite consistently embed their praise of Rails within a definite disregard (or outright ignorance) of what other frameworks exist. These guys didn't do their homework. In a technological field, that's a capital sin, IMO.

And I was thus not going to point out a specific framework as a comparison to Rails, because even if you trusted my word that something else out there is significantly ahead of Rails -- and you SHOULDN'T trust my word, anyway -- then you still wouldn't know WHY it's ahead and why it matters. There is no such thing as the right tool when you don't know why you're picking it.

And, yes, I do have a specific framework in mind as a point of comparison for all the points I listed in my first comment. By which I mean, benchmarks and articles that compared Rails and that framework, with that framework coming ahead by statistically significant margins where statistics were given. And, no, I'm not going to tell you which one it is. Do your homework. Frankly, you shouldn't need more than half an hour to figure out which one I have in mind based on the points above.

When that's done, download it, install it, and play with it. Figure out what's great with it and what's not so great. And then stick with Rails. It doesn't matter one bit if the tool you use is arguably not the best of its category -- what matters is knowing for yourself where it's lacking, in what cases it matters, and how to make up for it. And you don't acquire that knowledge by assuming by default your tool is the greatest, you know. (And yes, I do apply the last sentence to my choice of tools, which has several implications. Can you figure them out?)

Re:I never quite understood the benefit of Rails

[Keichann]

There's no reason you can't enforce those kind of restraints in your database _and_ use rails, for instance this is from one of the (postgresql) ActiveRecord migrations I'm working on now:

        # Foreign key referencing Target
        execute SQL
ALTER TABLE exclude_sets_targets
    ADD FOREIGN KEY (target_id)
    REFERENCES targets(id)
    ON DELETE CASCADE;
SQL

        # Foreign key referencing ExcludeSet
        execute SQL
ALTER TABLE exclude_sets_targets
    ADD FOREIGN KEY (exclude_set_id)
    REFERENCES exclude_sets(id)
    ON DELETE CASCADE;
SQL

I'm doing the same kind of thing for some triggers - using Rails and database integrity aren't in opposition. The only thing that really gets me about Rails is the lack (in the core) of composite key support, hopefully that'll be eradicated soonish though.

Re:I never quite understood the benefit of Rails

[Raenex]

and there's a lot more to our site than the glittery front end.

Glittery front ends suck.

Re:I never quite understood the benefit of Rails

[Raenex]

And, yes, I do have a specific framework in mind as a point of comparison for all the points I listed in my first comment. [..] And, no, I'm not going to tell you which one it is.

That's such a cowardly way out. No suprise you are posting AC. You made the claims, you back them up. Say what framework you think is better so it can be fairly compared to Rails.

I can play your stupid game too. I know what framework you're thinking of, and the one I'm thinking of is twice as good as that one. Do your homework and figure out which one it is.

Re:I never quite understood the benefit of Rails

[meiao]

Then you should take a look at railsday.
Nice apps there. Written in one day.

Re:I never quite understood the benefit of Rails

[Anonymous Coward]

For the last time, panic.com is not a rails site...

Comparision between Rails and Django

[Anonymous Coward]

http://jesusphreak.infogami.com/blog/why_django

Whew

[tcopeland]

It's getting installed at a furious rate... we're doing around a gem a second now.

Re:Whew

[Anonymous Coward]

Wow, that many people use rails? Are you sure it's not just one guy downloading to /dev/null?

I once set up rails to see what all the fuss was about and can confirm /dev/null is the only place it's going on any of my boxes.

Heaven help!

[Qbertino]

Now that we've just calmed down the Rails bunch they'll be all over us again with foam aroung their mouths. "RAILS! RUBY! RAAAAH!". ...

Here's a list of very good/better alternatives:
Zope - What Rails want's to be when it grows up. Ancient but still ahead of anything else with classic persistance. (www.zope.org)
django - Drinking buddies of the rails people. And they have unicode support. (www.djangoproject.com)
cakephp - YaWebframework. In PHP. Largest community out there. Impressive piece of code (www.cakephp.org). Some De-Normalisation and Relational Trails built in. Very neat.
symfony - PHP 5 Framework. Very good. (www.symfony-project.com)

The biggest suprise for me was reading right here that Rails, as of version 1.2, doesn't have unicode support - and apparently never had. Now that's showstopper imo.

Re:Heaven help!

[gimpimp]

You have to be kidding me? Zope is the Frankenstein's monster of frameworks. Developing TTW? Who was the idiot to come up with THAT? Zope is horrendous!

Django? anything that uses SQLObject is doomed to failure on anything but the most basic of projects. It's about 100 times slower than active record.

Cake php? You have to write php to use it. Game over.

Re:Heaven help!

[Anonymous Coward]

is doomed to failure on anything but the most basic of projects

That sounds like just about every "framework" I've tried. Adding business logic outside of "can't be empty" is pulling teeth, and trying to make conditional choices on data (ie, if X is more than $50000, then we need table entries for forms C-14, B-2007rev1, and S-60, and if the guarantor isn't already registered, we'll need to register one to meet the foreign key constraint for S-60) is like having your entire jaw pulled out. Through your belly button.

Re:Heaven help!

[bockelboy]

Here's a list of very good/better alternatives: Zope - What Rails want's to be when it grows up. Ancient but still ahead of anything else with classic persistance. (www.zope.org)

I program in python day in and day out. That said, Python can be a miserable choice for a large-scale framework. Why? It has a Global Interpreter Lock, meaning the interpreter can run on at most one processor at a time.

So, the nice new multiprocessor server you bought will have similar performance to the one-processor server you replaced it with. The "python way of doing it" is achieving multi-processing in multiple processes, not threads.

Unfortunately, precisely zero of the new-fangled Python web frameworks use multiple processes. You can hack something together, but doesn't that defeat the whole purpose of using a framework? Zope does something like that with ZEO, but Zope has other problems.

The lack of a thread-safe Python interpreter is something you want to watch out for.

Re:Heaven help!

[arodland]

Then you haven't used anything serious. I work with Catalyst during the days, and the thing about it that's so nice is that you're just writing another app -- except that you have a useful library that does a bunch of things for you. Sure, there's a dispatcher, but a Model is just another class, and so is a View. If I want to use three different models, and select between B and C based on some data I got out of A, it's an "if", same as it would be in any other piece of code. If I want to hand off to a PDF-generating view for this particular hit instead of my ordinary HTML-template view, I can do that. If, for some reason, I want to send a response to the client from controller code and forego the entire view stage, it's simple. If I want to have an action that triggers when the portion of the URL before the first slash is the rot13 of the next segment, and the third segment is a prime number... then I'd be a little nuts, but Catalyst wouldn't mind. It's nothing more or less than doing useful things, with less work.

Re:Heaven help!

[arevos]

Here's a list of very good/better alternatives

I'd hesitate to imply that PHP frameworks like CakePHP are better than Ruby on Rails. PHP's syntax is extremely limited compared to Ruby's, and these limitations are visible in any PHP web framework.

Compared to Django, Rails has more functionality directed toward maintaining AJAX sites (such as RJS templates). Ruby also has a few advantages over Python in terms of the flexibility of the language. On the other hand, Ruby lacks Unicode support and is significantly slower than Python.

I haven't really played around with Zope, so I can't comment on that.

Re:Heaven help!

[Lysol]

Yah, Unicode support is a biggie in Ruby. It's there, but still a pain. Rails has added support for it in 1.2 in ActiveSupport::Multibyte. So there's stuff like this now:

'€2.99'.first # => '€'
truncate('2.99', 2) # => '€2'

Even tho this isn't totally like Java's i18n support, it's getting there..

As for Ajax support, yah, it's a first class citizen in Rails. While a lot of people are sick of the term, I think it's for real and here to stay. It is the next step in web applications. While most of the examples in the world so far have been for 'social' .com apps, the fact that Ajax is now allowing (or putting a face on things that already existed but not termed in a way the masses could digest) for rich net apps that regular web pages couldn't deliver. Coupled with the various tool kits like Yahoo UI or GWT, the net and browser really are becoming the operating system. And Rails was the first framework who really made the whole Ajax thing easy to use. They're going to be ahead of everyone else in this category for some time.

Anyway, I'm very excited about 1.2. :)

Re:Heaven help!

[arevos]

I agree with you in general that AJAX is only going to become more common, and done right, AJAX has many benefits. However, stop saying things like this:

the net and browser really are becoming the operating system

Because it's akin to suggesting that we replace the engine of a car with a GPS receiver or an iPod.

Re:Heaven help!

[Fweeky]

Ruby has similar problems; the standard interpreter only supports green threads, so doesn't scale beyond a single CPU. JRuby supports native Java threads, but then Rails isn't thread safe, doh!

YARV has pthreads support, but they seem to be targeting a Big Giant Lock style design to avoid breaking lots of extensions, which is similar to what you get with PHP; the interpreter's thread safe, but use more than the most basic extensions and it all comes tumbling down.

It's not such a big deal for many deployments; you'll tend to be running out of CPU before you start hitting memory limits, but it does suck somewhat if you're trying to host lots of little apps for lots of users on the cheap.

Re:Heaven help!

[poopdeville]

Catalyst FTW.

I used to do a lot of work with Catalyst. I still haven't seen anything as flexible and easy to use. Rails is nice, but it's a bit too "write and drool"[1] for my taste. Oddly enough, it isn't as straight forward as it could be, either.

I highly recommend anyone interested in The Intro. The The Tutorial goes into a lot more depth.

[1] I don't mean to be pretentious. Ruby is a fantastic language for creating domain specific languages, as Rails shows. But Rails' greatest strength is also a major weakness. For the record, my professional work currently involves prototyping number crunching applications with Ruby.

Allow me to be the first to say...

[Palshife]

WHOOPS!

Frameworks are for sissies...

[sonofagunn]

I'm only sort of kidding here - I think frameworks are great for people who don't have strong OO design background and/or don't fully understand the MVC pattern, or for people who work on a team where some people meet these criteria. A framework forces everyone to "stay in bounds." But if you (and everyone on your team) do understand these things, then I'm personally an advocate for just using an OO language (PHP, Java, whatever) and making sure your class design follows the MVC pattern. ActiveRecord (and other stuff like it) are nice to get a prototype page up, but it's not hard to write classes that can update/insert themselves into a database (assuming you use a solid OO design). By the time the pages and objects get more complicated, the amount of control you'll have by doing it yourself will make up for the time lost that an ORM tool saved you in the beginning. Adding complex business logic to the queries, optimizing the queries, and just general maintenance will be easier if you've done it yourself (again, assuming it was done with a solid OO design). I'm not trying to make a blanket statement here, different projects will have different needs. I have decided against using a framework in one project I'm working on right now, and these are some of the main reasons. In other projects, I've been a big advocate for a framework.

Re:Frameworks are for sissies...

[mortonda]

Rails provides so much more than just MVC. It *is* built on solid OO design, and the ActiveRecord framework is pretty solid, and would take a lot of time to recreate by hand. Why reinvent the wheel? The point of rails is to free you from having to do that stuff all over again. "Don't Repeat Yourself" is the motto, and I find that to be the biggest reason to use rails. As I have grown in my own programming abilities, I've discovered the greatest frustration is when I repeat code (or worse, copy and paste).

With the rails framework, you also get(besides MVC and AR): Built in data validation, error reporting from the validation(model) immediately available to the view, session flash (temporary message carried through to next page view), the new RESTful approach (try it!), different responses based on request type, all sorts of view helpers, easy to integrate ajax.... man I just can't list it all.

Django does't use SQLObject

[tabo_peru]

Django doesn't use SQLObject. You can, as a programmer, use it of course, since everything in Django is nicely decoupled, but Django uses it's own ORM. The main advantage of using this ORM is of course the production ready administration interface that you get for free, but if you don't need that, there is nothing stoping you from using SQLObject or even better, SQLAlchemy. In fact, there is even a branch in Django to have SQLAlchemy support in the framework.

Using a different ORM, template engine, etc in Django is just a import statement away.

Unicode

[mortonda]

According to the release notes, Rails 1.2 works with Unicode.

How to update Rails

[Marcus K]

One of the great things with Rails is that it is so easy to update. There's three easy steps: Step 1: gem update rails --include-dependencies Step 2: Press return Step 3: There's no step 3

Re:How to update Rails

[crayz]

And then update your app to freeze to the new version. You are freezing your app, aren't you?

Re:How to update Rails

[Anonymous Coward]

Step 3: There's no step 3

Do we really need to continue rehashing this old commercial until the end of time? We're all well aware that you Rails fans are diehard zealotrous evangelists. We're all really excited for you. Now stop with the happy crap and just get down to business.

On the purpose of a framework.

[Spaceman40]

A framework forces everyone to "stay in bounds."

I've worked on several different webapps, from small and personal to large and corporate, using several different frameworks (J2EE, Django, Rails) as well as just straight PHP/ASP/static HTML. Frameworks don't really force anyone to stay in-bounds.

All of frameworks I've used allow you to drop down to straight SQL for database work, ignore their models and templating (or substitute others), and completely mess up the MVC pattern, if you want. Django goes the farthest towards restricting your options in the latter respect, but it's still possible.

I know you're somewhat kidding, but I just wanted to note that the reason for a framework is above all to have a starting point. Some frameworks do a much better job at that than others, but that's the purpose. If the only purpose was to restrict, they'd be more annoying than not, and people wouldn't use them by choice at all.

Ruby Rails goodness

[MarkWatson]

Thanks to the Rails developers!

Ruby on Rails is certainly a giant step forward in increasing programmer productivity. The new REST support is great, but I must say that the web based SOAP debugging interface made using SOAP with Rails painless.

A little off topic, but for my customer I integrate Rails with back end Common Lisp code - so far just using home grown REST support at both ends. Eventually, I would like to get the time to generate compiled Lisp libraries directly linked to Ruby when everything is runnng on a single server.

BTW, I created a simply Ruby and Ruby Rails news clipping web site, mostly for my own use, but it might be useful for you: http://rubyplanet.net/

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:No Mongrel but Litespeed

[nicksnels]

I have switched from Mongrel (behind Apache) to Litespeed. Mongrel was using too much memory and a mongrel process can only be used for one application. So if you want to set up a cluster of Mongrels for each application, it can quickly eat up a lot of memory. And if you are serious about deploying a Rails application, you should look at a VPS or a dedicated server to do it. For some good Rails hosting companies visit Railshostinginfo.com, which gives you the ability to compare Rails hosting companies.

PHP Rails

[Tablizer]

Just come up with a PHP version of Rails and acceptance and support will improve. Done.