So, What About Rubinius
In fact, I’m getting more and more convinced that for the people that don’t need the things Java infrastructure can give you, Rubinius is the most important project around, in Ruby-land. More than that, Rubinius is MRI done right. If nothing substantial changes in the current timeline and plans for Ruby 1.9.1, I predict that Rubinius will be the CRuby implementation of choice within 6 months. Rubinius is an implementation done the way MRI should have been.
He also lays out a number of reasons that he feels this way:
- It is byte code based. This means it’s easier to handle performance.
- It has a pluggable, very clean architecture, meaning that for example garbage collection/object memory can be switched out to use another algorithm.
- It is designed to be thread safe (though this is not really true yet), and Multi-VM capable.
- It works with existing MRI extensions.
- Most of the code is written in Ruby.
- It gives you access to all the innards, directly from your Ruby code (stuff like MethodContexts/BlockContexts, etc).
- The project uses Valgrind to ensure that the C code written is bullet proof.
The meme that rubinius matters has also spread to Sun, who sponsored the recent Rubinius Sprint in Denver. Tim Bray who arranged the sponsorship wrote about why Sun would do this:
Ruby isn’t finished. It’s a great substrate for Rails, it’s immensely useful for building all sorts of things, but it’s not fast enough. I agree with Avi Bryant’s argument that a language isn’t finished until it’s fast enough to extend itself. Frankly, none of the language enhancements proposed for Ruby 2.0 make my heart go pitter-patter. But give me a Ruby with performance as good as a really good Smalltalk VM, and the space of things for which you need statically-typed languages shrinks to a really uninteresting size.
Except for, nobody including me is smart enough to predict which of the Ruby.next implementations is going to have that performance mojo. So, it seems like the only reasonable thing is to bet on all of ’em. One thing that makes this easy is that all the teams get along with each other; a natural outgrowth of Ruby culture, and something from which we can all learn.
Ezra Zygmuntowicz and EngineYard think that Rubinius is important enough to have started hiring Rubinius developers.
I’m really stoked about this. I think rubinius has so much potential that I am really happy to be able to support it. Starting next month Evan Phoenix is going to be working here at EY half time on ey tools and such and half time on rubinius.
The sprint itself went very well. Evan Phoenix, Wilson Bilkovich, and Brian Ford (the core rubinius developers) met with Charlie Nutter (one of the core JRuby developers) for some intensive Rubinius hacking. Brian and Wilson have both written about the experience. Evan joined them in an interview. In the interview, Evan talked about the goals and outcome of the sprint:
[We wanted] to see how we rubinius work would progress in this kind of environment. I was extremely pleased how it went. The 4 of us really tackled things well, and working in a collaborative atmosphere really sped things up. I was also happy to be right there to transfer knowledge of some of the interior of the VM to other developers. That knowledge is more difficult to grasp than almost anything else in rubinius, but probably the most important.
-- -pate http://on-ruby.blogspot.com
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Tibbo Technology's Tibbo Project System
- July 2016 Issue of Linux Journal
- Why Python?
- High-Performance Networking Programming in C
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- The Giant Zero, Part 0.x
- Client-Side Performance
- Add an Auto-Incrementing Build-Number to Your Build Process
- New Products
- Tiny Makers
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide