4 ms·

Ideas for Improving Ruby During Google Summer of Code 2015

73 points by MrBra 12y ago

asb 12y ago
While we're sharing GSoC project ideas, I'd like to highlight the list we have at lowRISC - covering a wide range of languages and just about every part of the hardware/software stack. http://www.lowrisc.org/docs/gsoc-2015-ideas/ http://www.lowrisc.org/docs/gsoc-2015-ideas/
namidark 12y ago
Is it just me or is it odd that Sidekiq is in there when it has a corporate side to it?
unknownian 12y ago
>MRI executes Ruby via an interpreted stack-machine bytecode language known as YARV On Wikipedia: >Since YARV has become the official Ruby interpreter for Ruby 1.9, it is also named KRI (Koichi's Ruby Interpreter), in the same vein as the original Ruby MRI, named for Ruby's creator Yukihiro Matsumoto. So is one of them wrong? I'm confused.
- cremno 12y ago
  The full sentence is: >MRI executes Ruby via an interpreted stack-machine bytecode language known as YARV (Yet Another Ruby VM) bytecode. So YARV is a Ruby VM that has instructions and bytecode. Are you still confused?
- krylon 12y ago
  AFAIK, technically, ruby 1.9 and later are no longer MRI, but KRI. So, yeah, I would say that technically speaking, refererring to current versions of ruby as "MRI" is not terribly correct. On the other hand, to tell the "default" ruby apart from jruby and rubinius, one might still refer to it as "MRI". Also, Robert Metcalfe once said something to the effect that "Ethernet cannot die - if something comes along to replace it, it will just be called Ethernet" or something along those lines. Maybe something similar is at work here? (Sloppiness is more likely, though.)
  - tinco 12y ago
    I am not 100% sure, but wasn't KRI a fork of MRI that at some point simply was merged? It would be a bit strange if the whole interpreter would be called KRI when most code was still written by Matz. Though Ko1 is the main developer currently Matz is still the visionary and decision maker.
    - riffraff 12y ago
      you are correct. A lot of the code is still the same from the original (1.8) matz' interpreter.
    - krylon 12y ago
      Thanks for clearing that up!
tinco 12y ago
In a recent talk in Amsterdam Koichi said that Matz has very high ambitions for Ruby 3. They will focus on concurrency and it is expected that the concurrency interface might dramatically change. With that in mind I'd say that removing the GIL is a rather useless effort. It would probably not do much for performance and most likely result in many very buggy releases of Ruby possibly tarnishing its reputation for reliability. Imagine instead if Ruby 3 had an actor system like celluloid integrated to the core, and it would require any globally defined objects (I.e. most classes and modules) to be actors. (Perhaps by making the default class parent be ActorObject, instead of Object or something) That would in one fell swoop deal with concurrency, while retaining the clean feel of Ruby.
- ksec 12y ago
  I read Ruby 3.0 is coming in earlier then expected. Likely with concurrency, some sort of types, JIT or AOT for easier deployment. But Just when should we expect Ruby 3.0? 2020?

73 points by MrBra 12y ago

asb 12y ago

While we're sharing GSoC project ideas, I'd like to highlight the list we have at lowRISC - covering a wide range of languages and just about every part of the hardware/software stack. http://www.lowrisc.org/docs/gsoc-2015-ideas/ http://www.lowrisc.org/docs/gsoc-2015-ideas/

namidark 12y ago

Is it just me or is it odd that Sidekiq is in there when it has a corporate side to it?

unknownian 12y ago

>MRI executes Ruby via an interpreted stack-machine bytecode language known as YARV On Wikipedia: >Since YARV has become the official Ruby interpreter for Ruby 1.9, it is also named KRI (Koichi's Ruby Interpreter), in the same vein as the original Ruby MRI, named for Ruby's creator Yukihiro Matsumoto. So is one of them wrong? I'm confused.

cremno 12y ago
The full sentence is: >MRI executes Ruby via an interpreted stack-machine bytecode language known as YARV (Yet Another Ruby VM) bytecode. So YARV is a Ruby VM that has instructions and bytecode. Are you still confused?
krylon 12y ago
AFAIK, technically, ruby 1.9 and later are no longer MRI, but KRI. So, yeah, I would say that technically speaking, refererring to current versions of ruby as "MRI" is not terribly correct. On the other hand, to tell the "default" ruby apart from jruby and rubinius, one might still refer to it as "MRI". Also, Robert Metcalfe once said something to the effect that "Ethernet cannot die - if something comes along to replace it, it will just be called Ethernet" or something along those lines. Maybe something similar is at work here? (Sloppiness is more likely, though.)
- tinco 12y ago
  I am not 100% sure, but wasn't KRI a fork of MRI that at some point simply was merged? It would be a bit strange if the whole interpreter would be called KRI when most code was still written by Matz. Though Ko1 is the main developer currently Matz is still the visionary and decision maker.
  - riffraff 12y ago
    you are correct. A lot of the code is still the same from the original (1.8) matz' interpreter.
  - krylon 12y ago
    Thanks for clearing that up!

tinco 12y ago

In a recent talk in Amsterdam Koichi said that Matz has very high ambitions for Ruby 3. They will focus on concurrency and it is expected that the concurrency interface might dramatically change. With that in mind I'd say that removing the GIL is a rather useless effort. It would probably not do much for performance and most likely result in many very buggy releases of Ruby possibly tarnishing its reputation for reliability. Imagine instead if Ruby 3 had an actor system like celluloid integrated to the core, and it would require any globally defined objects (I.e. most classes and modules) to be actors. (Perhaps by making the default class parent be ActorObject, instead of Object or something) That would in one fell swoop deal with concurrency, while retaining the clean feel of Ruby.

ksec 12y ago
I read Ruby 3.0 is coming in earlier then expected. Likely with concurrency, some sort of types, JIT or AOT for easier deployment. But Just when should we expect Ruby 3.0? 2020?