Meeting notes: August 4, 2009 -- Rubinius, MagLev, and non-relational data stores

Skip to first unread message

Igal Koshevoy

Aug 11, 2009, 4:32:13 PM8/11/09
We had a good meeting at the Robert Half Technology conference room in the KOIN Tower, they provide technical recruiting and placement services:


1. Brian Ford gave an update on Rubinus <>, a Ruby implementation written mostly in Ruby
  • Brian recently gave a presentation "Rubinius 1.0: The Ruby VM That Could", PDF slides:
  • Rubinus team is planning to release a 1.0 release candidate in the next few months. Want to improve its compatibility (e.g., your custom Rails apps), and provide parity with MRI 1.8.6. on UNIX and Mac. You can learn more about their roadmap at <>.
  • Much recent work has gone into improving performance. The JIT (Just In Time) compiler and inlining system are able to compile Ruby code so that once compiled it's almost as fast as MRI running C code. Unlike MRI which only gets this kind of performance boost in C code, Rubinius can get similar performance in arbitrary Ruby code that's being repeatedly executed.
  • How you can help: Write specs, test code, file issues.

2. Brian Ford talked about Engine Yard <>, they're currently supporting:
  • Rubinius
  • RubySpec, an executable specification for Ruby implementors
  • JRuby, a Ruby implementation on the Java Virtual Machine
  • MRI 1.8.6, taking over maintenance from Matz's team

3. Monty Williams of GemStone <> spoke about MagLev <>, a Ruby implementation built on top of their Smalltalk environment and persistence layer.

4. Igal Koshevoy spoke about non-relational databases: MongoDB, Tokyo Tyrant, CouchDB
  • Overview:
    • Relational databases are still a great choice for general purpose applications and sites where you have only a few database servers.
    • Non-relational databases have proven their worth for huge sites, but may not be worth using instead of a relational database unless you're trying to do something special, like solve a scaling problem.
    • Making proper use of non-relational databases may require heavy denormalization and very different approaches than are "right" for relational databases.
    • MongoDB is well-rounded with good performance and excellent features, including many you'd expect to see in a relational database.
    • Tokyo Tyrant is a very fast data store with fewer features. Since my presentation, I've found that it's possible to add multiple indexes and these make queries fast, and that replication is built in and I've managed to make it work -- I've updated my code and slides.
    • CouchDB is the most sophisticated and promising, but its abysmal benchmark performance was magnitudes slower than the others.
  • Details:

Reply all
Reply to author
0 new messages