MagLev
RailsConf took place this weekend and it seems one of the biggest (as in most hotly covered) presentations that took place related to MagLev (not much to see at that web site unfortunately because its still at such an early stage). Apparently the MagLev presentation consisted of a demonstration of a distributed OO database and some benchmarks on current performance figures for the MagLev VM.
Being one of the hottest items at the conference has meant that the presentation has received a substantial amount of blog coverage (including this one I suppose). At lot of these posts have conveyed the positive impression the presentation made on the viewers but a few bloggers (see here and here) aren’t so easily impressed. I have to admit these guys make some solid points which basically boil down to…
- MagLev hasn’t stated its current compatability with Ruby and, therefore, its impressive benchmark figures are essentially meaningless.
- An OODB isn’t bringing anything new to the table. Indeed OO database have been around for quite a while and have consistently failed to live up to their hype.
While, at a fundamental level, these things are true I don’t believe that MagLev is at a sufficiently advanced stage to justify levelling these criticism against it. MagLev has been running on quiet so, as far as I know, theres not a great deal known about it but a few things that are known include…
- The project has been in the works for less than half a year (the Ruby aspect of it at least). This isn’t a particular long period of time.
- The work is based upon a mature Smalltalk virtual machine (its been worked on for around 2 decades from what I gather).
- The OO database side is based on a product call GemStone which, again, is mature and in practical and commercial use.
- It seems that the intention is to offer some of the MagLev elements as open source while others will be proprietary.
What I take from these facts are that the MagLev system is still young but seems to be building on a pretty solid foundation. The OO database side of things may not find universal application but it does offer an alternative to the standard RDBMS and its always good to have choices. The MagLev people may not yet be making any claims with regards to Ruby compatability but they have voiced a commitment to this and its early days yet. The underlying virtual machine was specifical designed to work with dynamic languages and, while it has required some tweaking to handle Ruby, its had a lot to time to iron out kinks and maximize performance (more time in fact than JRuby or Rubinius) so maybe the performance claims aren’t that outrageous.
The commercial licensing of the virtual machine may offend some but you don’t have to pay for it if any of the existing free choices fulfills your needs. On this last point I’d have to say its case of wait and see what the costs are before criticizing the decision. If they are able to maintain the order of magnitude speed increase in the finished product it may be more than worth paying for.
Ruby is at a very healthy stage in its life cycle, with at least a half a dozen competing implementations to choose from (MRI, YARV, JRuby, Rubuinius, IronRuby and MagLev). Personally I can’t see all of these surviving but many of then fit into niches that I can appreciate. For example JRuby or IronRuby can be used to leverage existing Java or .NET code bases. I can easily see a niche for MagLev in the commercial or large scale deployment arena if it lives up to its promises. I just don’t think that the MagLev project is at an advanced enough stage to be levelling such strong criticism against it.