Hi,
I had heard of most of the mentioned projects once but is impressive
to see them all in a single list: it’s longer than I would have
guessed!
http://www.igvita.com/2009/11/20/state-of-ruby-vms-ruby-renaissance/
Cheers
robert
Robert K. wrote:
I had heard of most of the mentioned projects once but is impressive
to see them all in a single list: it’s longer than I would have
guessed!
There’s a couple ones missing, actually. Overall, there have been
around 30 Ruby implementations to date. Although only half of them are
still being developed (for generous definitions of “half” and
“developed”) and only three of them (MRI, JRuby, YARV) have ever
produced a production release. (And one could argue about whether an
implementation which doesn’t even run its own testsuite, let alone
pass it, or one which leaks memory, can be called “production
ready”.)
Among the ones that are still being developed and that are missing
from the list are:
- YARV (Koichi Sasada’s custom VM for Ruby 1.9)
- XRuby (Ruby compiler for the JVM)
- SmallRuby (Ruby on Smalltalk/X)
- tinyrb (Marc-André Cournoyer’s tiny Ruby-subset VM)
- HotRuby (YARV bytecode interpreter on Flash or ECMAScript)
- Cardinal (Ruby on Parrot)
Especially YARV seems to be a pretty big omission from the list.
A couple of the ones that are no longer being developed but are
nonetheless interesting are:
- the original IronRuby (yes, there are two implementations called
IronRuby; this one had experimental support for continuations,
which is something that JRuby, XRuby, Ruby.NET and the other
IronRuby don’t have) - Carbone (Ruby VM automatically generated by vmgen)
- IoRuby (Ruby on Io)
- MetaRuby (Ruby 100% in Ruby, using Ruby2C)
- Red Sun (YARV bytecode interpreter in ActionScript)
And of course Rite, the mythical Ruby implementation that Matz once
wanted to write one day, but never did.
jwm
El Miércoles, 2 de Diciembre de 2009, Jörg W Mittag escribió:
Especially YARV seems to be a pretty big omission from the list.
What about Rubinius?
Iñaki Baz C. wrote:
Especially YARV seems to be a pretty big omission from the list.
What about Rubinius?
That’s already on Ilya’s list.
jwm
On 2 Dec 2009, at 15:40, Jörg W Mittag wrote:
Among the ones that are still being developed and that are missing
from the list are:
- tinyrb (Marc-André Cournoyer’s tiny Ruby-subset VM)
Hopefully this list will soon be joined by RubyGoLightly, my project to
port TinyRb from C to Go and then see where that leads. Anyone
interested in helping (or chucking stones) can find work in progress at:
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh wrote:
Now, if only tinyrb worked on Windows, Go worked on Windows and I
could overcome my deep-seated hatred against so-called “systems
programming languages”[1] and actually bring myself to learning the
damn thing.
Anyway, regarding your “see where that leads”, I have a couple of
questions:
-
Are you planning to use Go’s garbage collector or provide your own?
Currently, tinyrb uses the Boehm-Demers-Weiser conservative
garbage collector (AFAIK anyway), which incidentally is also the
collector used by one of the two Go implementations. Marc-André
was considering switching to reference counting, which
incidentally is also what the other Go implementation is
planning on doing. -
Are you simply using Go as an implementation language, like, say,
tinyrb, MRI, YARV or Rubinius do or are you planning some sort of
interoperability between Go and Ruby as JRuby and IronRuby do or
even a very deep unification of the two languages like MacRuby and
MagLev? -
Are you planning on implementing Threads with Goroutines? What about
Fibers, Continuations? -
Are you planning on surfacing the CSP/Pi-calculus style concurrency
of the Go runtime somehow in Ruby? -
Are you planning anything at all, or just having fun? (-:
jwm
[1] This hatred is rooted in two things:
1.) "Systems programming language" is commonly used as a
euphemism for "crappy programming language" in the sense
that "we know it's crap but it's okay, because it's a
systems programming language!". Ex.: C, C++, Java
2.) I strongly believe that systems programming languages should
not exist. Writing operating systems, garbage collectors,
compilers, interpreters, real-time systems, interrupt
handlers, databases, etc. *in* Lisp, Smalltalk, Python,
Haskell has been done for decades, as has writing fast
implementations *for* them.
El Miércoles, 2 de Diciembre de 2009, Jörg W Mittag escribió:
- HotRuby (YARV bytecode interpreter on Flash or ECMAScript)
From the project web (http://hotruby.yukoba.jp):
Most of the grammars are implemented. However, exceptions are not
implemented.
Most of the build-in functions and build-in classes are not implemented.
The idea is good, but obviously it’s not mantained, neither enoguh
advanced.
On 3 Dec 2009, at 11:30, Jörg W Mittag wrote:
This looks very cool!
Now, if only tinyrb worked on Windows, Go worked on Windows and I
could overcome my deep-seated hatred against so-called “systems
programming languages”[1] and actually bring myself to learning the
damn thing.
Well I’m not holding my breath on Go making it to Windows anytime soon,
but I hope I’m wrong.
I also share many of your feelings about “systems programming
languages”, compounded by the fact I spend a lot of time working on C
codebases. Part of what I find appealing about Go is that it reads like
a high-level language, that and the fact that it provides a decent
native concurrency model.
Anyway, regarding your “see where that leads”, I have a couple of
questions:
- Are you planning to use Go’s garbage collector or provide your own?
Currently, tinyrb uses the Boehm-Demers-Weiser conservative
garbage collector (AFAIK anyway), which incidentally is also the
collector used by one of the two Go implementations. Marc-André
was considering switching to reference counting, which
incidentally is also what the other Go implementation is
planning on doing.
I’d like to phrase everything to leverage Go’s garbage collection, the
same way that JRuby uses the JVM’s collector.
- Are you simply using Go as an implementation language, like, say,
tinyrb, MRI, YARV or Rubinius do or are you planning some sort of
interoperability between Go and Ruby as JRuby and IronRuby do or
even a very deep unification of the two languages like MacRuby and
MagLev?
As Go’s still a bit of a moving target I’m initially looking at it as an
implementation language, although supporting NaCl and other elements of
Google’s emerging software platform would be interesting.
- Are you planning on implementing Threads with Goroutines? What about
Fibers, Continuations?
It’ll use Goroutines for both Threads and Fibers, and I’m interested in
using the Go Iterator pattern to implement Ruby Enumerators.
Continuations should also be feasible, although a lot depends on how the
VM’s instruction set evolves and the
- Are you planning on surfacing the CSP/Pi-calculus style concurrency
of the Go runtime somehow in Ruby?
Whilst it’d be nice to have it’s a very low priority - at least until
there’s a stable interpreter capable of passing all of TinyRb’s tests.
- Are you planning anything at all, or just having fun? (-:
Well fun is a big part of it 
However there’s also a plan. Initially I want to get a codebase that
compiles, makes reasonable use of Go’s idioms, and passes TinyRb’s
tests. Once that milestone is hit I plan to experiment with the VM’s
instruction set and to start fleshing out the runtime, possibly with the
intention of becoming a full-blown Ruby implementation (if there’s a
demand).
A high priority at that stage will be getting Ruby-FFI support so I can
continue my low-level coding adventures
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason