Ruby vs. PHP

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 but several database
intensive features as well), and we think it will hopefully reach a
stage where scalability is going to become important.

Hence I wanted some idea abt speed…

I checked several benchmarks online between PHP, Python and Ruby, and
found that Python is a strong winner here, with PHP and Ruby about
distant second. However with Ruby 2.0, I read that it will use a
bytecode compiler YARV, which will make it significantly faster than its
current implementation Ruby 1.8… ?

My question:

  1. When can I reasonably expect a stable Ruby 2.0 release…
  2. Are there any benchmarks as to how will it compare to PHP and Python
    in run speed?

-Gaurang.

Gaurang Khetan wrote:

I checked several benchmarks online between PHP, Python and Ruby, and
found that Python is a strong winner here, with PHP and Ruby about
distant second. However with Ruby 2.0, I read that it will use a
bytecode compiler YARV, which will make it significantly faster than its
current implementation Ruby 1.8… ?

My question:

  1. When can I reasonably expect a stable Ruby 2.0 release…
    december
  2. Are there any benchmarks as to how will it compare to PHP and Python
    in run speed?
    there are few benchmarks, but it’s really hard to compare two langues as
    i found out ^^

. PHP is a
templating language.
PHP actually is a full-fledged programming 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.

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

Regarding the sigils and syntax, Ruby shows that if you have an
identifier that is not already used in some other capacity, then it
is enough to say it is a variable or object or a function that takes
no arguments. A function is generally obviously a function, if it
takes no arguments then it doesn’t need parentheses ! If it is
method it will be appended to an object’s identifier. This is the
core of Ruby’s gracefulness. Why should we have to type more than we
need to?

That said, there is something to be said for explicitness in
programming. If it’s necessary and appropriate it is good.
PHP as a language is pretty explicit most of the time, but to the
point of being arguably less legible. But many programmers are overly
accustomed to bending over backwards for code that is less legible (C/
C++ in many cases) or abusively explicit (Java) to the point of
redundancy.

But in the end, none of this matters, it is up to you to try a
language and see if you like it, see if it works for what you need.
You’re not likely going to write an OS in Ruby, but you could write a
DSL that might make that easier to do. You’re also not likely going
to do server side scripting in COBOL, but you probably could do it
somehow if you really wanted to, and you’d be able to connect to some
legacy systems older than you.

Gaurang Khetan wrote:

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

On Oct 1, 2007, at 4:27 PM, Lionel B. wrote:

but several database

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.

On 1-okt-2007, at 23:08, John J. wrote:

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.

On Tue, Oct 02, 2007 at 06:08:38AM +0900, John J. wrote:

. PHP is a
templating language.
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.

On 1-okt-2007, at 12:51, Marcin R. wrote:

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 :slight_smile:

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/

On Oct 1, 2007, at 10:01 PM, Chad P. wrote:

The worst thing to me about PHP is its object implementation and
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!

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.

On 2-okt-2007, at 5:27, John J. wrote:

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”.

On Tue, Oct 02, 2007 at 12:59:36AM +0900, Marcin R. wrote:

Why is this a good idea?

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.

investor was quite impresed with speed of development but of course
there’s trouble in paradise … he hired a consultant :confused: - this guy AFAIK
did lot’s of work but only in PHP and he is trying to convince investor
PHP is way to go.

PHP beats Rails in certain aspects; for instance if development of the
site is seasonal in nature, as opposed to continuous, the customer
is likely to be hiring as they need. The large availability of PHP
developers plays in its favour.

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).

All of these stacks are glued together with languages that are at least an
order
of magnitude slower than Systems languages like Java.

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”.

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.

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).

On 10/2/07, Chad P. [email protected] wrote:

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.

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).

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).

On 10/1/07, Marcin R. [email protected] wrote:

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.

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.

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.

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.

On Oct 2, 2007, at 1:19 AM, Julian T. wrote:


Julian ‘Julik’ Tarkhanov
please send all personal mail to
me at julik.nl

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.

Richard C. wrote:

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 R. solution is a non-starter here
for a number of reasons. It’s not “Ruby vs. PHP”, it’s “Rails vs. PHP”.

On 10/2/07, M. Edward (Ed) Borasky [email protected] wrote:

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.

  1. 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 R. 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 R. frameworks out there. Certainly
pure-Mongrel handlers, Merb & thread-safe ORM sounds like a fun
implementation to me.

But be nice to your customers.

Richard C. wrote:

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 :]

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

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 :slight_smile:

On Tue, Oct 02, 2007 at 03:19:20PM +0900, Julian T. wrote:

On 2-okt-2007, at 5:27, John J. wrote:

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”.

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.