This Blog Has Moved!

My blog has moved. Check out my new blog at realfreemarket.org.



Your Ad Here

Tuesday, August 5, 2008

Ruby on Rails Sucks!

At my slave software engineer job, I'm working on a web development project. Currently, it's written in jsp/Java/Spring/Beans, which is horrible, but at least it runs. Rewriting it in another language probably was a good idea.

My boss decided to rewrite it in Ruby on Rails. Neither my boss nor anyone else here has ever used Rails before. In other words, a critical business decision was made solely based on hype.

I looked around the Internet for information about Ruby on Rails. Most webpages fall into two categories. First, there are rants that say "Rails sucks!" Second, there are rants that say "Rails is awesome!" However, there were no webpages with details about how Rails actually works. This was a bad sign.

Some people say "If you want to know the latest developments in Rails, you have to follow Rails blogs and read the Rails online discussion forums." I have to subscribe to a bunch of blogs and sort through old posts, just to know how the language works? How about some documentation?

If I need information on Perl, C#/ASP.NET, php, or Java, there are plenty of online resources. For Rails, there's practically nothing. If Rails is so awesome, then why isn't there any documentation?

Converting a preexisting application to Rails is not easy. Rails insists that you use a specific naming convention. Your primary key must be auto-increment integer. Table names must be plural (i.e. turds). Join fields must be singular (i.e. turd_id). In that case, the turd_id field will automatically join to the turds table for you. You can override this behavior, but it isn't worth the hassle. They decided to completely redo the database. Some tables were definitely not compatible. For example, Rails won't support a table where the primary key is two columns.

Rails generates a lot of scaffolding for you. That is nice. However, when you have to put in your actual application logic, it's just as much work as any other language. If what you want is exactly covered by the auto-generated templates, then Rails development is very fast. If you need something different, then there's not as much gain.

Rails is interpreted and not compiled. You won't discover your mistyped variable name or function name until you actually run your code. You can compensate for this by automated unit testing, but you can test via script in any language.

You can have polymorphic tables and polymorphic fields. In most circumstances, these features are unnecessary. If a language has a cool feature, then we'd better use it in our application! (This is a management mistake and not a specific defect with Rails.)

Rails encourages you to normalize your data. You can go overboard. It may seem cool to split one table into 5-10 smaller tables. Each extra table is an extra few hours of coding and testing. It's an extra database query every time you load your page.

Instead of making "stock symbol" a varchar(8) like a normal person, my boss split this up into several sub-tables. He normalized out symbol. He made it polymorphic for stocks, options, and futures. He added a provision for foreign-listed stocks and ADRs. He normalized "exchange" out to a separate table. Add this philosophy over the entire application, and you have one big cluster****. (Over-normalizing your data is a management mistake and not a Rails mistake. However, Rails' model encourages such behavior.) It may seem cool to be using a whole bunch of "belongs_to", "has_one", "has_many", and "has_and_belongs_to_many", but after awhile you say "Why are there all these joins?" In order to get any useful information, I have to join 5-10 tables?

We have to totally reorganize our database before importing to Rails. However, we cannot abandon the old system immediately. This means that we have to rewrite the old system for the new database design and then start switching to Rails. Some features of the old system cannot be rewritten in Ruby/Rails, because of Java-specific libraries we're using.

It may seem neat to have ActiveRecord automatically write your queries for you. Actually writing out a few lines of SQL isn't a hardship. Even though ActiveRecord is writing the SQL for you, there's still the overhead for the database calls. Even though ActiveRecord does a bunch of stuff for you, you still have to program in your application logic at some point.

My boss said "We're not wasting money on Microsoft software licenses! We're not feeding the Microsoft monster!" However, because none of us know Rails, they had to hire a Rails consultant (and he's probably getting paid more than me). Even though we saved the cost of Microsoft licenses, there's the wasted time and the cost of the consultant. For a Microsoft solution, I could easily learn it on my own. I can't learn Rails on my own, because it's totally undocumented.

I feel dirty recommending Microsoft over an open source solution, but Rails is horrible. At least with Microsoft, you get something that's well documented and stable. A Microsoft license costs money, but wasting time also costs money. There are other open source possibilities, such as php, which also seem better than Rails.

They needed something done quickly, so I got permission to do it in php instead of Rails. It felt weird looking up the php tutorial and API, and getting a useful answer. Writing out your SQL queries and reading the fields out of the result set isn't the huge burden that Rails makes you imagine. Compare that php tutorial to anything available for Rails. The php tutorial is complete, and the Rails tutorials are sorely lacking details.

My boss said "Rails is a rapidly evolving platform! Isn't that exciting?" If I'm investing in a business, I'd prefer to use a stable platform with slightly fewer features. My employer doesn't need something super wicked cool. My employer needs something that runs. You read from the database, manipulate the data, display it on the page, get input from the user, and write back to the database. It's not rocket science. It's a boring data manipulation job.

Having Rails on your resume is a cool item. If I could honestly write "2 years Rails experience", then I'd have many job offers. However, two years from now, something else will be trendy. At that time, employers will be demanding "4 years Rails experience" or something else. Besides, do I really want to work for someone dumb enough to write their application in Rails?

At this point, my boss is emotionally attached to the decision to use Rails. They can't say "Whoops! Maybe that was a mistake!" Maintaining the fantasy requires ignoring feedback, which further increases the likelihood of disaster. There were two big mistakes. Using Rails was a mistake. Choosing a stupid database design and rollout strategy compounded the error.

I'm also getting better at reading body language. At this point, my boss' body language is screaming "I'm in over my head and this is going to be a disaster!" I can judge the doomed nature of the project just from my boss' attitude. For example, another developer complained that the database was over-normalized, and was ignored.

My boss actually seemed reasonable before. I wonder if being in a position of abusable power has a lobotomizing effect?

I've been involved with enough disasters to recognize the stench of failure. I just work there, so why should I care? On the other hand, I'm usually the guy who gets scapegoated for the disaster. Maybe Rails will work, but it looks like a disaster in progress.

71 comments:

Anonymous said...

Rails is like Agorism. Big on hype, short on documentation. Just kidding. Well, kinda.

I toyed around with RoR two years ago. I ended up sticking with PHP. People who think they can jump feet first into RoR without knowing Ruby are asking for trouble. Especially on a project like this, where the existing system is already in production.

Ineffabelle said...

PHP is nice, fairly simple and works for almost anything you need to do.
It's been around long enough to have lots of libraries, but accessing them isn't a pain in the ass like it is with Java.
The only major criticism I have of it is that it doesn't handle XML all that well, though I've heard they've improved that lately.

"Rails is like Agorism. Big on hype, short on documentation. Just kidding. Well, kinda."
Well, Agorism is kind of in the "early days of C" stage right now. People are mostly making it up from scratch. The idea is fairly simple:
Try to avoid involving the government in your life as much as possible. If you can do something on the grey or black market, and get away with it, do so.

Anonymous said...

Amen Amen

All good advice on this one. Why mess around with an unstable and unfamiliar platform? Well you can give us an update later if you guys stay with Ruby and let us know if, after getting familiar with it, you still think it a bad idea....

barry

Anonymous said...

One word, grails. You can reuse your java code. Scaffolding is for suckers.

Anonymous said...

A little googleing wouldn’t be bad.

Meet http://www.rails-doc.org/.

If you are a newbie to Rails, what about buying a book and reading it?

Rails Way is a very nice book: http://www.amazon.com/Rails-Way-Addison-Wesley-Professional-Ruby/dp/0321445619/ref=pd_bbs_sr_3?ie=UTF8&s=books&qid=1218678758&sr=8-3

And the PragProg have a lot of good Rails books too (with PDF versions for sale too): http://www.pragprog.com/search?q=rails

All problems that you invented in this article are almos ‘automagicaly’ resolved with TDD (Test Driven Development) or BDD (Behaviour Driven Development), the right way to write serious software. And some of the problems are very related to your strict-Java culture. Try learning a few different languages (such as Ruby, Python, Erlang, Haskell, Smalltalk, Objective-C) so you can think out of the box.

Trevor said...

Could not agree more. I've spent 2 years evaluating rails for production and I've come to a conclusion that It's complete garbage for all the reasons listed in this blog post and then some.

jmonteiro's book suggestion is already obsolete and any other book released prior to today is obsolete as well unless you use an old version of rails... the only book covering the new rails is in Beta 3. What now? what would that mean for anyone building entrprise applications, or existing applications?

Anonymous said...

I started a Ruby on Rails project a few years ago during the pinnacle of its hype. Every time I tried to look for documentation, I kept finding blogs that breathlessly posted scaffold tutorials but nothing else helpful to me. When I realized Ruby on Rails was as much work as any other framework when you step outside the auto-generated CRUD interface (which I didn't need or want) but without the years of documentation and support you find from other languages, I moved on. It felt like the community was made up of Mac users getting off on cute Ruby-isms.

Zibbo said...

PHP/Apache will beat the heck out of Rails in performance, any day. 5 times over. Rails is a fricking dog, and speaking of dogs, people seriously think 'Mongrel' is going to outclass Apache?

Ruby is a great language, but the ah.. 'community'...

"It felt like the community was made up of Mac users getting off on cute Ruby-isms."

That's awesome. It's truly the same sort of person, for the most part.

I agree, I tried to learn Rails and it really didn't go so well. The documentation is there, but is of the breathless 'try this amazing gadget, it solves everything! we're so cool!' variety for the most part.

PHP development seems way more direct, and if you want an ORM you can just use Doctrine or Propel. Rails is just what it is... a system that worked great for the guy that wrote it, and it obtuse and unclear for me.

Anonymous said...

Been comparing Django and Rails trying to decide. Rails really does feel better overall but I picked Django because Python is faster and has a more mature community. I love the admin system and all of the additional 3rd party modules that can be easily plugged into your Django project: http://djangoplugables.com/. Rails is not very modular. Python has been in use long before Django. Ruby was nothing before Rails. I get the sense the Rails community is a lot of script kids. However, Ruby performance is supposed to be vastly improved with 1.9 - 2.0. Maybe I'll revisit in a year or two.

Anonymous said...

Rails is far better than ur java.

1. If Rails is so awesome, then why isn't there any documentation

for Documentation go to www.api.rubyonrails.com you can find each and every functionality of rails there

2. Your primary key must be auto-increment integer. Table names must be plural (i.e. turds). Join fields must be singular (i.e. turd_id). In that case, the turd_id field will automatically join to the turds table for you.

These are the feature of active record association of rails. If u don't know how to use these features then u can go to conventional method as like java.

If u don't know how to use these simple features then please go to some other field but don't blame programming language

Anonymous said...

to say "Rails is far better than ur java." is quite foolish.

I feel java is far more flexible than rails, and I think that is one of the general matters at hand - flexibility and control.

Unknown said...

I'm discovering that very thing right now. I'm writing forum software, and, having a little Ruby experience, I thought I'd try it in Rails to see what the hype was about. After a month, I got done what I could have gotten done in a week and a half in PHP because I spent most of the time looking up how to do things.

Here's the thing with ActiveRecord: most people that jump into Rails come from a PHP/Python background, and thus most likely already know SQL. Now, I hate SQL, but it took me much longer to figure out how to do complex queries with ActiveRecord than it would to just write the damn SQL statement. Though SQL does suck in many ways, in practice it's so much easier than trying to set up complicated relationships and whatnot. (And don't even get me started on the performance hit of using an ORM.)

Rails tries to make relatively simple things simpler, but the learning curve is so steep it's pointless. And in the end, you'll probably end up using SQL anyway because your queries get to the point where they're too complicated for ActiveRecord to abstract, thus defeating the point.

Anonymous said...

@Sasha
"Though SQL does suck in many ways"

Typical statement usually made by someone with little to no experience with SQL (or generally a developer).

SQL is extremely powerful and in many ways can accomplish tasks faster than any language. The problem is MySQL (which I refuse to use) created a lot of bad conceptions and habits. I've written SQL procedures that processed data in 5 minutes where a purely compiled (using row-by-row analysis) language took hours to do

Anonymous said...

rails books are outdated by the time they go to press.

Anonymous said...

I tried to implement an intranet in Rails and while I was able to quickly get something up and running I found it extremely limiting when I had to start doing interop with the desktop, etc, etc. After awhile I scratched the whole thing and started from scratch with a less exciting but stable framework, namely, Java EE. Works great, run on Linux with no problems, I get to write SQL -- and best of all I got to solidify in my mind why most Rails hackers are tools. Mostly Mac fan boys with no real programming chops, just able to scaffold some things and say "I'm an engineer!" I didnt beat my brains in getting a Masters in Comp Sci to write dinky, non-scalable web apps with a framework written by a foppish douche bag from Denmark.

Unknown said...

Endlessly repeating the no docs mantra doesn't make it true. There are plenty of books on RoR, stacks of online sites and forums devoted to Rails. And what's so wrong about the Rails API online docs?

Do you need to be spoonfed knowledge. Do something for yourself. As the saying has it, 'seek and ye will find'.

Anonymous said...

The issue here, as in most cases with Rails noob, is that you did not take the time to learn Ruby first. Rails is written in Ruby. You can not expect to understand a framework if the language it is written in is foreign to you. Is it possible to right a book in Japanese if all you have to go on is some stuff you picked up in a Japanese phrase book? Of course not. So why do people think they should be able to write an enterprise level application using Rails without any Ruby experience? It is a bad decision to attempt to rewrite a platform in a language you know nothing about and an even worst decision to use an esoteric API written in said language. The problem isn't Rails, its the PM who made a decision based on hype instead of thorough research. Rails is a tool and as with any tool if you don't know when or how to use it, you could end up breaking something and hurting yourself in the process. Rails works well for me, but to be fair, I actually know how to turn off Rails features I don't need and when/how to extend it with Ruby classes.

James said...

I agree on the active record find stuff being abit complex for complex queries...

BUT, you can just use active record for simple finds: ie. 'Model.find(modelobject) and then when you get into complex stuff just use 'Model.find_by_sql(["SELECT bla FROM table bla WHERE bla.name = ?", name])' it is limiting in that you can only pull out results in a collection of single objects, but you can pull attributes from other tables which get stuffed into those objects. So not a huge issue.

Vladimir Karmishin said...

You wrote down what I'm suffering right now. I have the same situation, since someone "clever" decided to use Rails as primary framework. I can't say that I'm completely newbie in RoR, since I used it on smaller projects in past years.
But when we're speaking about middle, or even large-sized business projects, the whole RoR architecture rather limit the developer from doing the 'right things', and tries to impose the own vision of how the things should be done. But damnit! It's just a stupid framework, why should I follow its vision of how database should look alike, rather than use own head.
I don't even speak about documentation. There's just NO documentation, except several screencasts and API reference at the site. When you ask people on IRC how the things are working, they point you to that api site. But God, I don't want to be an RoR developer, knowing how X or Y function works in-depth. I just need a prototype or code example.
RoR-way seems somewhat like debugging libstd with gdb to get knowledge about how to use malloc(). It's sad, but it's true.
I don't even mention that Ruby is somewhat "different" language, and there's no possibility to make something complex with it, without knowing the language itself. So it means additional couple of month for studying Ruby.

Ehh.. Sorry RoR guys, I mean no offence, really, just bit upset right now, spending ~26hours w/o any sleep converting our database to comply with "RoR standards".

Anonymous said...

At my work, we use ruby a few modular features. One I converted to php with great results (greatly improved performance, decreased complexity of the code base). But there is a custom ruby gem that was written in house we're still stuck with.

Without fail, every time there is a dependency update, something breaks. All the activesupport, actionmailer, actionpack, rake, hoe bullshit has NO concern for backwards compatibility. This crap is just not production stable at all. The gem cmd lets you see what needs to be updated but there is no simple way to know what is just a bug fix and what is security critical. As an sysadmin, I loathe having to support this garbage. Development is only part of the picture. Long term support from 3rd party software is critical to a successful business, and I get no indication from the ruby camp that they give a flying f**k about that.

Anonymous said...

jmonteiro:

Have you actually read any of those resources, or are you just cargo-culting them? My experience has been that

a) online rails "documentation" is horrible and

b) the books which the RoR community fawns over aren't really that great. For example, the "Agile" book is close to 900 friggin' pages, and has the least dense amount of actual useful information I have ever seen in a book of that length.

Tony Marston said...

If you are serious about writing a web application (not a web site) then you should take a look at Radicore (http://www.radicore.org). This is a rapid application development tool for building administrative web applications - those which deal with maintaining data in a relational database. It is written in PHP, which means that it uses a very popular and mature language, and it can be used with existing database schemas as well as brand new ones.

It does not use convention over configuration, so you do not have to design (or redesign) your database to follow these conventions. Simply use Radicore's data dictionary to import your database schema, then export it to produce a pair of class and structure files, one pair per database table. The class files are initially very small as the majority of code is inherited from an abstract table class.

This means that any valid table structure is acceptable to Radicore. The primary keys can have any name you like, have any type you like, and any number of columns you like. Relationships are defined withn the data dictionary, will allows tables in different databases to be related to each other. The relationship details, which are exported to the scture files, allow the framework to automatically construct SQL queries with JOINS to each foreign table.

Once the class and structure files have been produced for a database table it is very easy to use the data dictionary to generate the basic scripts to view and maintain the contents of that table. This is done by matching a table with a transaction pattern, then pressing a 'generate' button. It is therefore possible to import a table's schema, export those details, then generate the initial maintenance screens within minuts, all without writing a line of code - no PHP, HTML or SQL code.

If you wish to insert custom code to change the default behaviour the framework uses a series of customisable methods which exist in the abstract table class but which are empty - simply create a version of a custom method in your table class and it will be executed at the appropriate time.

If a table's structure changes all you do is re-import it into the data dictionary, then re-export it. It will leave any existing class file alone (in case it has bee customised) but will recreate the structure file.

Radicore also comes with its own Role Based Access Control system, dynamic menu system, audit logging system (which does not use database triggers) and workflow system. The DBMS can be either MySQL, PostgreSQL or Oracle.

The documentation for Radicore is very extensive, much more than a simple API list. There is a tutorial, and a series of sample applications so that you have working code to play with and examine.

Take a look. You might be impressed.

Wayne M. said...

Your problem stems from bad management blindly going in a particular direction, and nothing to do with RoR. RoR is a great framework when it's used in applications that fit it's "sweet spot". I agree that it's a poor choice for applications with complex business logic or weird legacy databases that don't follow the conventions that Rails expects.

For the applications which suit it's purpose (relatively small, CRUD-oriented database apps) Rails lets you get things done much quicker than using Java or PHP, and looks much more elegant too.

Tony Marston said...

@ Wayne M

> RoR ... is a poor choice for applications with complex business
> logic or weird legacy databases that don't follow the conventions
> that Rails expects.

If RoR cannot handle complex business logic then it is a poor framework. Radicore has no such problem as it has been used to create an entire ERP application.

If RoR cannot handle legacy databases, weird or not, then it is not a good framework. Radicore can handle any existing database schema with it's data dictionary import and export facilities.

If RoR imposes its own conventions on developers then it is not a good framework. Radicore does not have any conventions which limit the developer, so it is far easier to use.

You can import a database schema into Radicore's data dictionary, then generate the class files and maintenance transactions within minutes, all without having to write a line of code - no PHP, no SQL, no HTML. Can you do the same with RoR?

Rishav said...

@Tony: Rails doesn't force its own
convention on developers, it follows industry conventions. Yes its possible that making it work on a legacy database is hard.

I agree there is a certain lack of documentation or rather, when the framework itself is a moving target. Most books and posts may become outdated very easily.You guys can check out these http://api.rubyonrails.org, or http://guides.rubyonrails.org.

And the community behind is great. And I have always found that help is always available.

As far as complex business logic is concerned. Its made complex by developers not the framework. I don't think Java makes that business logic any less complex than .Net or any other framework for that matter.

The amount of productivity gain with Rails is awesome. I am nt trying to compare it with Java/.Net Web frameworks or any other language. But these languages have been around in the same domain for more than 10 yrs and there are an ocean but a person with good understanding of OO and MVC can make it happen in rails.

The idiotic choice here is going on "HYPE". That means you little understand what you are getting into. If i don't know python or Spring and willy nilly decide to do a project in that, I will screw my case, how ever great the framework.

Spending time and understanding the framework is necessary.

Anonymous said...

Rails sucks. Stay way from that community if you can coz its full of aliens.. :)

takecare said...

I FUCKIN' HATE RAILS! WHEN IS THE HYPE GOING TO END?

Shane Reustle said...

I agree on the statement above that ROR is just a bunch of "Mac users getting off on cute Ruby-isms"

btaylordesign_test said...

I've found that over the past two years, what Rails has in hype, Django has in substance. Rails is a monolithic nightmare, and it's really tough to re-use code from app to app. Yes, you can write plugins, but it's not the same as how Django apps have worked since day one.

Rails documentation is horrific. Why should I have to buy a book to learn how to build something? You can't do that with the Rails documentation. Django is very well documented, with free online resources to not only learn Django but also Python.

Do yourself a favor. Skip the hype and install Django. It takes about 10, maybe 15 minutes. Create some models and add them to admin. You'll see what I'm talking about.

Larger companies are also taking notice: National Geographic, The New York Times, The Los Angeles Times, The Texas Tribune, Nasa, Google, Michael Moore, Walmart - all using, or transitioning projects to Python/Django.

Anonymous said...

It is funny how people say nonsense like "I can do something in PHP in a week that took me 5 in rails".

Duh, it is because you are accustomed to a completely mess of a language, there are no words to how disjoint PHP is.

You are learning rails and ruby. If all you know is PHP or Java you have confined yourself into a tiny and rigid box and you may find a language with so many functional programming features disorienting, because after being in a prison, freedom is hard.

Rails isn't perfect, but it does have decent docs(and honestly, it is so intuitive that if you need to read a lot of docs in rails, you suck), and it is very easy to go with something against what it expects.

That you claimed you had to change your DB to match rails, just shows how ignorant you are. Besides, your crappy DB probably needed to be refactored.

The one constant in PHP programmers is ignorance about the field.

Anonymous said...

Rails does have problems. But, the worst case (which has happened to me 4 times this past year) is when non developers decide to use Rails to build their new application, give up when they haven't documented any of their work or have anything working, and hire a consulting business (like mine) to fix it.

The #1 problem with Rails is the users.

Anonymous said...

I couldnt agree more with this article. Rails is terrible. Just wait till you finish your overly complex application, and a new version of some random gem comes out. You go to update and everything will go to shit!

Anonymous said...

"I can't learn Rails on my own, because it's totally undocumented." - lol. seems like you got the job you deserve :D

Noel Cosgrave said...

What I really love is that the Rails convention of plural database table (relation) names goes against a long-established but somewhat less religious convention that database relation names should be singular. Rishav might like to state *which* conventions it forces developers to follow, because from a database developer's standpoint, Rails not only eschews conventions, it practically stomps all over them.

Also, what is the point of all this convention over configuration hype if you end up with an app that performs like a swimmer in treacle?

Anonymous said...

There are issues with ruby, but normalization definitely is not one of them. If you really don't understand what normalization is and why it is necessary then you shouldn't deal with databases.

Anonymous said...

Its April 2010. For the last 3 or 4 months I tried dabbling in Ruby and Rails. I have a C, C++, Java, PERL, PHP background. No, I have given up on Ruby and RoR. Its just too much to achieve simple things. In Java I have a choice to either use an ORM like Hibernate or iBatis or not use use ORM at all and write raw SQL. I can decide to use Spring for IoC and configure it exactly the way I want it. If I need something complex done on the server, and at blazing speeds, I can resort to doing it with C++ and my Java backend will easily work with it.

Naah.. Having developed actual working products and critical systems over the last 15 plus years, I dont think I will ever go for something like Ruby.

Infact I would still use PHP. Infact Facebook uses PHP which talks to C++ based services using their open source Thrift RPC. We use something similar in our production systems.

Naah, serious advise to anyone thinking of writing a mission critical application - avoid Ruby and RoR.

Anonymous said...

Rails gets a lot in your way, that's true. Specially if you want to do something your own way, like dealing with complex and big (as in size) databases. Or using a different template library or ORM, or whatever.

You might want to check Ramaze (http://ramaze.net/), which is another Ruby framework that doesn't get in your way, it has good documentation and a very supportive community, this framework also follows MVC, the "M" part it's up to you though. You can interact with databases in the any way you want.

For interacting with DBs I recommend Sequel. http://sequel.rubyforge.org/

Good luck.

Anonymous said...

Why should anyone listen to you since you don't know that Rails in not a language?

Rails is certainly not a silver bullet, but it takes less than a week to learn it well.

Ah well. At least you continue the stereotype of Java programmers not being professionals, just people who read Java for dummies that uses design patterns like they are going out of style.

Anonymous said...

""PHP/Apache will beat the heck out of Rails in performance, any day."

Actually it will not.

Ever heard of a little app called Facebook?

They need 1 server for every 200 users. Performance indeed.

Not to mention that PHP is the absolute worst designed language ever created for widespread use. Even VB is better designed.

Anonymous said...

"I tried to implement an intranet in Rails and while I was able to quickly get something up and running I found it extremely limiting when I had to start doing interop with the desktop, etc, etc. After awhile I scratched the whole thing and started from scratch with a less exciting but stable framework, namely, Java EE."

Is this a joke?

Ruby is a very powerful sysadmin language. Java and system integration? Now that is LOL worthy.

Anonymous said...

Do you people realize that you can use SQL directly in Rails?

It is rare when it is needed, or even a good idea.

There is a reason PHP apps are so brittle and fall down in the face of simple SQL injection attacks.

Anonymous said...

"Do yourself a favor. Skip the hype and install Django. It takes about 10, maybe 15 minutes. Create some models and add them to admin. You'll see what I'm talking about."

If Python ever gets the same amount of metaprogramming support that Ruby has, maybe then Django will be worth something.

Don't get me wrong Python is a good language but it suffers from being stiff. Not as stiff as Java, but nowhere near as flexible as Ruby.

You can't even write multiline lambdas in Python for crying out loud.

And the bolted on OO in Python is ugly like all bolted on functionality is.

FSK said...

Why did some Anonymous commenter try to publish 5 pro-Ruby trolling comments in a row within a few minutes?

Notice the huge bimodal distribution in comments:

- Yeah, FSK is right, Rails sucks.
- The fact that FSK says "Rails sucks!" proves how unqualified FSK is as a software engineer.

If you have the intelligent personality type, you hate Rails (if you've tried it). If you have the parasitic personality type, you love Rails.

The target audience for Rails is "evil software engineers". That's why it's incredibly popular even though it sucks.

I'm quite happy with PHP for my personal projects and work-related projects. If a job description says "Rails required", I know the employer is a fool and won't bother.

Anonymous said...

You are unqualified because you don't understand Ruby or Rails.

Spouting misinformation about something and then calling that something bad because your management sucks doesn't prove anything.

Protip: If are a programmer working for a company with bad management, you do in fact suck, since good programmers can work at good companies.

Someone who read the getting started tutorial for both know more than you.

Anonymous said...

I'm a "model" lover: I model a business using UML and then, I translate this model to a data model using very standarized translation... You can use ORM mapping or a manual iBatis helper, but: you always obtains a Relational database with foreign keys, complex keys.... all relational database can do.

With Rails... you program all the "relational" logic in the model, but rails offers you ways to pass throw this rules... you have an inestable model then: nothing ensures you that working only with this model all will be ok.

Rails force you to use autogenerated integers ids... if you try to manage a string primary key then there is a lot of methods that doesn't work: some of them spects that the key must be generated on the DB...

Finally... the "validates_unique"... you, as a good programmer, usually try to create something and if a unique restriction is unacomplished, transaction is rolled back and an exception is raised... all is atomic... rails says to you "the unique validator of the model dosn't use the unique definition of the database... only performs a previous select to check that no one is using the same value)... then insertion/updated is performed and a second select is launched to see that no other register has this values... 2 selects and the insertion/update command... just a lot of "shit"

FSK said...

In my current wage slave job, there's a lot of "stock_id, date, account_id" primary keys. It's be a PITA/impossible to model that in Rails with the "primary key must be autoincrement integer" restriction.

A common query is "Grab all records for this day." or "Grab all records for this account." Try doing that in a Rails-type database.

The joins would take hours, if I designed the database the "Rails way". I deal with 500k+ records per day.

You can't use Rails if you have complicated business logic and a lot of records.

Anonymous said...

This is a funny post. I somehow learned rails on my own in a week, and could move around and do anything I needed to comfortably inside a month.

Yes, the docs should be better but the fact that YOU can't learn it on your own is not a Rails defect.

Anonymous said...

"You can't use Rails if you have complicated business logic and a lot of records. "

Well, you can't but most people can.

Haven't you figured out how uneducated you are yet?

Anonymous said...

I'm just learning RoR now. And it seems like a big headache. It's like a lot of programming projects I have done where people try to create a complicated solution to a simple problem just to seem clever.

Website development is NOT that complicated. HTML/MySQL/PHP, simple as pie.

It may be useful to people that know it. But I am really fearful of any architecture that does everything for you behind the scenes and forces kludges to get it to work right.

MVC is mental masturbation. Website development doesn't need to be made to be more complicated. Sheesh. It's basically documents, how simple is that?

Anonymous said...

"I'm just learning RoR now. And it seems like a big headache. It's like a lot of programming projects I have done where people try to create a complicated solution to a simple problem just to seem clever. "

That's because you are not an educated professional.

That's not to say that Rails is perfect or useful for everyone type of web project.

Using Rails is not complicated in the slightest. The underlying library are quite complex and you need to understand advanced programming concepts to really understand it, which self-trained people rarely do.
MVC is very useful, you just have to understand the theory behind it. Unless, you are doing something complex and need to change Rails you don't really need to understand the library code.

PHP is never the correct solution though. It is by far the worst designed language, except for the oddball languages like Malbolge, but those were created to be bad.

Unknown said...

A friend and I are writing a rails application for fun and I have to say rails is an absolute pain we had to use php for half of it because rails 3.1 has no information around.

Anonymous said...

Rails 3.1 in development. Stable is 3.0.5

Anonymous said...

have you lot heard yourselves :/

I've been using rails for literally just over a week now and with the use of a BOOK i'm finding it rather easy! It has a number of pages, a shop reading off a database, a checkout system, log in system...everything.

If you ask me it just sounds like you lot are frigin lazy and can't be arsed to actually learn anything new. Stop laying in bed at night having a wank over your best mates girl and try reading a book before you start slagging software off. Rails isn't the problem.

Florian Dutey said...

I totally disagree with you.

1) Rails is not the "Leader" in documentation.

Indeed, there's not a LOT of documentation BUT, unlike java / php, the all documentation is clean. You won't find a fucking hudge dirty code to make a trim, written by a retard 12 years old kid wich is not able to read String's doc.

Ruby doc and Rails doc is more readable than javadoc. There's example most of the time wich is not the case of java. Plus, rubydoc is easier to read because of default css style.

Finally, there's not lot of documentation in rails because:

* it's younger (about 10 years) than php or java
* convention over configuration reduces need of documentation

2) You talk about rails as if it was a language itself. If you want some documentation about ruby and are searching in rails documentation for that, you're fucked.

What would you say to someone who would tell you "spring / hibernate sucks because in spring's documentation, I can't find a bit of documentation about java"?

3) Php would be better choice.

I don't think so.
Php sucks as time as you have a serious business layout. There's no cache system, no application server (everything is loaded at each request). Even if rails don't scale really good, php definitly sucks. Your only good argument is that your dev team would have less effort to switch to it. Plus, php prime types (like String / Int / Float etc...) just suck. It's not object, there's plenty of dark issues.
There's still the same prob of non compilation than in rails (errors occurs when running). There's lot of issues like this with spring / struts and IOC, XML driven app and jsp.

4) Rails scaffolding

