What are Ruby developers saying about PHP

[phpimpact]

Interesting post in the O'Reilly Blog.

I switched back to PHP after 2 years on Rails

Welcome back my friend

[33degrees]

He's confusing a bunch of issues, not least comparing a framework with a programming language.

[logic_earth]

One of the major downfalls of Ruby and Ruby on Rails. Is deploying it.
Unlike PHP you just cannot setup Apache with a simple few modules and settings and go. No its a lot more work.

[Czaries]

One of the major downfalls of Ruby and Ruby on Rails. Is deploying it.
Unlike PHP you just cannot setup Apache with a simple few modules and settings and go. No its a lot more work.

Wow. Hit the nail on the head there. This is the EXACT issue I ran into with my host on a current project I am helping on (my friend is a RoR fanatic... no comment). Rails is nice and beautiful for simple CRUD websites... until you try to take it live and put it into production. Mongel error, Gem error, gem incompatible with rails version... ARGH! I want my PHP bundled with the necessary modules like GD by default!

I read that article earlier today. It's not really the best, though the author does bring up a few interesting points. The main impression I was left with after reading that was that the author clearly made a very poor business decision and didn't do enough research or read enough documentation on Rails to get the job done properly. Clearly not the point he was trying to make. The good bit is that programming languages and frameworks are tools to reach the desired goal, nothing more. Just use whichever tool you prefer and whichever one helps you get the job done best.

Personally I don't care what the Rails fanatics say - until Ruby/Rails is as easy to use and deploy out in the real world as PHP is today, we won't have too much to worry about.

[33degrees]

One of the major downfalls of Ruby and Ruby on Rails. Is deploying it.
Unlike PHP you just cannot setup Apache with a simple few modules and settings and go. No its a lot more work.

That is definitely true, but it's a problem that people are actively working on, and there are several hosting companies out there that can take care of it for you (for a fee, of course). In any case, there are valid criticisms to be made regarding ruby and rails, but the linked article does not contain any; it's just a cautionary tale about doing a total rewrite of a working system in another language.

[BerislavLopac]

He's confusing a bunch of issues, not least comparing a framework with a programming language.

While you're generally right, you are mistaken about that last part. PHP is a language, agreed. But at the same time it is also a Web development framework.

It is like this:

Ruby on Rails is a Web development platform, written in Ruby and using Ruby syntax for development.
Django is a Web development platform, written in Python and using Python syntax for development.
ColdFusion is a Web development platform, written in Java and using custom syntax for development.
PHP is a Web development platform, written in C and using custom syntax (which we call PHP programming language) for development.

[Czaries]

Here, let me give that a try:

Symfony is a web development platform, written in PHP and using PHP syntax for development.
Zend Framework is a web development platform, written in PHP and using PHP syntax for development.
Code Igniter is a web development platform, written in PHP and using PHP syntax for development.
CakePHP is a web development platform, written in PHP and using PHP syntax for development.

I am not seeing a difference here...

[Dr Livingston]

> But at the same time it is also a Web development framework.



I read that article as well, and I got a laugh out of it. For some reason, I'm still laughing... Seriously though, Ruby on Rails, no matter what Jazz it may have is not ready for mainstream use.

I said that a few years ago at about the time the buzz began with Ruby on Rails and I still stand by that today. I've I'm not mistaken, this isn't the first instance that a Ruby on Rails developed web application has been moved to another platform (such as PHP for example) because of performance (and other) issues.

It can't scale for a reason. If you are looking for a reason, look at PHP. You'll learn something.

[phpimpact]

but the linked article does not contain any; it's just a cautionary tale about doing a total rewrite of a working system in another language.

Yes true. It's a funny article After 2 years, and having the best programmer in the world, the site is halfway done!? Then he switches back to PHP and writes his own framework... another one!! Mama mia :P

On the other hand, this happens a lot. Not only to developers, but to companies as well. Specially in marketing, advertising and media agencies, that are more trendy than techie.

[33degrees]

I've I'm not mistaken, this isn't the first instance that a Ruby on Rails developed web application has been moved to another platform (such as PHP for example) because of performance (and other) issues.

Except, as I said earlier, he has not given any concrete reasons why they couldn't do what they wanted to in RoR. He said nothing about performance, scaling, or any issues that actually have anything to do with Ruby or Rails specifically. Basically, all he says is that he was more comfortable in PHP, which isn't any sort of revelation.

[BerislavLopac]

Here, let me give that a try:

