Ruby VS PHP

ruby-talk
21

Hi,

Also, you could note that with Ruby you can make non-Web applications,
which to my knowledge, you can't with PHP.

That's not true, of course you can build "non-web" apps with PHP [0] -
starting with simple scripts up to GTK bindings <http://gtk.php.net/&gt;
you have quite a lot of possibilities.

I think there's a lot of prejudice in that field. There are people
building high-traffic websites using PHP, and I think it scales at least
as good as "Ruby on Rails" (as you can use the same methods for
distributing your server load). There's also commercial support
available from Zend <http://www.zend.com/&gt;\.

And last but not least it's still much easier to find a web hoster who
supports PHP (with database bindings etc.) than to get support for Ruby
or even Rails. The latter is changing, though - but at least here in
Germany there's still a long way to go.

Regards,

Dominik.

[0] e.g. autocompletion and method reference for PHP in my editor
TextMate <http://macromates.com/&gt; is written as PHP scripts ...

···

Marcelo Paniagua <paniagua@pcmxl.com.mx> wrote:

22

I think there's a lot of prejudice in that field. There are people
building high-traffic websites using PHP, and I think it scales at least
as good as "Ruby on Rails" (as you can use the same methods for
distributing your server load). There's also commercial support
available from Zend <http://www.zend.com/&gt;\.

I agree with this. PHP scales quite well. In fact, in my experience, it did
better performance wise than RoR pre v.13. But the benefits that RoR brings
on development are worth the extra server resources IMHO :wink:

And last but not least it's still much easier to find a web hoster who

supports PHP (with database bindings etc.) than to get support for Ruby
or even Rails. The latter is changing, though - but at least here in
Germany there's still a long way to go.

Hopefully this is improving. We offer full RoR and Ruby support, and I know
some others are too. The thing is though, most web hosts have a "If Cpanel
doesn't have a checkbox for it we don't offer it" attitude. Partially this
is due to lack of experience on the part of alot of server admins of alot of
smaller web hosting companies.

···

On 7/16/05, Dominik Schlütter <schlu-do@gmx.net> wrote:

--

Robert W. Oliver II
CEO / President - OCS Solutions, Inc.

23

Hello Dominik,

That's not true, of course you can build "non-web" apps with PHP [0] -
starting with simple scripts up to GTK bindings <http://gtk.php.net/&gt;
you have quite a lot of possibilities.

I think the killer argument against this is that a php script never
frees memory, so it is not useable for many non web applications.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

24

> Also, you could note that with Ruby you can make non-Web
> applications, which to my knowledge, you can't with PHP.

That's not true, of course you can build "non-web" apps with PHP [0]
- starting with simple scripts up to GTK bindings
<http://gtk.php.net/&gt; you have quite a lot of possibilities.

I think there's a lot of prejudice in that field.

I think it's more a matter of "obsolete information" than "prejudice."
PHP did used to be solely for web applications. It got a makeover
a while back and is now endorsed as a general purpose application
tool... that just happens to be used almost exclusively for web
development.

And last but not least it's still much easier to find a web hoster who
supports PHP (with database bindings etc.) than to get support for
Ruby or even Rails.

That's dangerously like saying gasoline cars are better than electric or
hydrogen because it's easier to find a gas station. Still, it's an
important factor, making the argument almost true.

The latter is changing, though - but at least here in Germany there's
still a long way to go.

That's good news. Any progress away from PHP is good progress, IMNERHO.

:wink:

Tim Hammerquist

···

Dominik Schlütter <schlu-do@gmx.net> wrote:

Marcelo Paniagua <paniagua@pcmxl.com.mx> wrote:

--
$ rm -rf /mnt/windows

25

regarding webapps php is still the benchmark. why? change the script,
press reload - see the ...aehm error.. no .. changes.
i don't know why theres so much hassle with mod_ruby or fcgi. sooner
or later you will get problems with "in memory hanging classes" or
something. strange effects with "same-request-different-output". i
think it deals with the aggressive cleanup mod_php is doing between
requests so there are no problems on this side.
dry writing sourcecode for ruby/ ror is much more satisfying than php.
but testing or going productionmode with a ruby webapp - for me (with
php background) is quite hard...
how can providers sell virtual domains with mod_ruby, when you (their
customers) must be able to restart the webserver all the time?

regards,
  --robert

···

2005/7/16, Dominik Schlütter <schlu-do@gmx.net>:

I think there's a lot of prejudice in that field. There are people
building high-traffic websites using PHP, and I think it scales at least
as good as "Ruby on Rails" (as you can use the same methods for
distributing your server load). There's also commercial support
available from Zend <http://www.zend.com/&gt;\.

And last but not least it's still much easier to find a web hoster who
supports PHP (with database bindings etc.) than to get support for Ruby
or even Rails. The latter is changing, though - but at least here in
Germany there's still a long way to go.

26

seriously? __never__? if so - wow.

-a

···

On Sun, 17 Jul 2005, Lothar Scholz wrote:

Hello Dominik,

> That's not true, of course you can build "non-web" apps with PHP [0] -
> starting with simple scripts up to GTK bindings <http://gtk.php.net/&gt;
> you have quite a lot of possibilities.

