Re: Ruby vs. PHP

On 10/1/07, Marcin Raczkowski <[e-mail]> wrote:
> Richard Conroy wrote:
> > Why is this a good idea?
>
> why not?
> rails is easy to prototype but is painfully slow and hard to optimize,

Well thats a claim you will have to back up. I don't see it as being
harder than any other optimization work.

>  i know caching is going to play huge role but optimized complex sql
> queries are also important

And Rails/AR etc. support multiple levels of caching, and you can always
do find_by_sql. ActiveRecord dynamic finders are fun and all, but have no
place in a production app.

> possibility of continous development is one of strong points of rails,
> and that's why i'm advertising it, code writen by that large group of
> php developers is usually unmaintainable. I had plenty of expirience
> with php and i know how strangely can be php written, and rails forces
> good practices like MVC, and ruby i much cleaner langue then php to
> begin wth

Fair enough. Win for Rails.

> if it's easier to screw up in PHP with security, then here it's REALLY
> important, try to imagine hacker group logo in something like msn/yahoo
> main page

Agreed. But the default security in Rails is not bulletproof. Its also not
difficult to replace or improve. Edge Rails is bringing in protection for
Cross Site Request Forgery.

PHP security is probably going to remain a gaping wound for some time to
come. Win for Rails.

> >
> > PHP isn't exactly assembler speed itself. Ruby is in the same league (slower
> > with 1.8, faster with YARV). There is a reason that PHP is a central component
> > in a LAMP stack - probably the solution of choice for websites with high user
> > load. In principle Ruby can do the same, in practice we have only had
> > about 2 years
> > as a community to get big Ruby sites up. You also have an equivalent ASP
> > stack based on windows components.
>
> what is the reason? php was never solution of choice for high-load or
> professional websites,

Ah no. PHP is provably in use in many of the largest sites on the internet, like
Wikipedia, Facebook etc.. The foundations of why a basic language like
PHP works in this
environment is easy to understand: PHP doesn't give you many sharp tools
to hurt yourself with so its runtime characteristics are very predictable.

ASP stacks work the same way.

Rails is imitating those stacks. So it should reap the same rewards,
but the biggest
Rails website (twitter I think) is currently not in the same league as
the biggest PHP
and ASP sites.

Win to PHP. But not for much longer I suspect.


> > There's plenty of sites out there doing pretty heavy stuff with Rails,
> > but beyond
> > Rails there is not much evidence that shows pure Ruby custom web solutions
> > to scale. Rails has a lot of features and best practices built in to
> > help it scale.
> > In a pure Ruby solution you are committing to re-writing all of that
> > from scratch.
>
> any examples? i know google is starting to use Ruby.

Well no not really. The last really good writeup on the internal workings
of google, came from Steve Yegge a couple of months ago (see his
blog on Rhino on Rails).

Ruby is not yet one of the Google sanctioned languages (C++, Java, Python
& JavaScript).

> thanks for your response, it rises valid point that i have to think over

I am not being hypercritical of your choices. In your situation, I would go
with Rails over PHP as well, for much of the same reasons (performs
well enough, rapid delivery, long term maintenance).

But you have committed to an ActiveRecord rewrite, and your reasoning
is not clear. It sounds like you have read something that 'ActiveRecord
doesn't scale' without investigating thoroughly.

Rails gets a lot of its productivity from ActiveRecord. By getting rid of it,
you lose that, and you also close the door on the community development
of ActiveRecord and its supporting plugins.