Rails scaffolding IS NOT DESIGNED to create production templates.
It's only here to create a prototype very quickly.

Like with every framework, when you need to do some specific stuff, you have to do this "with your hands".
It's better to have a template system like php's than jsf or awful .NET xml templates. With jsf / gwt / .NET template, you ALWAYS reach a fucking limit where adding (for example) an id to a html tag need 1 day of work.

ActiveView approach with helpers to factorize view's business is the most efficient way to do html.
Just drop rails's javascripts helpers. Do vanilla js and everything will works. Little more time to develop, hudge time won for maintenance (if well written and documented).

Regards

Anonymous said...

Thanks for the key and specific criticisms of Ruby on Rails. Based on experience. Especially the parts about database tables and SQL.

And the fact that it is another "framework". For a good criticism on middle tier frameworks, see Toon Koppelaar's work:

http://thehelsinkideclaration.blogspot.com/2009/03/helsinki-declaration-observation-3.html
See all posts 1 to 4, and his posts on java too.

I've designed databases since 1992, and worked with Oracle since 1995. See my series of posts on Database Design Mistakes To Avoid, starting with:
http://rodgersnotes.wordpress.com/2010/09/14/database-design-mistakes-to-avoid/

I'll have to add this one. Making the reality of the data (the DB design) conform to a framework or process. Bizarre!!!

There, you'll also find more on architecture, tuning, design, crap software, managment, simplicity vs complexity, etc.

gv said...

The worst thing about the lack of documentation is not the difficulty of getting started - its the constant 'gotcha!s' as Rails tries to "help" you by munging your data. Like, permanently propagating form inputs into your links, with undocumented special 'blacklists' that don't get propagated...

The only way to code Rails is to constantly read all the library code. But as a productivity enhancer, it takes about 15x as long to do anything in Rails as without it other than display lots of rows of data and standard input forms.

Golda in Tucson, AZ

Florian Dutey said...

@gv:
What the hell are you talking about?

"form inputs into your links": Drop rails 2.x link helpers. That sucks and it has been rewritten long time ago in rails 3.x.

What do you mean by "munging your data?".

Anonymous said...

I love ruby. I love RoR -less.

Ruby delivers. It's genius. It's intelligent.

RoR is hyped by a bunch of fascist pigs who can't roll code out. A gem is written for one version, you use it, then the version advances but not the gem, you have to rewrite. You can't base business on that.

Without a good API, ruby is lost.

It's sad. Yes, and I was the boss-idiot who chose RoR. Now I wish I had written it in Java.

Florian Dutey said...

Yeah, you're right. Java has backward compatibility...

Try to move a java 1.4 project to java 1.6.
Lot of jars stop working when switching to new version of Java.

