We are here at Q-Con 2008 in London. We are sitting here with Avi Bryant. Recently Gemstone mentioned that they were looking into supporting Ruby, JRuby and maybe the new Ruby... Rubinius Virtual Machine. Have you heard anything about that?

Yes, I have. I guess you had an article last August about this and I have been talking a lot to them since then about what I think would make sense and giving them some input on that and for the last six weeks or so I have actually been working with them very intensely on something a little bit different from what they talked about in that article and which I think is a sort of a bigger commitment of something that will make a bigger impact from them than the JRuby and Rubinius stuff that they mentioned which is to build a new Ruby product that has the same performance, the scalability, the characteristics that their Smalltalk product does. So this will be a persistent scalable sort of distributed VM architecture like I was describing for Smalltalk, but that will execute Ruby.

So you mean it's a Ruby interpreter or translator built in Smalltalk or something else?

This isn't a Smalltalk product, this is a Ruby product. So this is certainly using VM technology that they have developed and as you know the Ruby and Smalltalk languages are quite similar and so they have a lot of existing technology that can be adapted or reused. But no, this is a Ruby VM that will be executing Ruby at very high performance and it will be transparently persistent and so people will have in the same way that I described a terabyte object memory for Smalltalk; you could have a terabyte sort of persistent transactional object memory for Ruby and really the focus here is on scale. I've been spending a lot of time talking to people like Twitter about just trying to get a sense of what a large scale Ruby installation looks like. And I did this post on my blog recently that sort of compared the Gemstone architecture to the typical kind of database plus, n Mongrels plus, memchached, Rails ...; exactly. That's for Rails model and actually that is quite similar to the Gemstone architecture. But I think that this Gemstone Ruby product will allow some very interesting scalability for Ruby and Rails.

Is it similar but with Rails you have to handle more... memcached,...?

That is exactly right. The architecture in similar and the characteristics should be similar but the effort required on the part of the developer should be much less. So unlike using memcached you sort of have to manually decide: "How am I going to get this stuff in the memcache ? When do I need to invalidate the memcache? How do I get stuff out of it?" Gemstone does have a similar in memcached but that in Memory cash is automatically hooked into the persistence engine, so you put something into the cache and it gets stored automatically, something changes in storage and the cache gets refreshed automatically. You don't have to explicitly marshall it or unmarshall it, everything is just copied around in the same object format. So I think it will be much easier to build a scalable Ruby application on top of this platform than it is right now and that is really what I am excited about. I mean I think people find it really easy to get started with Rails but then they hit this wall of scalability and they have to do a lot of work to scale the Rails app. And what I want to see is to have the same ease of getting started, but to have the scaling and obviously scaling is never free, but to have scaling happen much easier.

How much can you say about this Ruby product?

Feel free to ask questions and I might be able to answer them, I might be allowed to answer them, I might refer you to Gemstone. One thing I can say is that we are going to be doing a technology demo at Rails Conf. As I say we are only working on this for 6 weeks so let that set your expectations, but whatever we do have, we are going to demo in Portland at the end of May, I think, in Rails Conf.

So it's a ground-up implementation, a new implementation of Ruby, do you have to reimplement everything from the ground-up or do you start from any other VM like Ruby 1.9?

It won't be using any of the existing Ruby source code in terms of like the MRI interpreter or the YARV interpreter or any of that, because to have a persistent capable VM you really do need from the ground up to be aware that it's persistent capable. I am also a big believer in as you know turtles all the way down and not having the standard library implemented in C, for example, which is the case in MRI; I think it should be in Ruby. One thing that we are hoping to do is to use the core libraries from Rubinius which are implemented in Ruby and to have those running on this VM. Now that is probably not something that will be true by Rails Conf, but I do hope that it's something that will be turn on long run, it's something that we'll be talking with engineers about.

So you are interacting with the Rubinius crowd?

Yes, we are interacting to some degree with the Rubinius crowd.

So will you go the Squeak path, writing the basics in sort of a cuSo will you go the Squeak path, writing the basics in sort of a cut down version of Ruby or how will that work?t down version of Ruby or how will that work?

No I mean I guess that is what Rubinius is doing, but I mean no, Gemstone, their technological expertise I guess is in building VM's and I think they will use similar techniques, in fact probably some of the same code that they have for their Smalltalk VM in building this Ruby VM and that's not something I really know anything about. The details of how the VM engine actually works I have never seen that source code, I don't know anything about that source code. I've run benchmarks on it, I've used it, I know what it's like as a user of it, but I know nothing as a developer it. And I expect that the situation, anything you can find out about the Smalltalk product probably many of those same things in terms of the technology will also apply to the Ruby product, I would guess.