Symfony is a web development platform, written in PHP and using PHP syntax for development.
Zend Framework is a web development platform, written in PHP and using PHP syntax for development.
Code Igniter is a web development platform, written in PHP and using PHP syntax for development.
CakePHP is a web development platform, written in PHP and using PHP syntax for development.

I am not seeing a difference here...

That's because, unlike the platforms like Ruby on Rails and Django, PHP is a very low-level framework, with its scope extremely broad. You will agree that, to create a Web site, you need nothing more than plain old PHP, with no other framework on top of it.

Web development is, on its most basic level, extremely simple -- all you do is format and print some text. However, to interact with the HTTP protocol you need some library of functions which will do the hard work. PHP have all those capabilities -- from $_POST and similar arrays to a built-in templating systems -- which other languages need an extra framework layer for.

The PHP frameworks you describe don't give PHP any capabilities it doesn't already have -- they just make it easier and quicker for developers to write standard stuff like Web pages. Ruby on Rails does that as well -- but it also has to provide capabilities, like Web server integration, which the language doesn't include per se.

One note: Please understand that I'm in no way seeing PHP as being superior to either Ruby or Python or any other language -- I just think that things should be looked at from all points of view. Ideally, I'd love to have a PHP-like Web development environment, which easily integrates with Apache and other Web servers, but uses JavaScript syntax.

[BerislavLopac]

Except, as I said earlier, he has not given any concrete reasons why they couldn't do what they wanted to in RoR. He said nothing about performance, scaling, or any issues that actually have anything to do with Ruby or Rails specifically.

Earlier this year I had a site developed in RoR by an associate. The first thing I noticed was that it was extremely slow, and the second was that some modules kept crashing and the developer kept saying that he doesn't understand why, that his code is all perfect.

Now, granted, the developer was inexperienced with RoR, but we simply couldn't afford wasting time. So after a couple of months of waiting for things to improve we scrapped the whole RoR thing and I single-handedly rewrote the whole site in PHP5, literally in two days. Granted, I am probably a much better with PHP than he is with RoR (and Ruby), and I'm sure that with some more skilled developer things would run smoother -- but this just shows one of RoR's deficiencies, which is a lack of experienced developers.

[logic_earth]

I'll just say this PHP was designed for the web. Ruby was not.

[33degrees]

That's because, unlike the platforms like Ruby on Rails and Django, PHP is a very low-level framework, with its scope extremely broad. You will agree that, to create a Web site, you need nothing more than plain old PHP, with no other framework on top of it.

Web development is, on its most basic level, extremely simple -- all you do is format and print some text. However, to interact with the HTTP protocol you need some library of functions which will do the hard work. PHP have all those capabilities -- from $_POST and similar arrays to a built-in templating systems -- which other languages need an extra framework layer for.

You can write web pages in ruby without an extra framework layer too; the included CGI class offers all the interaction with the HTTP protocol needed, and mod_ruby with eruby allows you to drop in .rhtml (html with embedded ruby) files in your web directory, just like php. I believe python and perl also offer CGI functionality with their bundled libraries. The only advantage that PHP offers is that it automatically populates the super globals with that data; hardly enough to call php a framework.

[BerislavLopac]

The only advantage that PHP offers is that it automatically populates the super globals with that data

No, this isn't the only one. Don't forget the built-in templating, and in general PHP is designed with the Web in mind (the request-response paradigm).

[Dr Livingston]

> Ruby was not.

Neither was Python, but all the Python web based frameworks are doing okay for themselves. In the case of Ruby on Rails, it's not the language but for the most part it's, it's architecture that is the problem.

It just doesn't jell for web development. Simple as that really. Like I said earlier, this isn't the first case that has shown light on the issues. Putting an entire framework on top of those issues as is what Ruby on Rails is, is just asking for trouble in my view.

You could suppose that the framework is just that one layer of complexity too many?

[Dr Livingston]

> he has not given any concrete reasons why they couldn't do what they wanted to in RoR.

I had thought that the obvious was pointed out, but if that isn't the case, then I've pointed it out for you.

[33degrees]

> he has not given any concrete reasons why they couldn't do what they wanted to in RoR.

I had thought that the obvious was pointed out, but if that isn't the case, then I've pointed it out for you.

What, that RoR is slow? You've stated that, but you haven't provided any proof other than the anecdotal kind, and I've personally seen RoR sites that aren't slow at all. Besides, performance was not mentioned anywhere in the linked article.

[honeymonster]

Twitter is one of the heroes in the RoR space. They have managed to overcome the scalability and performance problems, but here is what one of the developers said:

It’s also worth mentioning that there shouldn’t be doubt in anybody’s
mind at this point that Ruby itself is slow. It’s great that people
are hard at work on faster implementations of the language, but right
now, it’s tough. If you’re looking to deploy a big web application
and you’re language-agnostic, realize that the same operation in Ruby
will take less time in Python. All of us working on Twitter are big
Ruby fans, but I think it’s worth being frank that this isn’t one of
those relativistic language issues. Ruby is slow.

Yes. Ruby is slow. Please don't fool yourself. Ruby is slow.

However, the way rails are set up, mongrels can cache constructed classes. That's something that PHP can't do. Using an opcode cache such as APC you can cache PHP's opcodes, but on every request PHP has to execute the opcodes which will construct the class. An opcode cache does not cache the class definition itself. That is a limitation by design because the class definition may indeed take on another meaning depending on what was executed before the class construction. As the complexity grows (number of classes used per page) the impact on a RoR application will be less than the impact on a PHP application.

In other words RoR scales better than PHP with page complexity. Where the break even point is, I have no idea.

[Dr Livingston]

> Please don't fool yourself.

I wasn't fooled, believe me. But getting to the point I have. Is Ruby on Rails going to be that much faster because of it's cache though?

I've never fancied the idea of the cache, a sort of poor mans excuse if you will; I'm not saying that a cache doesn't help, as in some cases, it can however there are overheads in that as well to maintain it.

Anyways, I don't believe that Ruby's cache constructed classes would make any difference, as at the end of the day, the issues are still there, regardless. PHPs performance can be enhanced true with APC (for example) but PHP is fast off the bat anyways, so ideally you could say that PHP is more or less capable anyway without APC.

Sorry, but I'm still not convinced of Ruby on Rails, and this is 2+ years on since the buzz began.

> Besides, performance was not mentioned anywhere in the linked article.

So are you saying that Ruby on Rails doesn't have performance issues? I would have though that, that would have been the first thing to spring to mind in regards that someone has dumped all over Ruby on Rails, for PHP as the next best alternative...

But the developer in question already knew that before he began to get stuck into Ruby on Rails, didn't he?

[honeymonster]

I've never fancied the idea of the cache, a sort of poor mans excuse if you will; I'm not saying that a cache doesn't help, as in some cases, it can however there are overheads in that as well to maintain it.

Well, when using cache infects the code with explicit cache manipulation, I sort of agree that you must carefully weigh pros and cons. The performance benefits have to be substantial in those cases.

But in the case of RoR, the class cache is on by default for the production environment, off for development environment. It really does not require any code effort or take up mindspace at all. You only need to consider it when deploying updates to a site, in which case you must restart the server or otherwise flush the cache.

[33degrees]

So are you saying that Ruby on Rails doesn't have performance issues? I would have though that, that would have been the first thing to spring to mind in regards that someone has dumped all over Ruby on Rails, for PHP as the next best alternative...

No, it's common knowledge that the ruby interpreter is slow, and that performance can be an issue. But that does not change the fact that his reasons for switching back to PHP have nothing to do with RoR itself. Replace the words ruby with java and everything he says would be equally true. Or indeed replace RoR with php and Zend Framework, and php with perl, and it would still be the same story. The article is useless as any kind of critique about ruby or rails.

He does mention "One little 2U LAMP server is serving up a ton of cdbaby.com traffic damn fast with hardly any load." but without any kind of statistics and relative comparisons, it's hardly a persuasive argument.

[samsm]

I think this sums up the author's point of view:

#6 - I LOVE SQL
Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables.
I was always fighting against Rails and its migrations hiding my beloved SQL from me.

I don't isolate that comment to mock it or praise it, it just points to a philosophy that is incompatible with Rails.

[Jasper Bekkers]

I've never fancied the idea of the cache, a sort of poor mans excuse if you will; I'm not saying that a cache doesn't help, as in some cases, it can however there are overheads in that as well to maintain it.

Yeah, it's just that, well, every performance related problem is solved using a cache. The L1 and L2 cache on your CPU exist because trips to RAM are expensive, you're HDD has a cache because it's slow, even your body caches frequent actions by storing them some place where you don't have to actively thing about what you're doing. One of the very concepts of programming, variables, can be seen as a cache of previous calculations.

The problem with caches is, that implementing a good cache management system is a though problem that requires some deep understanding of the system and it's data access patterns.

[phpimpact]

Ruby is another example of filling a tiny, short-term need, and then being a real problem in the longer term.