What are the cons of using rails?

Rails
61

2006/8/18, sean lynch [email protected]:

be in a year from now. For example there has been talk of removing the
webservices api from the rails codebase. (Yes it is then said to be
further
developed as a plugin, but for how long? There are already great rails
1.0plugins which ceased to be compatible with
1.1)

All good points Rodrigo, but I think that Java is far from stable.

in its programming conventions? I am not an expert in Java, cough, but
I
never knew that. Maybe the platform. I have a friend who programs Java
usually and he doesn’t complain about versioning and incompatibilities.

Each of the last three clients I worked at were migrating from 1.2x to

1.4x, even though 1.5 has been out for more than a year.

I started with PHP 5.2RC2 for my devel, to avoid this problem at least
for
the next 3 to 6 years.

The large banks and insurance companies I contract at do this to ensure

stability. They won’t support multiple versions, so they stay way behind
the curve on their upgrade path. They won’t even start completely new
projects with 1.5, until they start their migration to 1.5.

Yup.

So it seems that businesses interested in stability of language treat

Java the same way they would treat Ruby.

it helps developers to have more disposable jobs :stuck_out_tongue:

We’ll upgrade when we are convinced none of our systems will break.

Hard but more money :stuck_out_tongue:

That goes for Java, Ruby, or

even COBOL. (yes they treated the upgrade from IBM COBOL II to IBM COBOL
390 on the mainframe just like they treat upgrading Java).

COBOL was a painful language, since it had little standards.

So it seems the original poster’s complaints come down to "Ruby on Rails

has the same exact problems as every other language and framwork have."

Thanks Rodrigo

It’s such code, even C has those problems (I treat C++ as an
object-oriented
extension of C, rather than a language itself). It now complains with
#include <iostream.h>, requiring just …!!! Maybe the
framework
developers need to consider this on Rails, since this was a large
thread.

62

On 8/17/06, Zed S. [email protected] wrote:

My suggestion right now is that you can’t do anything about the above
two short of getting in there and fixing the problem yourself or trying
your app on something like jruby or the latest ruby 1.9 vm.

Zed,

Thanks very, very much for such an honest assessment of the situation.

It’s a disheartening read, but something I needed to read nontheless. I
have
a few questions for you if you have time:

  • Given your comments above, do you feel that Rails is not the best
    choice
    for production web applications if you intend to serve up a large number
    of
    hits? By coding with Rails in its current state, it sounds like a
    programmer
    may be painting themselves into a corner without a clear idea of how
    much
    paint thinner is in supply (or, for that matter, if paint thinner will
    ever be supplied).
  • Do you feel the 1.9 vm resolves most of these issuse? I could imagine
    it
    might resolve the IO slowness, but I presume it does nothing to solve
    the
    thread safety issue.

I appreciate your input.

Jake

63

Yes, Ruby VM is slow, but I played with YARV and it beats the ass even
to Parrot VM.

On some Fibonacci and Ackerman tests it was 40 times faster then current
Ruby VM and
30-40%% faster then Parrot VM. I was really surprized and pleased with
results.

PS: I just did this test yesterday. I used YARV-current.

All the Best!
Sergey.

64

Sorry for the jumping in, but, Ruby has slow I/O ? Compared to C with
sysread perhaps, or pure assembler, then yes, but, do you have example
timings and code that I could read as ‘proof’ ? Hopefully your not
basing this -purely- of a file.open and you -have- tried with file.read
… in much the same way as perl, python and java do ‘behind the scenes’
… yes ?

Statements without sufficient evidence are merely personal conclusions
:wink:

Regards
Stef
(ps. I am not a language zealot by any means and have zero intention of
starting/joining a flamefest :wink:

65

Let me try to explain why stability / backwards-compatibility is an
issue for me with rails.

Maybe Iâ??m just unlucky, but in my 2 pet projects for which I use RoR I
definitely suffered from backwards incompatibility. The first issue I
had to deal with was scoping in active record. Nested scoping has been
added, and as a result my plugin that kind of mimicked this behavior was
broken. Not a serious obstacle, and fixable, but certainly annoying.
Then we have memcached activerecord. Worked great, less great when 1.1
was introduced.
For rails 1.2 the routing part of framework will be redone. Again, bad
luck for me, as I altered the behavior a bit.

Compared to other frameworks (for example symfony, django, webwork),
rails is, again in my opinion, more vulnerable to source-code changes.
Ever since I started with rails it has been advertised as a framework
which is easy to extend (or break open). And indeed, with the ruby
language is extremely easy to alter objects during runtime. Of course,
this only works as long as the internals of rails do not change. And the
fact is, they do… not only the internals of function calls change, but
the behaviors of them as well. In a â??normalâ? framework, this is not an
issue (it is why one has protected methods). However, with rails, in
which custom configuration/behavior is to be implemented by (simple)
plugins that indeed do either alter or extend such internal functions
changes to the code can easily wreck damage to custom plugins. (This is
the reason I mention symfony as php-framework and not something like
cakephp… pure rails in php doesnâ??t work for me… because customizing it
is hardly possible in an elegant way)

If rails didnâ??t depend so much on â??hacking: into the framework Iâ??d
probably be more forgiving to a little â??instabilityâ? in its codebase.
Though they way rails works makes such instability difficult to accept.

66

@Brian H.,

As you said, you noticed the same problem with other frameworks. However
as I understand from your examples it where the developers of the final
application that made the “hacks” into the framework.

Rails, atleast for me, is more or less all about modifying the
framework. The whole â??DRYâ? principle is more or less about making rails
behave to suit your needs. See for example all the plugins that use this
way of customizing rails. Moreover, where in another framework I can
configure most behaviour in rails getting the same behaviour inevitably
means both extending/customizing classes, and using the new custom
class. (But due to the magic going on this is not always as transparent
as one would expect, for example telling rails to use RoutingExtend is
going to be a lot more troublesome than simply customizing Routings
behaviour to get that “.html” extension to work)

To me this situation simply spells out “trouble soon to be expected”. As
long as I’m in control, not much trouble. That’s why Iâ??m perfectly happy
with using rails on my own apps. But apps I develop for another, and
that eventually might have to be maintained by another, might, in due
time, surely somehow/somewhere result in something hard to fix. (Unless
you choose not to use all those rails goodies ;))

