What are the cons of using rails?

Performace hits? Integration with existing applications? Security?
Bugs? Memory use?

-Ben L.

On 8/15/06, Ben L. [email protected] wrote:

Performace hits? Integration with existing applications? Security?
Bugs? Memory use?

The biggest con for me is defending Rails against all the (perceived)
hype among non- Ruby programmers.

Most all the programmers I’ve discussed Rails with over the past year
or so think learning Ruby and Rails is high risk as it may very well
fizzle out at some point in the future. Many languages come and go,
even more so with MVC frameworks the past few years. I believe in
Rails but conveying my reasons for that leap of faith into learning it
to someone else is no simple task.

For me it’s like 1997-98 all over again. I woke up one morning (back
then) and realized if I learned PHP that I could stop coding in Perl.
I worked at it and it became a reality and I haven’t touched any Perl
in my daily job in a long, long time. (I absolutely despise timtowtdi
with my mortal soul.) But lately I’ve been waking up thinking if I
master Ruby and Rails, at some point I can pretty much stop writing
PHP for a living.

Some might consider another major con to be all the books you might
need to buy… and how quickly they become outdated.

it’s not “corporate”, not “enterprise”, it’s driven by good sense. You
will have lots of difficulties to sell the idea in these environments
(believe me)…

Jean-Etienne

Memory use is good. At least it’s a few times better than Java’s.

Almost all cons regarding Ruby on Rails relate to it’s youth. The
documentation is not good enough but mostly it’s the fact that there
isn’t enough code floating around. If you are developing in
Java/PHP/Perl you can always do a quick krugle.com search and see at
least 10 different solutions to what you are trying to accomplish.
Search for the word “session” in PHP and you see 72.595 different PHP
files. Do the same for Ruby and you get 387.

On 8/15/06, Ben L. [email protected] wrote:

http://lists.rubyonrails.org/mailman/listinfo/rails

+1 on that.

I spend a lot of time spreading the word on Ruby on Rails. Here’s the
thing
though: If you’re in IT, you are expected to learn new skills to get
things
done. Rails will eventually lose momentum to something better. Right
now,
it makes me more productive and helps me stay creative. (Less busy work
means more cool features and more time solving the real problems.)

Here’s my list of cons though:

  1. Rails productivity takes a huge dive if you are forced to work with a
    legacy schema. It’s designed to make you productive if you can do things
    using the conventions. If you can’t, you’ll spend much more time.

  2. Rails is only 100x more productive than PHP if

    • you scaffold everything and leave it alone (simple blogs or
      cookbooks)
    • you don’t write any tests
  3. Learning Rails is difficult, especially if you come from a Java
    world.
    You expect things to be harder. It’s also harder to learn by example
    because
    the really good programmers use a lot of tricks that are unique to Ruby
    itself. You don’t HAVE to do things the Ruby way, but if you don’t
    learn
    Ruby well, you’ll be at a disadvantage.

  4. Documentation is lacking. This is being worked on, but there is an
    emphasis on “free framework, pay for training” in this community.
    Personally, I have no problem with that as I make some decent money from
    training and it’s something that I really enjoy. However, some people
    think
    that free projects should make everything free.

  5. Rails is new. It’s a little rough in a few areas. However, I’ve never
    seen a 1.x version run this smoothly.

  6. Deployment is unfriendly. Don’t believe the hype… it takes work and
    understanding to do it right. Guess what? There will be a book on this
    shortly.

There isn’t a single thing here that would deter me from using Rails or
recommending it to anyone else. The productivity gain is worth it.

Less time coding means more time with the kids, the wife, the
girlfriend,
the bar, the race track, or just more projects.

:slight_smile:

-bph

On 8/15/06, Ben L. [email protected] wrote:

Performace hits? Integration with existing applications? Security?
Bugs? Memory use?

Cons of using Rails for what? That’s like asking “what are the cons
of using a shovel?”

Joe

Brian H. wrote:

[…]
Right now, it makes me more productive and helps me stay
creative. (Less busy work means more cool features and more time solving
the real problems.)

yeah, that’s surely a pro.

Here’s my list of cons though:

  1. Rails productivity takes a huge dive if you are forced to work with a
    legacy schema. It’s designed to make you productive if you can do things
    using the conventions. If you can’t, you’ll spend much more time.

I don’t know what do you mean about a legacy schema. If I check my
manual, surely Rails accepts well the normal forms required to ensure
your database-driven applications run properly, so if you can’t, you
will spend more time but who’s guilty? you, not Rails.

  1. Rails is only 100x more productive than PHP if
    • you scaffold everything and leave it alone (simple blogs or cookbooks)

If you scaffold anything with script/generate scaffold, and edit the
code by copying and pasting to get the result you want, Rails isn’t 100x
productive as PHP is, but it surely is 90x… still more!

In fact, I didn’t see Rails (or Ruby as a sole language) changing naming
conventions, something that helps developers. Think: If we compare, PHP
has many brain-storming naming conventions like:

strreplace (object then verb)
move_uploaded_file (verb then object)
rewind (just the verb)

or:

move_uploaded_file (with underscores)
strreplace (without underscores).

  • you don’t write any tests

If you know what you are doing, you don’t have to write any tests. First
before creating an application, you have to diagram everything using
your favorite methodology: for me, the best is UML, some E/R Diagrams,
and a sitemap.

  1. Learning Rails is difficult, especially if you come from a Java
    world. You expect things to be harder.

Not harder: different.

It’s also harder to learn by
example because the really good programmers use a lot of tricks that are
unique to Ruby itself. You don’t HAVE to do things the Ruby way, but
if you don’t learn Ruby well, you’ll be at a disadvantage.

Sounds like learning Ruby is the same as learning Assembler, and it
surely is not.

  1. Documentation is lacking. This is being worked on, but there is an
    emphasis on “free framework, pay for training” in this community.

In my point of view, yes, but it’s because Rails is relatively new.

Personally, I have no problem with that as I make some decent money from
training and it’s something that I really enjoy. However, some people
think that free projects should make everything free.

Opensource has to be financed in some ways. Surely Rails kids hadn’t to
pay for Ruby, and Ruby hadn’t to pay for GCC, and GCC hadn’t to pay for
Linux… But programmers are human, not programmers. As humans, they
have to eat, too.

  1. Rails is new. It’s a little rough in a few areas. However, I’ve never
    seen a 1.x version run this smoothly.

Being new doesn’t mean immature. Bad point of view. If you look to
Windows Vista, it’s new and some corporate guys are using it just
because it’s “a new technology”. Being new is not a reference. Something
new could be worked in the darkness for years (as .NET did since 1999).

  1. Deployment is unfriendly. Don’t believe the hype… it takes work and
    understanding to do it right. Guess what? There will be a book on this
    shortly.

ok, this is very true.

There isn’t a single thing here that would deter me from using Rails or
recommending it to anyone else. The productivity gain is worth it.

I don’t want to make a holy war, I just want to give an “optimistic”
point of view. As a database administrator and systems architect, i
found rails is enough for many industry-related works.

Less time coding means more time with the kids, the wife, the
girlfriend, the bar, the race track, or just more projects.

…or more beer!

:smiley:


Rodrigo F. Cartes
Software Developer / Systems Architect
Parés & Alvarez Ingenieros Asociados
Concepcion, Chile.

I"ll condense what Brian H. said in points 3-5. Learning Rails is a
huge amount to swallow (likely less so if you’re coming from Java or
.Net), made even more difficult by the sparse documentation. I’ve also
encountered several rough edges, banged my head against them, then found
a solution by googling and finding somebody else who encountered the
same problem and figured out a solution – oftentimes all of this being
a result of incomplete documentation. I’ve submitted many tickets to dev
when it was working. In the meantime, I just add to the wiki.

But since switching to Rails, I do have a lot more free time and have
been getting a LOT more things done.

Joe

Joe Van D. wrote:

On 8/15/06, Ben L. [email protected] wrote:

Performace hits? Integration with existing applications? Security?
Bugs? Memory use?

Cons of using Rails for what? That’s like asking “what are the cons
of using a shovel?”

Joe

I think he’s asking what are the cons of using a pickaxe :stuck_out_tongue_winking_eye:

Joe

On 8/15/06, Rodrigo F. [email protected] wrote:

If I check my
manual, surely Rails accepts well the normal forms required to ensure
your database-driven applications run properly, so if you can’t, you
will spend more time but who’s guilty? you, not Rails.

Not all Rails apps will use a new database schema, some will use an
old schema with established field names that are unchangable for
whatever reason. It does take additional time to deal with this sort
of setup.

If you know what you are doing, you don’t have to write any tests.

I’m quite happy the Rails developers write tests in spite of their
knowledge level. Being smart is terrible reason to not write tests.
I’d rather just admit the truth, I’m lazy sometimes.

Opensource has to be financed in some ways. Surely Rails kids hadn’t to
pay for Ruby, and Ruby hadn’t to pay for GCC, and GCC hadn’t to pay for
Linux… But programmers are human, not programmers. As humans, they
have to eat, too.

Some people code because they like to code, not because they need to
make money from their works.

  1. Rails is new. It’s a little rough in a few areas. However, I’ve never
    seen a 1.x version run this smoothly.

Being new doesn’t mean immature. Bad point of view. If you look to
Windows Vista, it’s new and some corporate guys are using it just
because it’s “a new technology”.

Corporate guys are idiots.

Being new is not a reference. Something
new could be worked in the darkness for years (as .NET did since 1999).

Darkness is the best place for .net and M$. Bottom of the ocean,
rocket ship to another planet, whatever.

…or more beer!

Or more Ruby and Rails books.

Cons of Rails:

  • lack of really big Rails applications in the market, which is an
    issue because many customers think their app will potentially need to
    scale to 1M hits/second so want to be convinced that it’s possible
    before you start
  • Rails is a particularly good fit for a defined problem space (e.g.
    non-legacy database, single-app database, Ajax interfaces, MVC
    architecture). Once you go outside that problem space, for whatever
    reason, most of the productivity improvements in Rails disappear very
    quickly
  • lack of a big pool of Rails developers. It’s improving, but
    compared to Java and C# there’s a long way to go

Regards

Dave M.

What are the problems with Rails and “legacy” databases? AFAIK,
composite keys, but I think Dr. Nic has a plugin that addresses that.
Anything else?

Joe

What are the problems with Rails and “legacy” databases? AFAIK,
composite keys, but I think Dr. Nic has a plugin that addresses that.
Anything else?

You lose all the conventions… so you have to sprinkle a lot of
set_table_name() and friends in your models…

not that big of a deal if you ask me…

-p

Greg D. wrote:

Not all Rails apps will use a new database schema, some will use an
old schema with established field names that are unchangable for
whatever reason. It does take additional time to deal with this sort
of setup.

but it’s still less code, since 3NF helps a lot here. I haven’t had
problems even by using OIDs in PostgreSQL… So, why coding more than
needed?

Clean code, less tricks, more extensibility. I found, at least in my
project, that Rails has everything I need for my own development, and
offers more than PHP itself.

If you know what you are doing, you don’t have to write any tests.

I’m quite happy the Rails developers write tests in spite of their
knowledge level. Being smart is terrible reason to not write tests.
I’d rather just admit the truth, I’m lazy sometimes.

I didn’t say “I’m smart, I don’t write tests”, I usually write tests
when the code isn’t clear for my way of attacking a problem. But it’s
not completely needed, that’s what I mean.

Opensource has to be financed in some ways. Surely Rails kids hadn’t to
pay for Ruby, and Ruby hadn’t to pay for GCC, and GCC hadn’t to pay for
Linux… But programmers are human, not programmers. As humans, they
have to eat, too.

Some people code because they like to code, not because they need to
make money from their works.

You said: “some”. And I know what are you pointing to, and I will
support your idea with my experience: I am working at my job, not
because I had a “Microsoft Certified Professional” diplomma, nor an
“Oracle Certified DBA” one. It’s because I had supported open source
projects in the past (mostly academic implementations here in Chile). I
didn’t get money for them, but I got a good job because of them.

Programming open source requires good skills, and being successful in a
project means you have good skills, and there are some places (mainly
academic ones) in where if you programmed PHP/Perl for 3 years means
more than programming Visual Basic for 3 years.

