Some interesting criticisms of rails

[David Balick]

may be found in the podcast
http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode-
09.html.

I am considering using rails (as opposed to asp.net) so am wondering what
y'all think of what these guys say.

In a nutshell, they say that Rails starts to get less appropriate for apps
with transactions that encompass entities other than just the database. If
the server side objects also modify the data, and particularly of the
modified objects then affect other objects, then it can become very non-
trivial to handle all of that in Rails.

Any feedback on this from experienced Rails folk would be most appreciated.

Cheers,
David Balick

 

[Han Holl]

------=_Part_9165_9483166.1126900052081
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
may be found in the podcast
http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode-
09.html.

I for one am _not_ going to listen to the criticism of someone who is too=
=20
lazy too write it all down.
Written text I can skim, reread and think about. Spoken text is much too=20
linear, and also often quite hard to follow for non native speakers.

Han

------=_Part_9165_9483166.1126900052081--

 

[David Balick]

I for one am _not_ going to listen to the criticism of someone who is
too lazy too write it all down.

------=_Part_9165_9483166.1126900052081--

Well... they are drunk and retired!

 

[David Heinemeier Hansson]

In a nutshell, they say that Rails starts to get less appropriate for app=
s

with transactions that encompass entities other than just the database. I= f
the server side objects also modify the data, and particularly of the
modified objects then affect other objects, then it can become very non-
trivial to handle all of that in Rails.

Since each request is handled in isolation, you rarely encounter
situations where object changes ripple through with tons of
consequences. At the end of each request, you'll have to persist your
data somehow, so whether that's in a database, Madeleine store, or web
service call, I don't see that being all that different.

Perhaps these guys are just solving different problems. But I found
the rant to be very abstract and hard to relate to. If you can come up
with a concrete example, I'd love to give a more concrete answer to
these concerns.
--=20
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

 

[Zed A. Shaw]

I remember reading about the Dining Philosophers problem when I was young and how it was solved with this incredibly complex logic proof that laid out most of the rules for what we know as "thread locking". For those of you who don't know, the Dining Philosophers is where there's four idiots arguing about communism eating a massive bowl of pasta and they're too stupid to ask for more than two serving forks. So, these "philosophers" spend a lot of time fighting over the forks and there needs to be a way to coordinate this fork "sharing". The solution? Ah, we'll add even more complexity to the problem and create neat things like semaphors.

Of course another way to solve the Dining Philosophers problem is: USE A FUCKING WAITER. You see, if these idiots don't serve themselves--but instead get their pasta from a "server"--then you don't have anybody arguing over shared forks. Hmmmm. "Server". I wonder why we call systems that act as a single access point to a service "servers"? Gee. That just stumps my tired little brain.

What's that got to do with the world of distributed transaction management? Well, you only need to have complicated distributed locking primitives when you try to distribute your shared resources to the point that people have to fight over them. If you just have a "server" that controls access and "share nothing" then the problem is solved in a much simpler way.

And BTW, if you've ever seen a gang of philisophical communists duel with forks for the last serving of fusili then you'll realize that letting communists share is not nearly as fast as having a waiter serve.

Zed A. Shaw
http://www.zedshaw.com/

 

[Joe Van Dyk]

=20
I remember reading about the Dining Philosophers problem when I was young=

and how it was solved with this incredibly complex logic proof that laid o=
ut most of the rules for what we know as "thread locking". For those of yo=
u who don't know, the Dining Philosophers is where there's four idiots argu=
ing about communism eating a massive bowl of pasta and they're too stupid t=
o ask for more than two serving forks. So, these "philosophers" spend a lo=
t of time fighting over the forks and there needs to be a way to coordinate=
this fork "sharing". The solution? Ah, we'll add even more complexity to=
the problem and create neat things like semaphors.

I remember that from a recent Operating Systems class. So it's still
in use today.
=20

Of course another way to solve the Dining Philosophers problem is: USE A =

FUCKING WAITER. You see, if these idiots don't serve themselves--but inste=
ad get their pasta from a "server"--then you don't have anybody arguing ove=
r shared forks. Hmmmm. "Server". I wonder why we call systems that act a=
s a single access point to a service "servers"? Gee. That just stumps my =
tired little brain.

I should've brought that up to the professor.


=20

What's that got to do with the world of distributed transaction managemen=

t? Well, you only need to have complicated distributed locking primitives =
when you try to distribute your shared resources to the point that people h=
ave to fight over them. If you just have a "server" that controls access a=
nd "share nothing" then the problem is solved in a much simpler way.