I think the killer argument against this is that a php script never
frees memory, so it is not useable for many non web applications.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

27

Hi,

That's dangerously like saying gasoline cars are better than electric or
hydrogen because it's easier to find a gas station.

Hmm - not sure about your example, as electricity outlets are even
easier to find than gas stations. But I would take "better" as "better
suited for today's life" - and then your above statement is true.

Electric or hydrogen cars might be "better" from an engeneering and
environmental point of view. But if you see your car as a way of
transportation and not only as a technical masterpiece, it is more
important to be able to get your fuel whenever you need it[0], IMHO.

Or if you look at Ruby: I really like it for administrative scripts and
I'm toying with Rails on my PowerBook. But my current web hoster
(domainfactory) e.g. only supports Ruby, no Rails, no fast-cgi or
mod_ruby. I'd like to do one of my next projects as a Rails application,
but that means I'd have to find me a new hoster being able to handle
different admin-c (the customer) and billing address/accounts (me),
offering something to grow with my needs, provide good support and
possibly be inside the EU. All these things are much easier to find, if
you only look for PHP - that's what I wanted to say with my statement.

Regards,

Dominik.

[0] And I need it quite often as I'm driving a 30 year old Citroen AK400
with a gas tank of about 25l ... :-).

···

Tim Hammerquist <tim@vegeta.ath.cx> wrote:

28

While this may have been true in the past, I don't believe this is current behavior. Getting FastCGI + PHP working has been discussed several times on the FastCGI developers mailing list. If PHP never frees memory, it would be completely unsuitable for use with FastCGI.

···

On 16 Jul 2005, at 14:04, Lothar Scholz wrote:

Hello Dominik,

> That's not true, of course you can build "non-web" apps with PHP [0] -
> starting with simple scripts up to GTK bindings <http://gtk.php.net/&gt;
> you have quite a lot of possibilities.

I think the killer argument against this is that a php script never
frees memory, so it is not useable for many non web applications.

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

29

I agree. I find dispatch.cgi may be slower but it's way more
predictable than dispatch.fcgi.

···

On 7/18/05, Robert Wagner <robbie.wilhelm@gmail.com> wrote:

regarding webapps php is still the benchmark. why? change the script,
press reload - see the ...aehm error.. no .. changes.

--
Greg Donald
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/

30

I let tests do the driving. I don't like the whole switch, reload, wait, verify, tweak, repeat cycle, it doesn't give rapid feedback.

Tests are much more pleasant to work with. They give rapid feedback and allow you to make sure you don't break stuff that used to work (provided your coverage is good enough).

···

On 18 Jul 2005, at 09:52, Robert Wagner wrote:

2005/7/16, Dominik Schlütter <schlu-do@gmx.net>:

regarding webapps php is still the benchmark. why? change the script,
press reload - see the ...aehm error.. no .. changes.
i don't know why theres so much hassle with mod_ruby or fcgi. sooner
or later you will get problems with "in memory hanging classes" or
something. strange effects with "same-request-different-output". i
think it deals with the aggressive cleanup mod_php is doing between
requests so there are no problems on this side.
dry writing sourcecode for ruby/ ror is much more satisfying than php.
but testing or going productionmode with a ruby webapp - for me (with
php background) is quite hard...
how can providers sell virtual domains with mod_ruby, when you (their
customers) must be able to restart the webserver all the time?

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

31

Hello Robert,

how can providers sell virtual domains with mod_ruby, when you (their
customers) must be able to restart the webserver all the time?

They expect that you never to development on the webserver (and they
did not configure it very well). It's still impossible to use mod_ruby
in a shared simple apache environment, but with FCGI you should never
need to restart apache.

If we want a mod_php like environment someone has to patch the ruby
interpreter so that multiple instances can be run by multiple
independent threads without any conflicts. Something that is very hard to do.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

32

> That's dangerously like saying gasoline cars are better than
> electric or hydrogen because it's easier to find a gas station.

Hmm - not sure about your example, as electricity outlets are even
easier to find than gas stations. But I would take "better" as "better
suited for today's life" - and then your above statement is true.

Oh, I have plenty of outlets in my house. But the 100ft extension cord
I'd need to charge my car from my upstairs apartment is an unattractive
solution.

Or if you look at Ruby: I really like it for administrative scripts

I still prefer perl for admin scripts, simply because it's closer to the
shell/OS environment. It's still significantly less elegant than ruby,
but closer to what I need. But about anything I do that requires user
interaction, console/xterm included, I like ruby.

and I'm toying with Rails on my PowerBook.

I'm about to take a closer look at Rails, also on my powerbook, in fact.
It's taken me a while to get around to it, as my web development has
slowed significantly in the past few years. I don't do it
professionally anymore.

All these things are much easier to find, if you only look for PHP
- that's what I wanted to say with my statement.

I understood, and I agree.

Did I mention my car still uses gasoline? Idealism is great in an ideal
world. In the real one, compromises must be made. :slight_smile:

Tim Hammerquist

···