While php5 (though it might not be fair to compare a language with a
framework) indeed broke most php4 apps, at least php4 is still being
maintained. With rails as soon as a new version arrives the old version
is not. Django is being kept beta 0.x until their api is stable. And
even webwork 2.2 only needed a few minor adjustments. Iâ??ve never noticed
such a rapid accession of backwards incompatible changes as I noticed
while using rails. Maybe Iâ??m just unlucky or rails makes is too easy to
do the â??advancedâ? stuff that is breakable :wink:

67

On 8/18/06, Colin Cc [email protected] wrote:

Compared to other frameworks (for example symfony, django, webwork),
rails is, again in my opinion, more vulnerable to source-code changes.
Ever since I started with rails it has been advertised as a framework
which is easy to extend (or break open). …

Don’t put your trust in symfony. The framework may not want to change
but instead the whole programming language is. PHP5 broke a lot of BC
and a lot of code didn’t port well. But now PHP6 is getting closer and
EVERY PHP application will break because they will introduce
namespaces. Yes thats right. Thay are finally putting in
namespaces… IN RELEASE 6???
django is now pretty stable NOW but it has not been. And it will
remain stable only until the first major bug is found. Actually the
only framework I really trust to remain stable right now is Catalyst.
Pretty ironic since it’s the youngest of all these. But of course
since it’s written in Perl you better get it right in the first
attempt because in a month you will be unable to understand your own
code. :wink:

–

68

Zed S. wrote:

On Fri, 2006-08-18 at 03:20 +0200, Andreas S. wrote:

snacktime wrote:
I’m often wondering: what is all this RAM actually used for, e.g. the
30-40 MB of Mongrel+Rails? Is it object data, is it code, …? Can
anyone of the Ruby experts (Zed?) give me some insight?

Not sure at all as I haven’t looked into it. For me 40M is a dream
compared to the monstrosity systems Java inspires.

Yes. But we shouldn’t only compare Ruby to the worst alternatives.

69

On 8/18/06, Zed S. [email protected] wrote:

What you must focus on–especially if your performance problem is
based on user perception–is how to make your application seem faster
to the users. This involves less mucking with code and more observation
and measurement of what users think. People are visually pretty dumb,
so you’d be amazed at what little stupid tricks you can do to simply
make them believe your stuff is quick.

I’m just starting out with Rails and this comment piqued my interest.
Could you please offer some examples?

70

@Colin:

Your issues are a direct result of your choice to modify the framework
to
suit your needs. When you do that in ANY open-source project, the
responsibility shifts to you to make things work when new versions come
out.
The Rails core makes no guarantees to anyone about plugins working after
upgrades; that’s why they allow for plugins instead of taking those
patches
into the core.

There’s usually a way to achieve what you want without modifying how
Rails
works… and you might want to explore ways to extend the framework
rather
than modifying its behaviours directly.Make your own class that extends
ActiveRecord and extend your models from that for example or invesitage
using modules to apply behaviours as needed. Now, I don’t understand
your
specific situation but I bet there’s a solution that would work well for
you.

I don’t see these as the fault of Rails. Rails doesn’t “depend on
hacking
into the framework”. Just because Rails allows you to modify the core
doesn’t mean you have to, or should.

I’ve seen Java projects stuck at Hibernate 1.0 because upgrade paths are
not
an option due to customization. I’ve had to support running PHP 3, PHP
4,
and PHP 5 in order to keep apps running because developers can’t modify
the
apps to work in the later versions of PHP.

I don’t consider this a problem with Rails because it seems universal to
me.

Just my .02 and I want to say you have brought up some very good
arguments.

Cheers!