The Rubinius project blog covers releases and design of its Ruby implementation, including GIL elimination, concurrent garbage collection, and the 3.0 instruction set.
Commenters point to it as an alternative Ruby implementation and a possible polyglot VM, and link its Rubinius 3.0 writeup.
This looks nice. I'm always excited to see higher level languages being used for scripting games. Lua is awesome at what it does but I've never really liked the syntax and lack of real objects. Building objects on top of Lua tables has always felt like such a hack to me personally.
The one thing that always concerns me with Ruby engines, however, is distributing the un-obfuscated ruby files with a game. In a single player game, with no online leader-boards or other concerns of cheating it's fine. But in a game where someone might be tempted to cheat this just makes it too easy. I know obfuscating / compiling code isn't very strong security against cheating but it's a huge step up from distributing source files ready to be edited.
Engines like Love2D (maybe other Lua based engines too, I haven't tried) allow you to compile your lua scripts and distribute the compiled versions.
With Ruby I guess the options would be to make a Java game engine with JRuby then you're just distributing JVM bytecode. Or maybe building a native engine in c (like this one) but including Rubinius to run compiled Ruby code. Rubinius has a blog post suggesting that this should be possible (http://rubini.us/2011/03/17/running-ruby-with-no-ruby/)
I'd love to see a game engine on Ruby with code obfuscation built in.
Your statement sounds like sour grapes to me.
When a language has multiple viable implementations, it means the language has a good specification. It also means that it doesn't depend too much on platform-specific characteristics. It means it is more portable. Python is both blessed and cursed with a couple of problems ... its behavior is sometimes related to the CPython implementation (e.g. reference counting, __del__), and also some libraries are too big and important to live without them.
One such library is NumPy. Currently you cannot talk about an alternative Python implementation if you don't have NumPy running on it, and that's a fact.
I'm a Python developer in my day job and I never used Pypy for anything. I only played with it and became frustrated that libraries I relied upon don't work on it.
Btw, if you're a fan of Pypy, checkout http://rubini.us/
This is a great overview about the two interpreters! However, I think you're being a bit inaccurate about how flexible the Rubinius VM is. It is certainly more than flexible enough to support a wide variety of non-Ruby languages.
The core Rubinius team bas been working towards a language-agnostic core, and toolchains for building your own language on top of the Rubinius VM. See http://rubini.us/2011/02/17/rubinius-what-s-next/#multi-language-ualization and http://rubini.us/2011/02/23/introduction-to-fancy/
There are already a good number of language projects that build upon it: http://rubini.us/projects/ Fancy is one of the more mature languages built on it (and it's self-hosted): https://github.com/bakkdoor/fancy. There's even an (immature) Python that runs on top of it: https://github.com/vic/typhon.
FTA:
> We are still using MRI 2.0.0-p195 on Heroku and haven’t switched to either JRuby or Rubinius. Although there is a lot performance we could gain from this switch we are happy with the performance we have and it would make our development more complicated.
From the Rubinius 2.0 release post[1]:
> Evan created Puma to meet the need for a fast web server that would promote the Rubinius parallel thread support. Puma also works well on MRI and JRuby. It provides Ruby applications excellent performance and multi-core scaling, especially when there's no global interpreter lock.
I'm very interested to see how much performance they would gain by switching to Rubinius, and why they say it would complicate their development.
[1] http://rubini.us/2013/10/04/rubinius-2-0-released/
What I can't understand is why Ruby's standard implementation still has such terrible performance after all these years. Yes, the language is quite complicated, at least syntactically, but semantically it's similar enough to Smalltalk, and most Smalltalks have fast jitting VMs, including Squeak and Pharo (CogVM). The Ruby community is enormous by comparison and full of productive, opinionated developers who write tons of code, books, and blog posts, and yet the standard implementation (MRI) remains abysmal (sorry).
It's really unfortunate that the MRI devs won't support Rubinius or event adopt RSpec to ensure interoperability with it:
http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use-rubyspec/
I apologize, I should have said that this is my startup. I've been a long time reader of new.yc but never felt the urge to post. But I am pretty excited about what we are doing and so I was compelled to respond.
My name is Ezra and my blog is http://brainspl.at if you have any interest in what I work on.
The most exciting thing about what we are doing wasn't really covered in this article. The real news is about our Rubinius(http://rubini.us) and Merb(http://merbivore.com) projects. We are trying to improve Ruby as a platform for everyone.