That's EXACTLY the same prob than Ruby or Rails.

You're not obliged to update your rails version in applications. If you chose gems wich are not supported in long term, you're a bad decider. That's the FIRST point I always check when I chose a gem. Will it be maintained? Is it already maintained since a long time?

WillPaginate is the perfect counter example to your argue. It's well maintained. A new version of rails is out, will paginate is updated the next week!

There's lot of gem wich are independant from rails, like acts_as_state_machine and won't have to be updated when new rails version is out.

Finally, View Helpers gem are most affected by rails updates in general. Just don't update your rails version until they're up to date. If they're not supported, change the way you chose your gems and update it. It's open source after all. A fork on github, an update on the gem and you contributed to the community.

Anonymous said...

If your Java jar files stop working when moving from 1.4 to 1.6, you might be a "bad decider" as well.

Ruby has a version and packaging problem that says "I don't want to grow up". So it hasn't, and it's no surprise.

Zequez said...

Rails is awesome.
Rails documentation sucks big time.

I had to read a book, but totally worth it.

Anonymous said...

"However, because none of us know Rails, they had to hire a Rails consultant"

I wouldn't have mentioned that since it shows that you guys are amateurs.

If you can't understand Ruby(including its awesome reflection and meta-programming facilities) and Rails and be productive inside 2 weeks, you don't belong in this field.

