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