Ruby vs. PHP

[Lionel Bouton]

Hello experts,

I thought this topic was quite related so posted in this same thread..

We are going to start a new website (serving videos

Ruby speed is irrelevant.

but several database
intensive features as well

There too (unless these "intensive features" involve fetching high
number of rows and computing on them in Ruby).

), and we think it will hopefully reach a
stage where scalability is going to become important.

Hence I wanted some idea abt speed..

You may want to compare RDBMs under your projected concurrent loads and
storage solutions for serving video...

Lionel

 

[John Joyce]

Ruby speed is irrelevant.


There too (unless these "intensive features" involve fetching high
number of rows and computing on them in Ruby).


You may want to compare RDBMs under your projected concurrent loads
and
storage solutions for serving video...

Lionel

If you by "serving videos" you mean streaming videos, you'll want
some specialized software, like Quicktime Streaming Server for
Quicktime, other stuff for RealMedia, other stuff for WindowsMedia,
other stuff for FlashVideo.
You can still call it from whatever language, but you might want to
think about serving video from the file system for speed.
You could keep an index of it in a database, but serving video
directly from a database might not be such a hot idea.

 

[Julian Tarkhanov]

also I'm open to any arguments(preferable documented, with
showcases, and understandable by investor(who never had much
expirience with computers except for e-mail and www)) that would
help convince him that ruby is much better then php

I have an argument, altough a weird one at that. PHP is all about
Apache deployment and mod_php. It's _optimized_ for the situation
whereby you have many
applications running on the same site and many of these applications
might be sloppy. Because of that, PHP dedicates a majority of it's
potential to sustain a
shared-nothing architecture where the virtual machine gets
reinitialized on every request etc. This is a total win for shared
hosting and fast and dirty deployment on shareds,
but this strength is not applicable to high-volume deployment (on VPS
or dedicated - which is I supposed is your deployment scenario for
this scale).

In any _other_ area than deployment with maximum security of
_developers_ from each and _raw speed_ PHP looses to Ruby. The
following arguments are boilerplate that I usually put on the
table when the question 'Why Ruby arises':

a) the obscurity of the language gives much higher guarantees of
library quality (both in implementation and style). All Ruby libs I
came to use in the last few years have been remarkably elegant.
b) the fact that Ruby is currently on the edge of Agile interests
(there are just more metodologies that get tested in Ruby-land as
opposed to PHP)
c) any developer with a level of OOP experience can pick up Ruby
remarkably easily (this does not apply to troglodyte bold types who
want their "for" loop and don't give a damn about design)
d) most Ruby developers favor "clean" in place of "fast and dirty"
e) if you got the hardware the deployment is actually much more
streamlined than for PHP projects (with tools like cap and vlad)
f) all C-aware developers that I know admitted that writing Ruby
extensions in C is a breeze, if you need it
g) there is quite some development going on in the alternative
interpreter scene (with projects like JRuby, Rubinius etc)

Basically there are two, and only two situations where I would either
drop the project because it needs PHP or write it in PHP klinging:
a) you want ubiqutous deployment options - you want to distribute the
script that the user can install on a shared hosting platform where
he's even disallowed from doing a database dump
(not your case)
b) you need to bind to Win-only API's or deploy on Win

That's one of the best articles I know of on "slow versus fast" argument
http://plasmasturm.org/log/443/

 

[Julian Tarkhanov]

I think one of the reasons it took off so well is that its syntax
is very C-like so many computer science grads feel right at home
with it after being taught C/C++/Java for so long. It takes less of
a leap for them to start using it than would Perl or Ruby.

The reason it took off is mod_php, and I am kind of dreaming about
something similar for Ruby. Like a mod_ruby2 where the interpreter
spaces are divided per request.

 

[Chad Perrin]

PHP actually is a full-fledged programming language.

Who ever said a templating language couldn't be a "programming language"?
So it's Turing-complete. Big deal. It's still a templating language.

I think one of the reasons it took off so well is that its syntax is
very C-like so many computer science grads feel right at home with it
after being taught C/C++/Java for so long. It takes less of a leap
for them to start using it than would Perl or Ruby.

I can only assume you haven't made the transition from C/C++ to Perl,
then. Perl is in many ways closer to C than PHP ever was.

The worst thing to me about PHP is its object implementation and
overuse of sigils.

Its object implementation sucks. No arguing that. It's basically just
a poor implementation of namespaces with delusions of grandeur.

My main problem with PHP sigils is that they don't actually do anything
useful. At least in Perl they serve some purposes in making certain
things easier to support with the interpreter and easier to parse by
human eye, by being different for different types of variables.

I can only assume that the rest of your post wasn't directed at me,
because I didn't see any connection between it and what I said.

 

[Lloyd Linklater]

There is a recent thread that covers speed. If you take ruby 1.9 and
compile it yourself, it runs about 5 or 6 times faster. That should
cover the speed aspect.

Also, the speed of the language is not necessarily all that critical as
long as it is more or less enough. You can always add hardware to cover
that aspect. After that it is the usefullness of the language that is
critical. There are always changes to be made. You really need a
language that can refactor and upgrade quickly and easily. So,
whichever language you can use to "git thar the firstest with the
mostest" (old saying) that is the one that they should use.

For the record, if your team is efficient and proficient with one
language and not the other, then go with what you know. Fighting a new
language could be a problem unless they can pick it up easily. Which
language is better is irrelevant if they cannot use it.

 

[John Joyce]

Who ever said a templating language couldn't be a "programming
language"?
So it's Turing-complete. Big deal. It's still a templating language.



I can only assume you haven't made the transition from C/C++ to Perl,
then. Perl is in many ways closer to C than PHP ever was.



Its object implementation sucks. No arguing that. It's basically
just
a poor implementation of namespaces with delusions of grandeur.

My main problem with PHP sigils is that they don't actually do
anything
useful. At least in Perl they serve some purposes in making certain
things easier to support with the interpreter and easier to parse by
human eye, by being different for different types of variables.

I can only assume that the rest of your post wasn't directed at me,
because I didn't see any connection between it and what I said.

nah most of what I type is only directed at my computer.

But yes, critically, the worst thing about PHP sigils is how useless
they are. They're just noise!

 

[Julian Tarkhanov]

But yes, critically, the worst thing about PHP sigils is how
useless they are. They're just noise!

Not exactly. Because PHP is so intimate with spitting text at people,
the sigils serve as a helper for string interpolation,
because you can make "a literal string with a $variable inside".

 

[Chad Perrin]

why not?
rails is easy to prototype but is painfully slow and hard to optimize, i
know caching is going to play huge role but optimized complex sql
queries are also important

My first thought was that it's a good idea because PHP is more painful to
use than Ruby and sometimes I have needs other than those for which Rails
is best suited.


PHP doesn't beat Rails at all, because "PHP" is not the same category of
tool as Rail. PHP may be Ruby in some respects, and Smarty may beat
Rails in some respects, but saying PHP beats Rails is like saying wood as
a boat-building material beats a given shipyard (which happens to make
all its ships out of steel).


Java isn't what I'd call a "systems language". That'd be something like
C instead. Java tends to be better than languages like PHP for
long-running webserver processes because of the optimizing VM, but that
doesn't make it a "systems language".

any examples? i know google is starting to use Ruby.

News to me. Last I checked, Steve Yegge actually ported Rails to Rhino
(JavaScript) because he wanted to use Rails but Google wouldn't adopt
Ruby (they have a strict policy about what languages their developers are
allowed to use at Google, as far as I'm aware).

 

[Richard Conroy]

I didn't "hear" anything, i performed tests and benchmarks, with few
ORMs (AR, Og, sequel) and pure postgres library and obviously pure hand
made SQL is best - of course i can use AR's find_by_sql, and sometimes i
do but it's slower then pure call.

Yeah, but slower for which end, the Database or the Rails pizza box?
Pursuing as-optimal-as-possible can introduce issues elsewhere. In general
Rails ActiveRecord just needs to be 'fast enough' - i.e. not be the bottleneck.

I'm planning to use ORM, and use pure sql for most frequent calls (like
checking for new messages, or new stories) that are made by ajax

Thats a bad design. The most frequent calls should be hitting your memcache.
If you have already rendered the new messages resource once, then it
should be in your memcache. Subsequent calls to the resource should
return the cached result, no Rails rendering or DB requests involved.

You cannot scale big without memcaching. It should be factored into your
design already.

 

[Richard Conroy]

PHP doesn't beat Rails at all, because "PHP" is not the same category of
tool as Rail. PHP may be Ruby in some respects, and Smarty may beat
Rails in some respects, but saying PHP beats Rails is like saying wood as
a boat-building material beats a given shipyard (which happens to make
all its ships out of steel).

Read my response again - the high availability of PHP developers suits
certain classes of customer whose web development is not continuous.
This will change of course (probably in the next year). For this purpose,
Rails and PHP are equivalent - tools for building dynamics web sites.

Java isn't what I'd call a "systems language".

A lot of people are. Especially on a web environment - its the language
that can do the heavy lifting (long-lived, CPU bound processes) on the
server.

News to me. Last I checked, Steve Yegge actually ported Rails to Rhino
(JavaScript) because he wanted to use Rails but Google wouldn't adopt
Ruby (they have a strict policy about what languages their developers are
allowed to use at Google, as far as I'm aware).

Yeah, thats the post I read too. Certainly the google idea factory contains
a lot of people who know languages outside of the google language policy;
but AFAIK, production code still has to be written in the big 4.

Amazon however are using increasing amounts of Ruby and dynamic languages
in production code. However Amazon is in a rather unique situation wrt to
code maintenance (Steve Yegge blogged on that one too, a while back).

 

[John Joyce]

Not exactly. Because PHP is so intimate with spitting text at
people, the sigils serve as a helper for string interpolation,
because you can make "a literal string with a $variable inside".

That's fine to use a sigil some opening-closing delimiters with
interpolated identifiers. But in any other case? Useless, unless you
want to identify it as a special type of object of variable. '$' is
way over used.

 

[M. Edward (Ed) Borasky]

Yeah, thats the post I read too. Certainly the google idea factory contains
a lot of people who know languages outside of the google language policy;
but AFAIK, production code still has to be written in the big 4.

Amazon however are using increasing amounts of Ruby and dynamic languages
in production code. However Amazon is in a rather unique situation wrt to
code maintenance (Steve Yegge blogged on that one too, a while back).

This thread has gone on so long that I've forgotten the original
*business* question that was posed. But I *do* remember that it *was* a
business question, and not a linguistic one. Therefore, I think that the
Google and Amazon experiences, both of large web enterprises that
started small(ish) are highly relevant.

As you point out, each business has different needs, as will the
original poster's. And in the end, those are what we need to be looking
at. So ...

1. I've forgotten exactly what Matz has said about Ruby in the corporate
world -- perhaps someone here (even Matz) can repeat that. But Rails
clearly *does* have a corporate presence. The last time I checked, there
were very few "pure open-source non-corporate" Rails projects around,
vs. a number of highly-publicized corporate ones.

2. The LAMP stack is a major force in web applications. I'm not quite
ready to say, "Nobody ever got fired for deploying an RHEL LAMP web
application", but I think you have to be pretty close to that.

So I think a home-grown non-Rails Ruby solution is a non-starter here
for a number of reasons. It's not "Ruby vs. PHP", it's "Rails vs. PHP".

 

[Richard Conroy]

This thread has gone on so long that I've forgotten the original
*business* question that was posed. But I *do* remember that it *was* a
business question, and not a linguistic one. Therefore, I think that the
Google and Amazon experiences, both of large web enterprises that
started small(ish) are highly relevant.

Well thats what has shaped my answers. In particular the OP wanted
to push his custom Ruby (non-Rails) solution over a custom PHP
solution on a customer.

The reasoning behind building another Ruby Web Framework from
scratch on the customers' dollars instead of using the already
excellent ones out there seemed a bit flawed to me. In which, case
a Warts-n-all PHP solution may have suited the customer better
(who according to the OP is not tech-savvy).

(Chad - this was the point I was getting at when I was saying
PHP beats Rails)

1. I've forgotten exactly what Matz has said about Ruby in the corporate
world -- perhaps someone here (even Matz) can repeat that. But Rails
clearly *does* have a corporate presence. The last time I checked, there
were very few "pure open-source non-corporate" Rails projects around,
vs. a number of highly-publicized corporate ones.

My Recollection: They (Matz & the Ruby Dev team) are not actively courting
the corporate world in the way .NET & Java did. They are out to make a
beautiful language, if the corporate world enjoys it too, well thats
good aswell;
but there will be no concessions.

DHH & Rails Dev isn't trying to court it either, but you make a leading edge
web technology with proven cost savings and the corporate world will follow.

2. The LAMP stack is a major force in web applications. I'm not quite
ready to say, "Nobody ever got fired for deploying an RHEL LAMP web
application", but I think you have to be pretty close to that.

The LAMP stack is an instance of 'The Pit of Success' - by following the
easy, well-known, route to implementation of one (even dogmatically),
your solution will probably Just Work with predictable amount of effort.

That previous statement generates a lot of warm fuzzies to corporate
stake holders.

So I think a home-grown non-Rails Ruby solution is a non-starter here
for a number of reasons. It's not "Ruby vs. PHP", it's "Rails vs. PHP".

And no disservice to the non-Rails Ruby frameworks out there. Certainly
pure-Mongrel handlers, Merb & thread-safe ORM sounds like a fun
implementation to me.

But be nice to your customers.

 

[Marcin Raczkowski]

Yeah, but slower for which end, the Database or the Rails pizza box?
Pursuing as-optimal-as-possible can introduce issues elsewhere. In general
Rails ActiveRecord just needs to be 'fast enough' - i.e. not be the bottleneck.

in my expirience when in my test (but based on real case) database DB
is taking 85% of request time i think it can be bottleneck don't you :]

Thats a bad design. The most frequent calls should be hitting your memcache.
If you have already rendered the new messages resource once, then it
should be in your memcache. Subsequent calls to the resource should
return the cached result, no Rails rendering or DB requests involved.

You cannot scale big without memcaching. It should be factored into your
design already.

Why are you treating me like an idiot ? seriously? im using memcached,
but in some cases i have to generate query based on parameters provided
by user, and each user have diffirent excluding conditions based on his
permision level, how you suggest i use memcached for that?

what if each request is unique and comes in random 2-20s intervals, how
you suggest i use memcached?

I'm not saying memcached is bad, i even advertised it as big part of my
project but what you said is like saying (using your pizza analogy) you
need tomato sauce on each pizza, you can't make good pizza without
tomato souce, use tomato souce becouse it's good, even if client have
alergy give him tomato souce becouse you can't make pizza without it

 

[Marcin Raczkowski]

Well, yes, it WAS buisenes questions, with spawned, lots of subthreads,
personal atacks, flamewars etc.

I, my boss, and few others in my company decided that ruby will be our
langue of choice (even my boss's 12y old is learning it) and we have
sound reasons behind it.

Rails vs. Other vs. Custom - Rails is great for prototyping, ultra fast,
easy and have other strong points BUT it have it's disadvantages,
"Second league" like Nitro / IOWA - are good - but lack
documentation/support
now we have custom frameworks based on mongrel handlers - merb and mine
- i borrowed lot's of ideas, and some code from merb - and if i ever get
it to work as i want I'm going to release it as open source, but reason
for using them is simple - they are fast and custom tailored - exactly
what i need, it sure takes some more time to make something work, but i
know it'll work as i want it to work and it'll work fast.
Ah... and they implementing one sounded like fun to me to ... and i did
it in my free time

 

[Chad Perrin]

Not exactly. Because PHP is so intimate with spitting text at people,
the sigils serve as a helper for string interpolation,
because you can make "a literal string with a $variable inside".

I'd say that PHP should have taken a hint from environment variables if
it wanted to use those sigils more effectively -- by not using them
except in certain cases where they are being interpolated. They're just
line noise *most of the time* in PHP.

 

[Rick DeNatale]

I'm jumping in late here, and I've only skimmed most of the replies,
so pardon me if I'm repeating anything already said:

why not?
rails is easy to prototype but is painfully slow and hard to optimize, i
know caching is going to play huge role but optimized complex sql
queries are also important

On the other hand, there are lots of folks working on optimizing
Rails, how many are working on optimizing your custom tailored
framework.

If you don't want to use Rails, then why not look at something which
already has somewhat of a community like merb?

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

Here I totally agree with you. In fact, I'd argue that Rails is a
better choice for a "seasonally" developed project than the average
PHP application.

Nicely written PHP code can be picked up quickly by a new developer,
but from what I've seen except for some large open-source php efforts
like mediawiki, there's a lot of not so nice PHP code out there. I've
tried a couple of times to take on maintenance of PHP apps and have
always had to turn down the gig.

On the other hand, Rails apps tend to be easy to pick up even "second
hand." Most follow the convention over configuration philosophy, so
they all tend to have similar structure. And the good ones tend to
have nice test suites which make it easier for the new guy to grok
what it's supposed to do.

So even though the population of Rails savvy programmers might be
smaller than the PHP community, there's a much higher probability that
any of then could pick up and existing Rails app than a random PHP
programmer could understand a random PHP application.

On the other hand, how many will understand your custom MVC framework?

Of course if you're looking for job security AFTER you get the gig....

 

[Chad Perrin]

Read my response again - the high availability of PHP developers suits
certain classes of customer whose web development is not continuous.
This will change of course (probably in the next year). For this purpose,
Rails and PHP are equivalent - tools for building dynamics web sites.

You're talking about which is more socially acceptable to a manager,
then, rather than which is the better tool for the job -- because that's
the *only* way in which the two are equivalent, as far as I can tell. In
any other sense, saying the two are equivalent in that they're tools for
building dynamic web sites would be like saying that a hammer and a
prefab house component factory are equivalent because they're tools for
constructing homes.

A lot of people are. Especially on a web environment - its the language
that can do the heavy lifting (long-lived, CPU bound processes) on the
server.

I know that some people call Java a "systems language", but in the (age
old) sense in which I'm familiar with the term "systems language", it
isn't.

Yeah, thats the post I read too. Certainly the google idea factory contains
a lot of people who know languages outside of the google language policy;
but AFAIK, production code still has to be written in the big 4.

Amazon however are using increasing amounts of Ruby and dynamic languages
in production code. However Amazon is in a rather unique situation wrt to
code maintenance (Steve Yegge blogged on that one too, a while back).

Amazon's hiring seems to focus more on Perl than any other single
language, actually -- and has for a long time. As such, while the amount
of dynamic language usage may actually be increasing, I think one might
better represent the situation by saying that Amazon has used dynamic
languages to a significant degree for a long time.

That's "long time" in Intarweb years, of course.

 

[Chad Perrin]

Well thats what has shaped my answers. In particular the OP wanted
to push his custom Ruby (non-Rails) solution over a custom PHP
solution on a customer.

The reasoning behind building another Ruby Web Framework from
scratch on the customers' dollars instead of using the already
excellent ones out there seemed a bit flawed to me. In which, case
a Warts-n-all PHP solution may have suited the customer better
(who according to the OP is not tech-savvy).

(Chad - this was the point I was getting at when I was saying
PHP beats Rails)

I don't think saying that PHP serves the customer better is such an open
and shut case. I also don't see how building a Ruby web framework from
scratch wastes customer dollars any more than building a PHP web
framework from scratch.

Based on what I've seen here, most of the arguments against doing what
the OP proposes are based on:

1. PHP is more popular, so getting more (on average, low quality)
programmers familiar with the technology is easier.

2. PHP is more popular, so migrating from one shared host to another is
easier (even though shared hosting probably isn't what's intended
here).

3. PHP is more popular, so managers are less likely to balk at it.

4. Rails already exists, so it's better to build a new framework than
to build a new framework. (One of those two is in PHP, the other in
Ruby.)

I'm just not buying any of that as technical reasons to choose PHP
instead of non-Rails Ruby.

The LAMP stack is an instance of 'The Pit of Success' - by following the
easy, well-known, route to implementation of one (even dogmatically),
your solution will probably Just Work with predictable amount of effort.

That previous statement generates a lot of warm fuzzies to corporate
stake holders.

. . which is a great reason to use LAMP if that's the only way you're
going to get the contract. It's not such a great reason if you're
looking for the best technologies to use for a given project.

And no disservice to the non-Rails Ruby frameworks out there. Certainly
pure-Mongrel handlers, Merb & thread-safe ORM sounds like a fun
implementation to me.

But be nice to your customers.

. . even if it means using what's best, rather than what's most
popular.