=20
And BTW, if you've ever seen a gang of philisophical communists duel with=

forks for the last serving of fusili then you'll realize that letting comm=
unists share is not nearly as fast as having a waiter serve.

 

[Robert Klemme]

I remember reading about the Dining Philosophers problem when I was
young and how it was solved with this incredibly complex logic proof
that laid out most of the rules for what we know as "thread locking".
For those of you who don't know, the Dining Philosophers is where
there's four idiots arguing about communism eating a massive bowl of
pasta and they're too stupid to ask for more than two serving forks.
So, these "philosophers" spend a lot of time fighting over the forks
and there needs to be a way to coordinate this fork "sharing". The
solution? Ah, we'll add even more complexity to the problem and
create neat things like semaphors.

First of all it's five philosophers (i.e. as far as I remeber it's important
that the number of resource aquisitors is odd). Then of course this just
serves as an illustrating example. The problem of shared resource access is
all too common in CS (for example in databases). You cannot solve it by
introducing a centralized server because that creates a bottleneck which
defies the purpose of parallel processing. Your waiter is not the best
solution. If you're interested in more details about how for example RDBMS
solve this there's a lot of resources out there to read on.

I don't know why think you have to rant about real CS problems or
communists. This is not an excercise to plague students but it's a real
issue and an important problem which must be solved. Without real solutions
your OS would likely perform much worse than it actually does.

Regards

robert

 

[Douglas Livingstone]

=20
First of all it's five philosophers (i.e. as far as I remeber it's import= ant
that the number of resource aquisitors is odd).

http://en.wikipedia.org/wiki/Dining_philosophers_problem

Not only five philosophers, but five forks too.

The solutions here are very much about moving the complexity out of
the application and into the database, which is fine if your database
can handle it. It doesn't *remove* the complexity as such, it just
means that you can stop worrying about it until your database servers
die, which in your average web app probably won't happen.

Douglas

 

[Alex Nedelcu]

That's assuming that's all we do: web apps that can move all the login
to the database.

 

[Zed A. Shaw]

Robert, where's the logical proof that distributed locking to control access to a shared resource is always faster than using a centralized server? I'm curious if one exists.

 

[Randy Kramer]

First of all it's five philosophers (i.e. as far as I remeber it's
important that the number of resource aquisitors is odd). Then of course
this just serves as an illustrating example. The problem of shared
resource access is all too common in CS (for example in databases). You
cannot solve it by introducing a centralized server because that creates a
bottleneck which defies the purpose of parallel processing. Your waiter is
not the best solution. If you're interested in more details about how for
example RDBMS solve this there's a lot of resources out there to read on.

Just replying for "fun", iirc, when I went to school it didn't make any
difference whether the number was odd or even--there was one fork for each
philosopher but he could only eat if he had two forks. (Sounds odd, now.)

But +1 on everything else in your post.

regards,
Randy Kramer

 

[Jason Voegele]

First of all it's five philosophers (i.e. as far as I remeber it's
important that the number of resource aquisitors is odd).

[snip]
Just replying for "fun", iirc, when I went to school it didn't make any
difference whether the number was odd or even--there was one fork for e= ach
philosopher but he could only eat if he had two forks. (Sounds odd, no=

w.)

When I first learned of the Dining Philosophers, they used chopsticks so
it made sense that they would need two in order to eat.

--=20
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life's externals may be transformed
or recombined. But it's smaller than we think."
-- Gene Wolfe, The Book of the Long Sun

 

[Randy Kramer]

When I first learned of the Dining Philosophers, they used chopsticks so
it made sense that they would need two in order to eat.

Thanks, that makes more sense and rings a bell!

regards,
Randy Kramer

 

[Alex Nedelcu]

Well, I first heard of the dining philosophers in the Java tutorial
where it serves as a perfect example to ilustrate deadlocks:
http://java.sun.com/docs/books/tutorial/essential/threads/deadlock.html

 

[Victor Reyes]

------=_Part_29913_20550405.1127085553895
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

"there's four idiots arguing about communism"

You got it all wrong, the "philosophers were arguing about capitalism and=
=20
how to complete the choking of developing nations.

I solved this problem during my master work in Ada, 1990 - (Yes, you heard=
=20
me well...ADA).

=20
Well, I first heard of the dining philosophers in the Java tutorial
where it serves as a perfect example to ilustrate deadlocks:
http://java.sun.com/docs/books/tutorial/essential/threads/deadlock.html
=20
=20

------=_Part_29913_20550405.1127085553895--

 

[Joe Van Dyk]