Unknown said...

I would like to state that I have had to have Rails force fed to me because my company has a lot of clients whose apps are Rails apps acquired from another company. That having been said, I would just like to go on-the-record as saying that the Rails framework has got to be the most ludicrous syntax of anything I have EVER encountered as a programmer. The syntax reads like a Finnish dictionary. Amputating my arm with a piece of paper would be easier than trying to debug that totally lame ass syntax. All in all, Rails makes me want to slap the everliving sh*t out of the moron that created it. I can't believe that people actually find this framework to be anything even remotely "developer friendly". Rails, in and of itself, is an egocentric framework that assumes you don't need to know wtf it's doing behind the scenes. Frankly, when I'm debugging those totally useless error messages in the logs, knowing what's going on behind the scenes would sure be a freaking major help. F**K RAILS! What a piece of SH*T framework!

bubuzzz said...

ha ha, i think it is not the problem of you and rails. It is the problem of you and your post :D. Great article :DDDD

Anonymous said...

You sir don't have a clue what rails was created for. Convention over configuration i.e. the rails way!! There are tons of books and online documentation exists!! Do your research!!!

Anonymous said...

Abstract: Rails is a framework not only comprised of a series of substantial components, but also dependent on non-trivial technologies to enable the productivity and happiness gains that veteran programmers often see. Most complaints about the framework bely the nature of the problem, which is that beginners are underprepared for introduction to the advanced concepts inherent in Rails, resulting in vocabulary confusion. Furthermore, this is a feature, not a bug; Rails’s value comes with its complication, and attempts to simplify it to be more beginner-friendly are simply misinterpreting the problem.

