The Ruby Conference concluded Sunday with Ezra Zygmuntowicz's talk on Mongrel -- entitled Building Custom Mongrel Handlers for Speed and Concurrency
-- and a discussion on Rubinius by Evan Phoenix.
To highlight the merits of their offerings they note a few philosophical issues with Ruby and Rails, respectively.Mongrel
, a fast HTTP library and server, hosts Ruby apps using HTTP instead of FastCGI or SCGI. The framework agnostic solution supports Ruby on Rails
Ezra passionately contends it is a common myth that Ruby is slow. In fact, he believes, Rails is slow and Ruby is quite sound.
To back up his point he points out that each recent new release of Rails has been 10-20 percent slower than the last. It is time for the "premature optimization" that, given the rapid maturity process of the programming framework and the increasing cumbersome feel to Rails, would not be quite so premature anymore.
Rails has also become more bloated with increased participatory interest by "too many people." His response to Rails' heftiness is an offering called Merb, a Mongrel+Erb mash-up that started out as a hack. Its benefits:
* No cgi.rg
* It's thread-safe (Ruby generally isn't)
* Rails-compatible REST routing
* Less Magic (too much Magic, he contends, is one of Rails' problems)
* It's what you end up with anyway if you keep writing custom Mongrel handlers
Nice logic on the last one. If everybody's already beating the path there, why not just cut to the chase? Check out
Mongrel at Rubyforge. Note that the best way to install it is via Gems. Then run a Ruby on Rails app. All the instructions are right on the website.
Evan Phoenix begins his Rubinius discussion with a series of philosophical positions.
The Rubinius mantra is "If it can be done on Ruby, it shouldn't be done in C." To obliquely highlight this point he later notes that programmers ultimately build for an end consumer, so keep things simple and easily scalable. This is something to keep in mind when engaging in web development.
In essence Rubinius is a project meant to create a Ruby implementation. Its virtual machine "shotgun" is based on Smalltalk-80 VM architecture. C extensions written for Ruby run easily under shotgun with a recompile.
Rubinius boasts the following:
* A new Ruby engine
* Bytecode virtual machine foundation
* Generational garbage collection. It merits noting in the JRuby discussion
that garbage collection in Ruby is an ongoing problem
It also covers five core sections: CPU, primitives, a compiler, object memory/garbage collection and a core library.
Evan adds that while every presenter in the conference has highlighted Ruby limitations to showcase their products, these limitations are not problems with Ruby itself. They're problems with the current interpreter, not the language. At present the interpreter doesn't provide a wide avenue for fixes, which comes off to some as problems with the language.
Evan humbly divulges that he is not a Java programmer. With a foundation in Ruby, however, he asserts an understanding of how Ruby may shine in projects where Java or JSP-based solutions would typically be the rule.
Finally, Evan takes pains to highlight that Rubinius is not vaporware, not a thesis project (meaning there's some serious heft behind it; it's not going anywhere at semester's end) and not finished. Input is always invited.
All object access in the VM is done through the write barrier, which maintains the set of mature objects that reference young ones. Also, objects aren't marked, making Rubinius uniquely fork friendly. For those in the know, Ruby is frustratingly not.
Catch up on what's new with Rubinius at Rubini.us
And that's just about everything that went down at Ruby central this year! Check out all the previous coverage:
* CMSWire Reports Live from the Ruby Conference!
* Ruby Conference: Tor Explores Ruby Tooling
* Ruby Conference: Ruby to Crown the JVM?
* Ruby Sunday: Scaling Twitter and Other Lessons from Mr. Cook