
Rubinius 2.0 released - steveklabnik
http://rubini.us/2013/10/04/rubinius-2-0-released/
======
1qaz2wsx3edc
> Concurrent and distributed applications aren't the future anymore, they are
> the present. They are vital to business success. The many talented
> developers that are passing over Ruby for Erlang, Go, Clojure and Node are
> draining Ruby of talent and vitality.

As someone who has been working with MRI since 2006-ish, I feel this statement
is accurate. MRI is stagnating around the GIL. Rails last lost some of it's
edge and this is in part responsible. Since about 2011, I've invested into
Erlang (elixir), and mostly NodeJS. They're truly communities that are
evolving well, they are applying themselves well to new problems inherit to
changes in application building demands.

~~~
rahoulb
Genuine question: what advantage does Node give you over EventMachine?

~~~
sturadnidge
The creator of Node was something of a Rubyist, i believe the main reason was
around the stdlib / ecosystem not being event oriented, making it difficult to
build non-blocking applications. EventMachine may well have strategies to
defeat this, I just don't know.

This video gives some good insight into what led to his decision to start
fresh rather than try and change things in Ruby
[http://m.youtube.com/watch?v=SAc0vQCC6UQ](http://m.youtube.com/watch?v=SAc0vQCC6UQ)

So that's probably the biggest thing about Node - everything in the core is
built with event orientation in mind, so you know you're not going to hit
something that will block and kill you, and that minset is pervasive in
userland too.

~~~
tomphoolery
Wow, what a journey!

------
thomasfl
It would be helpful if some could version bump rubinius in the Gemfile of this
rubinius for heroku example rails app: [https://github.com/rubinius/heroku-
rbx-puma-rails-app](https://github.com/rubinius/heroku-rbx-puma-rails-app)

------
akanet
I'm very interested in trying out rubinius alongside MRI. I have two big
questions, if anyone knows the answers:

Does anyone have any pointers on how to keep the latest RBX up to date in RVM?

Will heroku be supporting RBX's new weeklyish release cycle?

------
wiremine
Here's a tl;dr for the blog post:

Thanks to Matz, DHH, Evan Phoenix. Thanks to the hundreds of contributors.
Thanks to Engine Yard for the $$$. Thanks to the community.

Rubinius 2 will target Ruby 2.1. We're brining Ruby into the future! We will
not support multiple Ruby language versions moving forward.

Version releases are changing with the release of Rubinius 2.0. There will be
a new release once a week, won't follow a pre-determined release schedule.
Master branch will be kept extremely stable. New versions will be X.Y.Z+1.
Please post issues, hopefully they will be fixed quickly.

The goal is to semantically version the Rubinius core starting with version
3.0. We've added a subdomain
[http://releases.rubini.us](http://releases.rubini.us) for hosting release
tarballs.

About Rubinius Parts:

* It has a VM that runs byte code produced by the Ruby compiler. Every Ruby method gets its own interpreter.

* The generational garbage collector (GC) has a very fast young generation collector, usually pausing for less than 15 ms to complete a collection.

* Rubinius implements native operating system threads for concurrency and has no global interpreter lock (GIL). Ruby code can run in parallel on multi-core or multi-CPU hardware.

* The Rubinius just-in-time compiler (JIT) turns Ruby bytecode into machine code. The JIT thread is mostly independent of the Ruby threads so the JIT operation doesn't impact the running code's performance.

* The Rubinius core libraries (e.g. Array, Hash, Range, etc.), as well as Rubinius tools like the bytecode compiler, are written in Ruby. The Rubinius systems treat them just like Ruby application code.

Commenters note: There's a whole section called "Plans, Meeet Future" which
seems to say Ruby hasn't kept pace with the "SaaS revolution." Honestly, not
sure what as going on here, I'll punt on a summarizing.

Plans for improvement:

* Significantly improve concurrency coordination in the system. Some operations requires topping all threads. Working to get rid of this.

* Provide more efficiency by using more modern lock-free concurrent data structures.

* Make the GC more concurrent and parallel.

* Make the JIT even faster and expose more of it to regular Ruby code.

Gems as Components:

* Major components, like the bytecode compiler, Ruby parser, debugger, etc. have been moved to gems. These components can be updated easily and quickly without requiring a Rubinius release.

* In Rubinius 2.0, the Ruby standard library has also been converted to gems.

The post then reflects on how Rubinius has inspired other projects: RubySpec,
Topaz, Opal, Puma, etc.

And it ends with: "Ruby is an excellent language. Rubinius is dedicated to
providing Ruby developers with excellent tools and technology competitive with
these other languages. Developers who are happy writing Ruby shouldn't be
forced to leave it because of technical limitations."

~~~
tomphoolery
Can't wait to try this out at work!

------
regularfry
> Over time, we've tried to support multiple Ruby language versions, many
> different projects, old and new code, code that abuses every corner of MRI's
> ad hoc semantics, and every random, undocumented MRI C function with the
> Rubinius C-API compatibility layer. Unfortunately, this is unsustainable and
> not in the best interests of Ruby or Rubinius.

I wonder what this means for RubySpec?

------
ksec
Finally, i thought it would be another Duke Nukem Release. Glad to see it out.

Now, Rubinius 2.0, Ruby 2.1, Topaz, JRuby.

Exciting time for Ruby implementation.

------
piratebroadcast
Can someone explain Rubinous to me like I'm 5? NEwish to Ruby and Rails.

~~~
xionon
Ruby is what's known as an interpreted programming language. It was invented
in Japan by a guy nicknamed Matz. You write code, save it to a file, and then
a separate program "interprets" this file into code that the computer can
understand.

So, when people refer to "Ruby," they are most commonly referring to two
things: the language, and the default interpreter. The default interpreter is
known as "MRI," which stands for "Matz's Ruby Interpreter."

Rubinius is an alternative Ruby interpreter. It's main claim over MRI is that
Rubinius has (much) better support for multi-threaded applications.
Additionally, where much of the core Ruby functionality (e.g., Array) is built
using C in MRI, Rubinius builds most of it's core functionality using pure
Ruby code, and relies on the interpreter to make it fast enough, similar to
PyPy. The theory is that if you build a fast enough interpreter, it's easier
to build your dynamic language functionality in the dynamic language, rather
than in C.

~~~
mhartl
Excellent summary. N.B. *Its main claim, its core functionality

------
arnvald
Congratulations to Brian, Dirkjan and all the other people involved in
Rubinius. This is great news, I'm looking forward to test my apps on Rubinius
2.0!

------
kasperbn
Are the new lock-free concurrent data structures like clojures persistent data
types? That would be very useful. Great work/plan!

------
tharshan09
Is there a possibility of something like this for python? or is there already?

~~~
maz-dev
PyPy? [http://pypy.org/](http://pypy.org/)

------
te_chris
This is super cool, great work guys!