Dominik Schlütter <schlu-do@gmx.net> wrote:

Tim Hammerquist <tim@vegeta.ath.cx> wrote:

--
I shall never go back now that I have tasted of sweet, *sweet* invincibility.
It tastes like varnish. Not many people know that.
    -- Fighter, 8-Bit Theater <http://nuklearpower.com/&gt;

33

There is a simple workaround.

Everyone gets their own Apache server running on a specific port. There is
then a server running on port 80 that proxies requests to the private
servers.

So they can do anything that they want in their own environment.

Once upon a time I ran a corporate development network like this. Each
developer had his own sandbox, but it was all on a shared server and the
server on port 80 proxied everything. Worked great.

Kirk Haines

···

On Monday 18 July 2005 2:55 pm, Lothar Scholz wrote:

Hello Robert,

> how can providers sell virtual domains with mod_ruby, when you (their
> customers) must be able to restart the webserver all the time?

They expect that you never to development on the webserver (and they
did not configure it very well). It's still impossible to use mod_ruby
in a shared simple apache environment, but with FCGI you should never
need to restart apache.

34

that would be very cool. kinda
--enable-stupid-webapp
configure option. i'd love it.

-robert

···

2005/7/18, Lothar Scholz <mailinglists@scriptolutions.com>:

If we want a mod_php like environment someone has to patch the ruby
interpreter so that multiple instances can be run by multiple
independent threads without any conflicts. Something that is very hard to do.

35

Kirk,

This is a great idea. It seems you'd have a headache on the front end with
the Apache proxy server, but some careful management of that might prove
helpful.

My company provides mod_ruby and mod_fastcgi, but we do recommend people
develop on their machines, or with fcgi off. Turning fcgi off in Rails v13+
isn't so bad, as they've really speed up the core.

We're working a script to kill off processes that are in their name, but its
not yet done, because even though you can say "Don't develop on this
machine, or don't have fcgi on if you do so", people still will from time to
time :slight_smile:

···

On 7/18/05, Kirk Haines <khaines@enigo.com> wrote:

There is a simple workaround.

Everyone gets their own Apache server running on a specific port. There is
then a server running on port 80 that proxies requests to the private
servers.

So they can do anything that they want in their own environment.

Once upon a time I ran a corporate development network like this. Each
developer had his own sandbox, but it was all on a shared server and the
server on port 80 proxied everything. Worked great.

Kirk Haines

--
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.

Ruby / Ruby on Rails Discussion at http://www.rubyforums.com/

36

I say a lot of bad things about Apache2, but the proxy support is very easy to
use. Especially in a corporate environment where employees aren't turning
over rapidly, it's no problem. It's just like name based virtual hosting,
but all of the requests for the virtual host are then just proxied out to the
developer's server.

It's not a management headache at all.

The biggest management headache actually comes from developers who know just
enough to really mess up their development server's configuration, but not
enough to fix it, in my experience. Fortunately, most people deemed
employable are capable of learning, so this is a problem that can mostly be
educated away. :wink:

Kirk Haines

···

On Monday 18 July 2005 3:18 pm, Robert Oliver wrote:

This is a great idea. It seems you'd have a headache on the front end with
the Apache proxy server, but some careful management of that might prove
helpful.

37

As you said though, in the corporate environment, you can lay down more
ground rules and hopefully prevent some mess that could ensue with virtual
hosting in this manner :slight_smile:

However, either way, keeping regular, frequent backups of all the
apache2.conf's seems to be in order :wink: I could see someone turning into a
full time Apache administrator, solving a ton of little config issues.

···

On 7/18/05, Kirk Haines <khaines@enigo.com> wrote:

It's not a management headache at all.

The biggest management headache actually comes from developers who know
just
enough to really mess up their development server's configuration, but not
enough to fix it, in my experience. Fortunately, most people deemed
employable are capable of learning, so this is a problem that can mostly
be
educated away. :wink:

Kirk Haines

--
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.

Ruby / Ruby on Rails Discussion at http://www.rubyforums.com/

38

I run something similar except the apache up front proxies to lighttpd instances for each app or developer. Much less overhead than running many apaches :wink:
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
ezra@yakima-herald.com

···

On Jul 18, 2005, at 2:42 PM, Robert Oliver wrote:

On 7/18/05, Kirk Haines <khaines@enigo.com> wrote:

It's not a management headache at all.

The biggest management headache actually comes from developers who know
just
enough to really mess up their development server's configuration, but not
enough to fix it, in my experience. Fortunately, most people deemed
employable are capable of learning, so this is a problem that can mostly
be
educated away. :wink:

Kirk Haines

As you said though, in the corporate environment, you can lay down more
ground rules and hopefully prevent some mess that could ensue with virtual
hosting in this manner :slight_smile:

However, either way, keeping regular, frequent backups of all the
apache2.conf's seems to be in order :wink: I could see someone turning into a
full time Apache administrator, solving a ton of little config issues.

--
Robert W. Oliver II
CEO / President - OCS Solutions, Inc.
http://www.ocssolutions.com/
Ruby / Ruby on Rails Discussion at http://www.rubyforums.com/