Isak H. wrote:
On 7/21/06, Henning K. [email protected] wrote:
And also - who says J2EE is faster? I believe that’s as much hype as
Ruby, the language, is dog slow, while Java runs about as fast a s
OK - and the point is? I said you had to decide between raw performance
of the language itself, and productivity of your developers. Again -
what would you prefer? Buying more (commodity, cheap) hardware - or
spending the money on increased development time and complexity
Also, Active Record is somewhat primitive, lacking support for
prepared statements, for instance. This means your app and database
are spending a fair amount of resources on parsing and planning the
same queries repeatedly.
True. Prepared statement support is lacking - but there is a reason. The
inherent dynamic nature of Active Record makes prepared statements a bit
of a no-go. However, there are ways to alleviate this. With Oracle, for
instance, you can set up the database to “semi-prepare” statements for
you that have the same general syntax (select firstname, lastname from
people where id = “23” automagically becomes select firstname, lastname
from people where id = :1).
Java is superior in other regards as well, for instance when it comes
to distributed transaction support and messaging.
Yes. But the question is - do you really need it, or can it be achieved
via simple scale-out with commodity hardware? If not - sure - go with
Java. Java has its place in the world, there is no doubt about that. So
does .NET, if you’re so inclined. DISTRIBUTED transaction processing
to me sounds like bad application design. It can just as easily be
achieved via database loading-tables and triggers/stored procedures.
Database transaction handling belongs in the database, not in the
That said, I generally prefer rails for anything that doesn’t require
massive throughput or distributed transactions…
Then, after all, I believe we are on the same page (although I might
lean a bit more towards Rails even in performance-intensive cases).
Performance can be achieved in numerous ways. Load-balancing, caching
(rails internal, assisted via memcached, or simply via massive amounts
of RAM on the db/web servers).