"there's four idiots arguing about communism"
=20
You got it all wrong, the "philosophers were arguing about capitalism and
how to complete the choking of developing nations.
=20
I solved this problem during my master work in Ada, 1990 - (Yes, you hear= d
me well...ADA).

How did you complete the choking of developing nations using Ada? I

 

[Victor Reyes]

------=_Part_34112_27998356.1127146004762
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

That was funny. You got my laughing! But, I am still doing it...the choking=
,=20
of course!

=20
=20
=20
How did you complete the choking of developing nations using Ada? I
=20
http://java.sun.com/docs/books/tutorial/essential/threads/deadlock.html
=20

------=_Part_34112_27998356.1127146004762--

 

[Bob Hutchison]

Hi,

I'm kind of interested in hearing opinions relating to the original
question.

I don't know a lot about Rails but I am very interested in learning
more. I've mucked about with it a bit but nothing serious. I
definitely formed a good impression of it.

David Balick <[email protected]> provided a URL
<http://www.drunkandretired.com/2005/06/drunkandretired-podcast-
episode-09.html> to a podcast that contains some criticism of Rails
(and almost as much praise, so I don't think of this as some kind of
rant/trashing of Rails).

It is, I think, difficult to pull the argument out of the podcast.
David took a shot at it...


In my opinion the comments regarding extended transactions is a bit
of a red herring -- it may well be an issue, but I don't know how big
in practice (though I'm sure BEA, MS, and IBM want you to believe it
is a HUGE problem . But more importantly, it seemed to obscure the
real point that was expressed before that.

Here is my take on the argument made:

1) They are talking about what they call 'enterprise' applications. I
think that they're talking about a class of applications that do
things that are more complex than manipulating data in a database
(and I think they are including in this wide-spread changes in the
database in a single transaction). I think getting hung up on the
term 'enterprise' is not a good idea -- everyone can name plenty of
enterprise applications that primarily manipulate localised data in a
database.

2) Rails encourages (forces?) the object layer and data layer to
merge with some negative consequences for that class of applications
(actually they may not have qualified this and so might have
expressed it as a universally Bad Thing)

3) Rails does not keep track of instances; so that if two requests
are made for the same object two different copies are returned (and
what comes with this is a performance question)

4) Rails returns the whole object graph with each request (which in
certain kinds of applications could pull much more information from
the DB than necessary)

5) Rails does not provide a transaction that can contain more than
one object retrieval and/or/? write to the DB (at least this is what
I think they meant) and that there is too much work (knowledge
maybe?) required to save changes -- this may be related to the kind
of thing Hal Fulton was getting at in the recent KirbyBase thread.

Now *I* am not making these claims, all *I* am trying to do is
explain what I heard on the podcast (and it isn't easy), and I don't
claim that I got *their* arguments correct either. But maybe there is
enough there to talk about. If not, maybe we should just make up our
own straw-man issues.

Since each request is handled in isolation,

I'm not sure what you mean by this.

you rarely encounter
situations where object changes ripple through with tons of
consequences.

Do you mean that you rarely encounter situations where many objects
are changed? Rarely as in not in most applications? or Rarely as in
many applications but only occasionally occurring?

At the end of each request, you'll have to persist your
data somehow, so whether that's in a database, Madeleine store, or web
service call, I don't see that being all that different.

I think they are complaining about what you have to do to accomplish
this in Rails, with the implication that you have to do a lot.

Perhaps these guys are just solving different problems.

Probably (and they called them 'enterprise applications' which I've
already suggested is a really poor name for them, and possibly
inflammatory). How would you characterise the problems that Rails is
really good at, and where it is OK, and where it isn't so OK?

But I found
the rant to be very abstract and hard to relate to. If you can come up
with a concrete example, I'd love to give a more concrete answer to
these concerns.

I find the argument a bit slippery, especially as I try to write it
down

I agree that this would be the best thing. I don't think I understand
their complaint sufficiently to try. I think I know what kind of
application they are talking about, and I have a lot of experience
with them, so with a bit more clarification, I might be willing to try.

(I don't think I've ever equivocated so many times in one sitting
before

Cheers,
Bob

 

[James Britt]

Hi,

I'm kind of interested in hearing opinions relating to the original
question.

Same here. I listened to the recording this morning while out running.

I don't know a lot about Rails but I am very interested in learning
more. I've mucked about with it a bit but nothing serious. I definitely
formed a good impression of it.

David Balick <[email protected]> provided a URL
<http://www.drunkandretired.com/2005/06/drunkandretired-podcast-
episode-09.html> to a podcast that contains some criticism of Rails
(and almost as much praise, so I don't think of this as some kind of
rant/trashing of Rails).

It is, I think, difficult to pull the argument out of the podcast.
David took a shot at it...



In my opinion the comments regarding extended transactions is a bit of
a red herring -- it may well be an issue, but I don't know how big in
practice (though I'm sure BEA, MS, and IBM want you to believe it is a
HUGE problem . But more importantly, it seemed to obscure the real
point that was expressed before that.

I got the sense that the lack of transactions was the main concern; that
there was no inherent way to assure that all clients were dealing with
the "same" object at any given time, and that one could not easily
update multiple resources (databases, message queues, what have you) in
one transactional shot.

Here is my take on the argument made:

1) They are talking about what they call 'enterprise' applications. I
think that they're talking about a class of applications that do things
that are more complex than manipulating data in a database (and I think
they are including in this wide-spread changes in the database in a
single transaction). I think getting hung up on the term 'enterprise'
is not a good idea -- everyone can name plenty of enterprise
applications that primarily manipulate localised data in a database.

Quite true. I sort of sniggered when they were talking about
"enterprise" apps, but I also think I understood well enough what they
were saying. It's sort of like when people toss around the equally
vacuous term "Web 2.0"; a bit of reading between the lines often reveals
the actual meaning in the given context (and it's typically less grand
than one might first think).

2) Rails encourages (forces?) the object layer and data layer to merge
with some negative consequences for that class of applications
(actually they may not have qualified this and so might have expressed
it as a universally Bad Thing)

3) Rails does not keep track of instances; so that if two requests are
made for the same object two different copies are returned (and what
comes with this is a performance question)

