Rubinius 2.0 released

http://rubini.us/2013/10/04/rubinius-2-0-released/

by steveklabnik • 13 years ago

189 47 13 years ago

te_chris• 13 years ago

This is super cool, great work guys!

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.

riffraff2• 13 years ago

I feel this statement is accurate. MRI is stagnating around the GIL

That seems a bit over the top.

Ignoring the steady stream of improvements/features in MRI in the 1.9-2.1 timeframe, even from the thread-based-concurrency side there have been improvements (e.g. thread safe/async IO libraries replacing older ones).

If rails lost some of it's edge compared to an Erlang based platform, it's because people have awaken from the hype dream they were living in, as they should have never have used it for that job anyway.

why-el• 13 years ago

If you dont mind me asking, what hype are you referring to? I think a lot of people are correct in assuming that Rails is a good solution for a large (largest?) class of web applications, from cruds to crud+some ajax and so on. We know for a fact that it is working for some really successful companies, so I think depicting people as living in some dream just for rationally concluding that a particular technology will suit them is, well, a stretch.

lkrubner• 13 years ago

Right or wrong, we should all take a moment to consider the irony that people are now writing stuff like this:

"If {language} lost some of it's edge compared to an {other language} based platform, it's because people have awaken from the hype dream they were living in, as they should have never have used it for that job anyway."

and compare it this passage that Bruce Eckel wrote in 2005:

"The {language} hyper-enthusiasts have left the building, leaving a significant contingent of {language} programmers behind, blinking in the bright lights without the constant drumbeat of boosterism. But the majority of programmers, who have been relatively quiet all this time, always knew that {language} is a combination of strengths and weaknesses. These folks are not left with any feelings of surprise, but instead they welcome the silence, because it's easier to think and work. Where did the hyper-enthusiasts go? To Ruby, apparently."

http://www.artima.com/weblogs/viewpost.jsp?thread=141312

rahoulb• 13 years ago

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

sturadnidge• 13 years ago

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

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.

otterley• 13 years ago

Among other things, ludicrous speed, and a reasonably decent debugger.

omarforgotpwd• 13 years ago

The virtual machine node uses, V8, is very fast. It was written by Google for Chrome and is much faster and lighter than the ruby interpreter.

tomphoolery3• 13 years ago

One thing I enjoy about NodeJS is their standard library is asynchronous until you want it to be. Most of the NodeJS libs in NPM are also designed in this way. With EventMachine, you have to be careful what you're using because some of those RubyGems will probably include blocking IO.

When you're doing that kind of programming, I think it's better to use a language or ecosystem designed specifically for that purpose rather than use a library such as Twisted or EventMachine which is inside another language that may or may not support what you're doing. This has no basis in theory or anything, just my own experience. Makes things easier for me, that's all.

camus• 13 years ago

In node all IO is async by design. So it is likely any lib you'll use will be async too.

denysonique• 13 years ago

Opal -- Ruby runtime implemented in JavaScript browser/node.js may revitalise Ruby.

claudiug• 13 years ago

why this hate for rails and ruby on ycombinator? and why this love for javascript on serverside. I never find javascript to be a great language. Callback, callback, everywhere:)

eulerphi• 13 years ago

Callbacks cause no resource retention other than the closure whereas context switching incurs a much greater hit.

thejosh• 13 years ago

it depends what the moon is like for the love/hate of language x to show in a post on HN....

lnanek2• 13 years ago

well, investors hate rails for one, because a lot of high profile companies had to move off it to scale.

virtualwhys3• 13 years ago

> The many talented developers that are passing over Ruby for Erlang, Go, Clojure and Node are draining Ruby of talent and vitality.

and the elephant in the room (Scala) goes unmentioned.

jhspaybar• 13 years ago

I love Ruby, but I have to agree with this. Scala is the language I'm slowly moving away from Ruby for. I describe it to people who love Ruby but haven't used Scala as "Ruby with types, that you don't need to know about". It's obviously A LOT more, but I've found using Scala and JRuby in conjunction is an amazing combo.

ksec• 13 years ago

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.

kasperbn• 13 years ago

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

akanet• 13 years ago

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?

arnvald• 13 years ago

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!

tharshan09• 13 years ago

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

maz-dev• 13 years ago

PyPy? http://pypy.org/

regularfry• 13 years ago

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?

wiremine• 13 years ago

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 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."

tomphoolery3• 13 years ago

Can't wait to try this out at work!

piratebroadcast• 13 years ago

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

xionon• 13 years ago

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• 13 years ago

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

thomasfl• 13 years ago

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

Rubinius 2.0 released

Related Stories