And Rubinius right now is still built on the C based interpreter, it's still, the basic VM is written in C and basically ...?

They seem to have plans for Cuby.

There are different names all around. There are very nice interviews on InfoQ with the core Rubinius crowd about that. So they are going to reuse the Rubinius core implementation ...

We are very much hoping that we can collaborate with Rubinius and sort of have standard libraries in Ruby implementation that get used across. I would hope to also see a get used by JRuby which I think has some interest in.

They are interacting I think with the Ruby spec and stuff like that.

Right. Absolutely to use the same set of RSpecs I think there is a lot at the kind of Ruby level that can and should be shared across all of these projects and the differences will be at the VM level. I mean different VMs will perform differently, they will run on the JVM versus being persistent. There obviously have to be some different design decisions there and that has applications, but the more that can be shared obviously the better. I think it will be very interesting and I am excited to demo it at Rails Conf and to see what their reaction is.

It's something you've been talking about for a long time.

Absolutely. That is the thing. I mean I've been saying for years that there is this opportunity to brings a lot of the knowledge that we have in the Smalltalk world about how to bring VMs and a lot of the property that these commercial Smalltalk vendors have and apply that to the problem of Ruby. And it is very exciting to me that someone has finally taken up on it and also that I am able to be involved right now anyway at a fairly deep level with it.

What do you think it means for Smalltalk that there are so many different implementations around and if it's a strength or weakness. I think there is not a lot of very big in-use languages that has a lot of different implementations and with what is going on in Ruby now it's interesting to see what will it mean that they are beginning to be a split of maybe 3 or 4 different implementations of Ruby?

I think the biggest problem that Smalltalk has had is that with regard to their multiple implementations is that there have not been, to step back Smalltalk implementations typically do not use text files for version control. They typically use version control systems that are sort of database based and aware of the structure of the Smalltalk language and this has a lot of advantages. But what has happened is that essentially every implementation has had its own version control system and that actually more than there being separate sort of VM implementations I think has had a fragmenting effect, because it meant that you couldn't really have people who were working on multiple implementations of Smalltalk, truly sharing source coding in the sense of committing to the same tree; one of the things that I think Gemstone did exactly right when they ported Seaside and they are the only Smalltalk vendors to have done this, the sort of canonical repository for Seaside is the Squeak, Monticello repository and so what Gemstone did when they wanted to port Seaside they said:

"First we have to port the vision control system, first we have to support the same version control system that Squeak does and then it will be really easy for us to bring the code over and that means that I find it actually fairly easy to move code back and forth between Gemstone and Squeak, that is not true for any other pair of Smalltalk implementations. That is not a problem Ruby is going to have; all the Ruby code is going to be in .rb text files regardless of what implementation it is and so you are all going to be able to share the same source code repositories and so I think you won't see the same kind of issues that Smalltalk did. The other thing, I think it's instructive to look at the Scheme community versus the Common Lisp community and Scheme and Common Lisp both have many implementations, Scheme especially because it is so easy to write Scheme implementation but Common Lisp also has quite a few and the Common Lisp ones are all extremely interoperable and the Scheme ones by enlarge aren't and I think the reason for that is that the Common Lisp standard is huge.

Common Lisp has all of these libraries where Scheme is intentionally very minimal and there are standards for this and I am not that deeply involved in the Scheme community, so I shouldn't speak too much out of school, but you see certainly a different object system on your Scheme implementation, you see different implementations of things like Hash tables and so it makes it very difficult to have your code work on many of them, whereas in Common Lisp all those things are sort of baked into the standard. And again Ruby has a rich enough standard library that all of these implementations all support in the same ways that I don't think it will be a problem. So I am actually looking forward to a world with a lot of different Ruby implementations and where people can choose the implementation that makes the most sense for what they are doing and there is a few I don't know if you've seen MacRuby, but I think that is a fascinating new one to come onto the scene which uses the objective C runtime and allows very easy bridging to Cocoa; I think that is very cool, I think JRuby is obviously super important in environments with JVM is what it's all about and I think Gemstone's Ruby implementation is going to be really exciting for people doing large scale web apps.