Being new doesn’t mean immature. Bad point of view. If you look to
Windows Vista, it’s new and some corporate guys are using it just
because it’s “a new technology”.

Corporate guys are idiots.

I agree. But they have a point of view, that should be considered, not
in a specific way but in the general way. Never say something is bad
because it’s new.

Darkness is the best place for .net and M$. Bottom of the ocean,
rocket ship to another planet, whatever.

I don’t find .NET to be bad. It was built in a bad platform, that’s
another story. But the way it interacts with another programs is not a
point to discuss. Why then Miguel de Icaza wrote Mono? Because .NET as
an architecture is bad?

Holy wars don’t make anyone happy.

…or more beer!

Or more Ruby and Rails books.

…I will write one and I will sell it: 2.5 beers the unit.! :smiley: ok ok
bad joke.

Philip H. wrote:

What are the problems with Rails and “legacy” databases? AFAIK,
composite keys, but I think Dr. Nic has a plugin that addresses that.
Anything else?

what do you understand as “legacy” or “not legacy” db’s? I’m not english
speaker so I missed the point.

Rodrigo F. wrote:

If you know what you are doing, you don’t have to write any tests.

I’m quite happy the Rails developers write tests in spite of their
knowledge level. Being smart is terrible reason to not write tests.
I’d rather just admit the truth, I’m lazy sometimes.

I didn’t say “I’m smart, I don’t write tests”, I usually write tests
when the code isn’t clear for my way of attacking a problem. But it’s
not completely needed, that’s what I mean.

To me, test are more insurance than anything else. I don’t want to get
scatter-brained trying to remember everything that might break by
changing code, and don’t want to get caught with my pants down when it
does.

Joe

Rodrigo F. wrote:

Philip H. wrote:

What are the problems with Rails and “legacy” databases? AFAIK,
composite keys, but I think Dr. Nic has a plugin that addresses that.
Anything else?

what do you understand as “legacy” or “not legacy” db’s? I’m not english
speaker so I missed the point.

I’m not sure – legacy=poorly designed (e.g. not conforming to the three
normal forms) database(s) perhaps. I have some non-legacy databases I
created from scratch for Rails apps and creating associations between
tables wasn’t the easiest (had to result to :finder_sql).

Joe

Cons of Rails:

  • lack of really big Rails applications in the market, which is an
    issue because many customers think their app will potentially need to
    scale to 1M hits/second so want to be convinced that it’s possible
    before you start

Our site (not pjkh.com, heh :slight_smile: recently did just under 9 million pages
in a day. For August we’ve averaged 4.5 mil pages/day (and about 40 mil
hits/day).

Rails scaled just fine, it’s the database you have to worry about (and
in
that regard, memcache helps a lot :slight_smile:

Not that Alexa is the be-all-end-all, but just to give you some
comparision’s on what is considers “page views” during August compared
to
penny-arcade and basecamphq which are the two sites that always seem to
crop up when scaling is mentioned…

http://img312.imageshack.us/img312/3569/alexavd9.png

So, yeah, Rails can scale… at least this high… which is more than
most
websites are going to see…

Anyway, when things settle down for us a bit we’re going to write up
something that will hopefully help folks convince their PHB that Rails
scales just fine…

-philip

normal forms) database(s) perhaps. I have some non-legacy databases I
created from scratch for Rails apps and creating associations between
tables wasn’t the easiest (had to result to :finder_sql).

Not necessarily… legacy just means “existed before I started my rails
app”. For instance you might have a table:

employee

employee_id
fname
lname
address <— foreign key to ‘address’ table.

Nothing wrong with this table, except that Rails would prefer by
convention:

employees

id
fname
lname
address_id

So you have to tell Rails (through your models) what to look for since
you’re not going to be able to follow it’s convention.

-philip

To me, test are more insurance than anything else. I don’t want to get
scatter-brained trying to remember everything that might break by
changing code, and don’t want to get caught with my pants down when it
does.

Good answer, when it is a big project. That’s surely a very good pro for
Rails over PHP. (even using a framework -not-sf-or-cakephp- ).