Should Wikipedia's software be rewritten in Ruby on Rails? Options Rating

[LamontStormstar]

Should Wikipedia's software be rewritten in Ruby on Rails? Discuss.

[Somey]

Personally, now that Delphi for PHP exists, I can't imagine why anyone would want to switch from PHP to Ruby on Rails, unless they were already skilled in it of course.

[LamontStormstar]

Personally, now that Delphi for PHP exists, I can't imagine why anyone would want to switch from PHP to Ruby on Rails, unless they were already skilled in it of course.

I once worked on Delphi back in the 1990s. I'd tried visual basic, then I tried Delphi. Delphi was only a little slower to develop in than Visual Basic and Delphi was more powerful and code was slower. I then tried C++ because a friend recommedned it, which was hard and slow to develop in, though code got even smaller and the program was faster. I later gave up on C++.

I'm not sure what Delphi for PHP is about. Delphi is a bit of a better language than PHP

Java would probably be even slower than PHP. Whenever I go to a website with a java applet, if it is really complex it slows my computer way down.

Server side Java is nothing like client-side java. The slowness you're experiencing is due to your browser launching a JVM inside the browser. Server side Java doesn't have this problem; the JVM is already running in the server and all you get is the same HTML you'd get from the PHP app -- it's just generated that much faster. A properly implemented Java webapp will run rings around a PHP app.

MediaWiki runs 25% faster just by running it within Quercus, which is pretty much just a PHP interpreter written in Java. A full reimplementation in Java would be 50% to 75% faster.

I doubt that a Ruby on Rails implementation would be that much faster as RoR is, like PHP, a fully interpreted language (although the odds are that the RoR interpreter is more efficient than PHP, as PHP's is just about the worst-performing interpreter there is in common use). Java is at least compiled to JVM code. The only way to get faster than that would be to go to a fully compiled language like C or C++.

Hmm... isn't the native PHP interpreter written in C++ or something low-level? If it's not, that's surprising.

[gomi]

Hmm... isn't the native PHP interpreter written in C++ or something low-level?

Yes, and in addition there has been a lot of work done to integrate PHP with Apache, the dominant web server out there. This ameliorates a good deal of the overhead of the interpretive nature of PHP, but not entirely. It is likely that what has been said above is true, which is native C/C++ CGI modules are faster than Java, which is in turn faster than PHP, which is in turn faster than Python, which is in turn faster than Ruby. But this, of course, obscures vast amounts of other complexity that depends on what it is you're trying to do. A large stream of poorly-designed SQL queries will use up vastly more time than any amount of user interface cruft you can imagine.

Recall here that Yahoo runs on a LAMPs engine (Linux, Apache, MySQL, PHP), and it seems to perform well under high levels of load.

The two useful ways of improving Wikipedia performance would be to optimize the database queries and structure, which (given the size of the existing dataset) is probably impossible, or to re-implement the core Wiki functions in C++. In fact, I'm doubtful that even the latter would help, as I suspect the site is database-bound.

On the larger topic, has anyone tried PHP/Cake and have a report to give?