Home > General Development > Rolling with Ruby on Rails by Curt HibbsRolling with Ruby on Rails by Curt Hibbs Eugenia Loli 2005-01-21 General Development 22 CommentsThe Ruby community is abuzz about Rails, a web application framework that makes database-backed apps dead simple. What’s the fuss? Is it worth the hype? Curt Hibbs shows off Rails, building a simple application that even non-Rubyists can follow.About The Author Eugenia LoliEx-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.Follow me on Twitter @EugeniaLoli 22 Comments 2005-01-21 7:11 pm Anyone who has used both have any opinions on Python vs Ruby? I will admit that I have not used Ruby, but I like what I hear. 2005-01-21 7:12 pm Rails proves:– that once a framework is in place, the languages plays a second role.– that Ruby is a very nice base for such frameworks. 2005-01-21 7:18 pm Jason, lots and lots of folks use Ruby and lots and lots of folks use Python, so both can do the job just fine. What differentiates them is too objective and too subjective at the same time, for they are similar and different at the same time. They are similar when compared to other less dynamic languages, they are very different when one is compared to the other. There are links that cover the comparison, but I don’t have anyone handy. 2005-01-21 7:31 pm I think you’ll be hard pressed to find a better language for web development than PHP5.The problem with both Python and Ruby is that they are interpreted languages, which adds substantial overhead to their execution.JSP goes exactly the opposite way, bytecode compiled but with ridiculous complexity which adds additional overhead. JSP works best on massively multiprocessor machines with VM pooling, and preferably with a low-overhead HTTP connector like Apache Coyote.PHP5 is the best of both worlds. It’s bytecode compiled, and furthermore with an accelerating cache like eAccelerator (http://eaccelerator.sf.net/) or Zend Accelerator, the compiled bytecode can be cached for future reuse. It implements a full and proper object model with inheritance and exceptions just like Java, Python, and Ruby.Best of all, it’s pro-actively oriented towards web development, unlike Java, Python, and Ruby which all aim to be general purpose languages. While PHP is rich enough to be a general purpose language as well, it will always remain foremost a web development language.We’ve seen JSP sites with considerable performance issues such as Friendster dump its complexity for PHP.I think we’ll continue to see web development with Python and Ruby but I just don’t see either ever garnering considerable marketshare compared to ASP(.NET), JSP, and PHP… 2005-01-21 7:42 pm You know that PHP does not lend its success to OO programming and OO frameworks.So PHP5 is pretty much like PHP4 to 99% of its userbase.You cite a couple of external tools that add complexity to the usual PHP programming. It’s like that with PHP5 that’s OO and about 5 to 10 external tools you can do great things. Or, you could use Rails and be done with the job already.FastCGI is used in Rails so much of the reloading of scripts/programs does not need to happen. Rails is about 7 months old. Give it 2 years and lets see its userbase and applicability grow. It has a nice O/R mapper for the OO fans. It has separation of responsibilities for the MVC fans. It is more practical than almost all the other frameworks. It has WEBrick and CGI for fast development and FastCGI for performance in production. Etc.Give it a try and see it for yourself. 🙂 2005-01-21 7:54 pm python is bytecoded too. And obviously being bytecoded does not relate in any way with efficiency.If you go hunt some dumb benchmark on internet (remember: lies, damn lies, benchmarks) you’ll discover that php is the worst performer of all the other scripting languages, even if it provides a much less dynamic environment. Especially when doing OO stuff. And you are writing modular good OO stuff, don’t you?Caching is handled by all python and ruby (and perl and tcl and whatever) decent frameworks, so that is a no brainer.IIRC Rails itself has caching options for relational database, distributed remote objects caches, file system and memcached, at various leveles of granularity.Imho, the only good reason to use php is “I’m stuck with this <host|legacy application>”. 2005-01-21 9:11 pm I’m developing a major (major as in size, not as in very-well known yet ) open source project with php and I’ve spent countless hours designing the data access layer… When I saw what you can do with Ruby on Rails, where 2 lines is enough to do what in php+adodb takes quite few more (develop the objects, create the db connections, add the fields to the class, etc) I thought I had just seen heaven.I mean, look at this: http://www.onlamp.com/onlamp/2005/01/20/graphics/recipe-model2.gif — this is all the code you need to encapsulate your database access (of course this is the simplest version but it’s enough functional)There are other cool things that you cannot do in php but you that can do in other languages such as python. Take a look at python’s xmlrpclib (http://www.python.org/doc/current/lib/xmlrpc-client-example.html), where the method examples.getStateName is not a real method that exists in the ServerProxy class but instead, it exists in the xmlrpc server (think of dynamic rpc calls without the need to pregenerate stub methods)So the point is, php is not the end-all be-all for web development. In fact, after seeing Ruby on Rails I’m starting to think that php might not even my first choice anymore… 2005-01-21 9:28 pm I think language wars are silly. Seriously, learn as many as you can. Don’t just stop at one language, be it c++, java, c#, python, ruby, perl,.. They can all learn you stuff as a programmer. Both the really cool stuff in a language, but also through making mistakes that are easy to make in a certain language.Another language is easy to learn anyway if you already know one. 2005-01-21 9:43 pm I work for a living on PHP4 + PHP5. I’ve been doing it for some years now. I even build my own framework with a data access layer and a bunch of PEAR classes to help. But I have never, ever seen anything as simple and elegant as Ruby on Rilas and it’s Active Record layer. The closest thing in PHP5 is Creaole and, although it’s very nice, it’s so far away in simplicity and functionality from Rails that it’s not even funny. I’m all about performance but I am a firm believer that the performance of the developer is more important than the server performance in many ways.Anyway, do yourself a favor. Open your mind for 30 minutes. Take the Todo list tutorial or follow the article’s instructions and you’ll see how simple, powerful and elegant Ruby on Rails. It made web development fun for me again and that’s no easy feat. 2005-01-21 11:07 pm scripts.First 3 pages are about installing stuff.While I think ruby is “neat”. You can make a lot of applications frameworks look cool at first glance when you have a couple of code generation scripts on hand. One couple make struts, webwork, spring etc look cool with similiar scripts that produce controller code and edit screens. 2005-01-21 11:15 pm You cite a couple of external tools that add complexity to the usual PHP programming. It’s like that with PHP5 that’s OO and about 5 to 10 external tools you can do great things. Or, you could use Rails and be done with the job already.Don’t get me wrong, Ruby on Rails is immensely impressive from solely a programmer’s point of view. But that won’t change the fact that Ruby is inherently slow.The tool I cited was a performance enhancing cache. Since Ruby is interpreted, no such tool for Ruby can exist.python is bytecoded too.My mistake.And obviously being bytecoded does not relate in any way with efficiency.Wrong. Without bytecode the original source must be scanned and parsed with each invocation. Furthermore, it’s substantially easier to optimize a bytecode interpreter than it is a textual language interpreter.The free (as in it doesn’t cost money) Zend Optimizer is able to perform high level optimizations on PHP bytecode. eAccelerator (free as in GPL) or Zend Accelerator can then cache that compiled and optimized bytecode. For any subsequent invocations of a given script, the pre-compiled, pre-optimized bytecode is loaded in lieu of rescanning/parsing the original textual code.[quote]If you go hunt some dumb benchmark on internet (remember: lies, damn lies, benchmarks) you’ll discover that php is the worst performer of all the other scripting languages[/quote]Hmm, here’s what I found, PHP outperforming JSP and ASP:http://www.linuxdocs.org/HOWTOs/PHP-HOWTO-13.htmlI’m unable to find performance comparisons of PHP to Python and Ruby as a web application language. Care to back up your statement with a source? Preferentially one that isn’t a meaningless latency microbenchmark and demonstrates the effectiveness of Zope or mod_perl or Rails over PHP? Also, be sure to compare to PHP5 with the Zend Engine 2, eAccelerator, and Zend Optimizer.[quote]Caching is handled by all python and ruby (and perl and tcl and whatever) decent frameworks[/quote]What are you caching with ruby if it’s interpreted? And for the others, source please?[quote]Anyway, do yourself a favor. Open your mind for 30 minutes. Take the Todo list tutorial or follow the article’s instructions and you’ll see how simple, powerful and elegant Ruby on Rails. It made web development fun for me again and that’s no easy feat.[/quote]Again, it looks wonderful from solely a programmer’s perspective, but abstractions like this are only great as long as they don’t leak, and frankly, Ruby does. Ruby can’t scale until Ruby gets a good bytecode engine or Cardinal, the project to write a Parrot plugin for Ruby, is completed.If scalability isn’t a concern, more power to you, but from an end user perspective I get easily frustrated with dynamic web pages that crumple under load. 2005-01-21 11:41 pm Will be the fastest Ruby Virtual Machine available. The initial benchmarks are very impressive.See:http://www.atdot.net/yarv/bench_20041206.txtSo never say never. 🙂Ruby in a year or so could get its version 2.0 with a very fast virtual machine, and what kills already, could become somewhat mainstream. 2005-01-22 12:03 am How about schema evolution, indexing, dealing with added fields, deleted fields, changed fields, relationships between tables, etc. Is looking at a schema and making a CRUD app that big a deal? I don’t think so. For example, what is their paging algorithm if there are 100000 rows. The stuff i saw was a joke. 2005-01-22 12:19 am Most of the stuff is handled automagically. Of course that some tweaking here and there may be necessary, but the community is open to ideas and the development of Rails is heating up for the 1.0 release. Whatever is needed may be added for the 1.0 release.Join #rubyonrails at irc.freenode.net and get heard. 2005-01-22 12:35 am Python, Ruby and PHP are interpreted, this means that they don’t run native machine code but bytecode. PHP can be easily optimized because it is much closer to c than to a very high level language like Ruby or Python. I never used Ruby (I really don’t like the sintax, but maybe some day, this rail system seems impressive) but I can almost assure you that it transforms the source files to bytecode prior to execution.Just some more info, some day python will be faster than C, just look at http://codespeak.net/pypy/. 2005-01-22 1:02 am >> Caching is handled by all python and ruby (and perl and tcl and whatever) decent frameworks> What are you caching with ruby if it’s interpreted? And for the others, source please?Oh, this really shows PHPer’s mental model, that is, CGI-like model: run script once and be done with it. They have no place for long-running process.Ruby and Python process can be started once and run for a long time, and can communicate with web server (like mod_python), or be a web server by itself (like Zope). Do you even know what FastCGI is?Of course being bytecoded or not doesn’t mean anything to caching in these cases. All needed codes reside in the memory so don’t need to be parsed over and over. 2005-01-22 1:12 am Another note: Python was compiled to bytecodes from its very beginning. At least from Python 1.5 (released 1999).Get the fact right. 2005-01-22 4:00 am Oh, this really shows PHPer’s mental model, that is, CGI-like model: run script once and be done with it. They have no place for long-running process.Agreed. PHP should be more accurately called “page-oriented” instead of “web-oriented”.I do program in PHP since 1999 (Perl since 1997, Python in 2000-2001, and Ruby since 2001). And I really don’t care if PHP is “compiled” or “much faster” or “web oriented” compared to Perl/Ruby. I still prefer Perl/Ruby over PHP any day. I can produce results as fast as (or sometimes faster) in those languages, while still *enjoying* doing them.There are many things with PHP, technical and non-technical, that really put me off. I’m not too impressed with PHP5 either.In short, pick your cup of tea. PHP isn’t mine. Unfortunately, from time to time I have to code in PHP… PHP is becoming like Windows/MS Office to me. You hate it, but you can’t totally avoid it. 2005-01-22 10:14 am I said that bytecode does not relate to efficiency in any way. Sorry for being inexact. What I should eave said is “being bytecoded does not guarantee you fastness”. The problem of “recompiling” is obviously non existing, since the AST is hold in memory, just like bytecode is hold in memory. I mean, if you don’t use just cgi. But if you’re talking about simple CGIs I don’t even understand how we ca talk about performace Then, are you aware that performing bytecode optimization does not make the Zend engine faster?The zend engine is an hack, (remember that their parser has ~800 conflicts and 6 unused terminals, it works by P.F.M)then, are you aware that thos “howto” does not have any source of the information linked?Then, how does “being a web language” makes a difference? Since given fastcgi you have great performance with almost any language, and php is slower than others. Look out for scutigena, and the various shootout.You’re really asking what I’m caching? You do really don’t have a clue ? I believe you’re faking ignorance You do cache database queries. You do cache pages and page fragments. You obviously do cache the AST and the bytecode (but this is done by fcgi or mod_whatever).For rails (but I bet it is the same for webware or maypole or whatever) you even have the chance to have distributed caches. It’s not something to hunt, just look in the projects’ documentation:http://ap.rubyonrails.com/classes/ActionController/Caching.htmlMaybe rails won’t scale, but this in no way relates to bytecode. 2005-01-22 11:19 am “Sounds like what you’re trying to say in a round about way is that they’re both the same shit, but different color. Am I getting that right? Not trying to say that they’re crappy, but it’s just how the saying goes. You know what I mean?”They are dynamic s-its. The other languages are static sh-ts, or less dynamic shi-s. Whatever. The problem is not about colors. Both have all the rainbow colors that you may ever want. I wouldn’t be so sure about what is sh-t (crappy) or not. 2005-01-22 4:07 pm I can tell you for sure that the official ruby interpreter does not compile to byte code. The source is available, and the machine itself is actually very simple and easy to follow. Grab it yourself and have a look; there’s no bytecode going on there. I can’t say the same for the optimized server versions of ruby, but I’m betting that they use libruby, which is basically the entirety of the ruby program. 2005-01-23 1:46 am Ruby does not do ‘textual interpretation’ — the interpreter evaluates ASTs produced by the parser and it is as fast as any bytecode interpreter. Maybe you should get your facts straight before posting idiocy on forums.