Anonymous said...

C/C++ developer here. 15+ years.

RoR is a joke, it doesn't make anyones lives easier except those who only use and think in ruby.

and my biggest problem wasn't even all the framework limitations or preceptions of them, not even the mediocre api docs, or even the fanboi online communities...it's simply the ruby syntax....its ugly to read, ugly to use. it hides too much and allows lazy garbage programmers to be employed.

No thanks, if someone were to even mentionion bringing in RoR I'd quit my job today.

jb said...

nice article,

im a ROR developer right now and I hate it. I miss working with php so much. Learning ROR feels like im learning photoshop and not learning a prgramming language. Things that take me a day in php take me 2 weeks to figure out in ROR. You learn nothing about programming when using ror because your so dependent on gems that you spend all your time getting gems to work together.

thats my 2 cents

JB Trebilcock

Florian Dutey said...

Are you saying that php is like paint, a non tool with no features that a monkey could use to do crap and ror is like photoshop, a complex tools that requires skills?

So we both agree.

Depending on gems means not reinventing wheel. You're exactly that php developer, always do things badly by himself, without feedback, coverage etc...

Florian Dutey said...

Are you saying that php is like paint, a non tool with no features that a monkey could use to do crap and ror is like photoshop, a complex tools that requires skills?

So we both agree.

Depending on gems means not reinventing wheel. You're exactly that php developer, always do things badly by himself, without feedback, coverage etc...

Aleksandar said...

Also and I am in RoR last 12 months, and my background are C, C++, C#, Java, VB, PHP, MySQL etc. I don't like "Convention over configuration", it's stupid (or write code in english only to be compatible with rails way). There are big chance that simple, basic things (compare to other languages) can transform to nightmare. Don't use it, and make mistake as I am.
regards

This Blog Has Moved!

My blog has moved. Check out my new blog at realfreemarket.org.