4) Rails returns the whole object graph with each request (which in
certain kinds of applications could pull much more information from the
DB than necessary)

5) Rails does not provide a transaction that can contain more than one
object retrieval and/or/? write to the DB (at least this is what I
think they meant) and that there is too much work (knowledge maybe?)
required to save changes -- this may be related to the kind of thing
Hal Fulton was getting at in the recent KirbyBase thread.

Now *I* am not making these claims, all *I* am trying to do is explain
what I heard on the podcast (and it isn't easy), and I don't claim that
I got *their* arguments correct either. But maybe there is enough there
to talk about. If not, maybe we should just make up our own straw-man
issues.

That sounds about right, though.

I'm not sure what you mean by this.



Do you mean that you rarely encounter situations where many objects are
changed? Rarely as in not in most applications? or Rarely as in many
applications but only occasionally occurring?



I think they are complaining about what you have to do to accomplish
this in Rails, with the implication that you have to do a lot.



Probably (and they called them 'enterprise applications' which I've
already suggested is a really poor name for them, and possibly
inflammatory). How would you characterise the problems that Rails is
really good at, and where it is OK, and where it isn't so OK?



I find the argument a bit slippery, especially as I try to write it
down

But still, not really a rant; while these guys may have been a bit
obtuse in explaining their concerns, they seem to have reasonable questions.


James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[Bob Hutchison]

Bob Hutchison wrote:



Same here. I listened to the recording this morning while out
running.





I got the sense that the lack of transactions was the main concern;
that there was no inherent way to assure that all clients were
dealing with the "same" object at any given time, and that one
could not easily update multiple resources (databases, message
queues, what have you) in one transactional shot.

Yes I agree, but there are two levels of this that came up -- at
least I think so. The first, and the one that I think they were most
concerned with, seemed to be transactions at the application level
but that only concerned the db. The second was the extended
transactions that include all kinds of stuff beyond the db (as you
say, like message queues, and any number of other things like
workflow, distributed transactions and stuff like that). If Rails
cannot deal with transactions as the application level then it surely
can't deal with the extended transactions. As I said, I don't know
Rails that well (cursory understanding, at best really) -- does Rails
really not have application level transactions? By application level
transactions I understand that to mean that if the application pulls
a bunch of objects in from the database, modifies some of them, then
Rails can guarantee that all of the changed objects have been written
successfully or not at all to the db. If Rails cannot do this, then
there is a class of applications that Rails cannot support. I find
this difficult to believe.

Quite true. I sort of sniggered when they were talking about
"enterprise" apps, but I also think I understood well enough what
they were saying. It's sort of like when people toss around the
equally vacuous term "Web 2.0"; a bit of reading between the lines
often reveals the actual meaning in the given context (and it's
typically less grand than one might first think).

And, of course, raises the possibility of a data integrity concern.

That sounds about right, though.

So we have a start