3 ms·

Rubinius X, an experiment in modernizing Ruby

34 points by slowernet 13y ago

nwienert 13y ago
Any word on the progress of this / who is behind it?
- lobster_johnson 13y ago
  As far as I can see, this is all Brian Shirai (aka brixen), who is the current maintainer of Rubinius.
  - diminish 13y ago
    i m also curious why rubinius failed to gain traction, how it all started and why EY abandoned their support?
    - lobster_johnson 13y ago
      I don't think Engine Yard has abandoned support. Back in April they added funding for a Rubinius developer [1]. But they did lay/move off the full-time Rubinius team, back in 2008-2009, which, as far as I know, was due to financial constraints [2] [3], not a lack of interest. [1] https://blog.engineyard.com/2013/engine-yard-expands-support-for-rubinius https://blog.engineyard.com/2013/engine-yard-expands-support... [2] http://blog.fallingsnow.net/2008/11/18/a-sad-day/ http://blog.fallingsnow.net/2008/11/18/a-sad-day/ [3] https://news.ycombinator.com/item?id=424000 https://news.ycombinator.com/item?id=424000
static_typed 13y ago
I thought all the hipster Brogrammers moved onto Node and JS? Didn't they get the memo?
- lobster_johnson 13y ago
  Most of us rubyists aren't actually "hipster broprogrammers", but hard-working devs who like to get things done -- just like everyone else. It's unfortunate that the Ruby world is being painted with that kind of brush, when it's really down to just a few bad apples.
  - astrodust 13y ago
    It's not the bad apples, it's the impression others get due to relativity. To some guy slamming out Java in a bank where you have to wear a suit and tie or PHP in some chop shop where version control is on the distant TO-DO list, Ruby programmers do look like brogrammers with their fancy tools and fancy computers.
- heijmans 13y ago
  You're probably not serious, but for the OP this was the reason to start Rubunius X, as you can see here: http://rubini.us/2013/10/15/introducing-rubinius-x/ http://rubini.us/2013/10/15/introducing-rubinius-x/ discussion: https://news.ycombinator.com/item?id=6553767 https://news.ycombinator.com/item?id=6553767 Personally I believe in "the best tool for the job".
comex 13y ago
> Global Variables > Gone. Period. That's pretty extreme. What is supposed to replace them?
- lobster_johnson 13y ago
  It's not really extreme. You can, and should, easily provide globals through attributes on classes and modules (which are globals themselves): module Foot @size = 10 class << self attr_accessor :size end end Foot.size = 8 ActiveSupport gives you "mattr_accessor" and "class_attribute" to accomplish the same thing with less code. In my opinion, class/module-level attributes are useful enough that it ought to be provided by the language itself. Edit: Come to think of it, most people, that I have seen, use globals to set constants. That currently has perfectly good syntax: module Foot SIZE = 10 end print Foot::SIZE
  - cheald 13y ago
    Sans ActiveSupport, you can achieve the same things by just opening class/module eigenclass: module Foo class << self attr_accessor :bar end end Foo.bar = "baz"
    - lobster_johnson 13y ago
      Sure, but wasn't that exactly what I wrote in my first example?
      - cheald 13y ago
        Oy, it is. Sorry; my brain is apparently missing its reading comprehension hat today.
davidroetzel 13y ago
While I do not disagree with any of the proposed features, I am not sure, what they would accomplish. Could someone point out, what kind of applications would benefit from those changes? Is this just about making ruby more like node (substituting callbacks for promises)? Also, do all of these features really need to be implemented on the interpreter level?
- lobster_johnson 13y ago
  It is, at least, about making Ruby more concurrent. Rubinius eliminates the global interpreter lock, which helps, but Ruby's execution model is still very much thread-oriented; Ruby's fibers are very slow, and are not good enough for Node-style concurrency. It is also about wiping the slate clean. Ruby still has some ugly stuff inherited from Perl (globals for regex results, or the use of unreadable "magical" globals such as $:). There are many areas where years of experience can help us design a better language.
  - ksec 13y ago
    To me, that is more like Ruby 3.0, or a similar languages with another name. How will this turn out? Matz will approve it? If yes why not make Rubinius the default implementation? If not, then ?
  - draegtun 13y ago
    >Ruby still has some ugly stuff inherited from Perl (globals for regex results, or the use of unreadable "magical" globals such as $:) And Ruby also has some pretty stuff inherited from Perl like postfix statements & first class regex so it wouldn't be good to strip out all of Perl's influences! Gosh even Ruby's blocks are (partly) inspired by Perl's list block functions... array.map {|n| n * 2} map {$_ * 2} @array; However I do agree that Ruby's magical global variables should be removed because they're not dynamically scoped like in Perl. NB. It should be noted that not all Ruby magical variables even come from Perl. For eg. $: doesn't and thankfully Perls $= does something quite different to Rubys! - https://news.ycombinator.com/item?id=5072925 https://news.ycombinator.com/item?id=5072925
heijmans 13y ago
While this sounds interesting and a lot of the features are laudable, it seems to me that such a language will no longer be "Ruby". All non-trivial Ruby code (like any library or gem) will not work in Rubinius X. So why base this on Ruby? Because the syntax is nice? Perhaps it would be better to start with something like elixir, which has a syntax based on Ruby, works with existing Erlang libraries and has good (perhaps excellent) support for concurrency and immutability.
- astrodust 13y ago
  It's not the point to fork, but to experiment and see which features are worth porting back into Ruby core. I think it's great.
UNIXgod 13y ago
why break regex support just because it's not what one person wants to use; the philosophy of more than one way to do it goes back to the beginning of computer science. I like Rubinius for the fact that it has educational value to see ruby implemented in ruby but feel breaking unix system programming features sounds more like turing it into someones personal DSL than actually modernizing it.
- saidajigumi 13y ago
  Because that's what Rubinius non-X is for. This is about an experimental Ruby-based language that has the freedom to make breaking changes. It's not just another implementation of Ruby, it's about creating a new language that learns from Ruby and other languages. I expect that we'll see some of these ideas percolate back to Ruby proper, and others will be created and/or wither on their merits within Rubinius X, so long as it remains experimental. All that said, this simplifies the language spec and implementation by eliminating features that have long been on-the-outs in the Ruby community. Note that the proposals on that page don't break regexes, they just break code that uses the old Perl-esque $1, etc. magic variables. This is almost mechanically trivial to port to use Regexp methods, MatchData, etc. IME, it's rare to see this used in Ruby code in the wild. I find it kind of startling when it does show up.
lobster_johnson 13y ago
More activity in the other thread: https://news.ycombinator.com/item?id=6553767 https://news.ycombinator.com/item?id=6553767

34 points by slowernet 13y ago

nwienert 13y ago

Any word on the progress of this / who is behind it?

lobster_johnson 13y ago
As far as I can see, this is all Brian Shirai (aka brixen), who is the current maintainer of Rubinius.
- diminish 13y ago
  i m also curious why rubinius failed to gain traction, how it all started and why EY abandoned their support?
  - lobster_johnson 13y ago
    I don't think Engine Yard has abandoned support. Back in April they added funding for a Rubinius developer [1]. But they did lay/move off the full-time Rubinius team, back in 2008-2009, which, as far as I know, was due to financial constraints [2] [3], not a lack of interest. [1] https://blog.engineyard.com/2013/engine-yard-expands-support-for-rubinius https://blog.engineyard.com/2013/engine-yard-expands-support... [2] http://blog.fallingsnow.net/2008/11/18/a-sad-day/ http://blog.fallingsnow.net/2008/11/18/a-sad-day/ [3] https://news.ycombinator.com/item?id=424000 https://news.ycombinator.com/item?id=424000

static_typed 13y ago

I thought all the hipster Brogrammers moved onto Node and JS? Didn't they get the memo?

lobster_johnson 13y ago
Most of us rubyists aren't actually "hipster broprogrammers", but hard-working devs who like to get things done -- just like everyone else. It's unfortunate that the Ruby world is being painted with that kind of brush, when it's really down to just a few bad apples.
- astrodust 13y ago
  It's not the bad apples, it's the impression others get due to relativity. To some guy slamming out Java in a bank where you have to wear a suit and tie or PHP in some chop shop where version control is on the distant TO-DO list, Ruby programmers do look like brogrammers with their fancy tools and fancy computers.
heijmans 13y ago
You're probably not serious, but for the OP this was the reason to start Rubunius X, as you can see here: http://rubini.us/2013/10/15/introducing-rubinius-x/ http://rubini.us/2013/10/15/introducing-rubinius-x/ discussion: https://news.ycombinator.com/item?id=6553767 https://news.ycombinator.com/item?id=6553767 Personally I believe in "the best tool for the job".

comex 13y ago

> Global Variables > Gone. Period. That's pretty extreme. What is supposed to replace them?

lobster_johnson 13y ago
It's not really extreme. You can, and should, easily provide globals through attributes on classes and modules (which are globals themselves): module Foot @size = 10 class << self attr_accessor :size end end Foot.size = 8 ActiveSupport gives you "mattr_accessor" and "class_attribute" to accomplish the same thing with less code. In my opinion, class/module-level attributes are useful enough that it ought to be provided by the language itself. Edit: Come to think of it, most people, that I have seen, use globals to set constants. That currently has perfectly good syntax: module Foot SIZE = 10 end print Foot::SIZE
- cheald 13y ago
  Sans ActiveSupport, you can achieve the same things by just opening class/module eigenclass: module Foo class << self attr_accessor :bar end end Foo.bar = "baz"
  - lobster_johnson 13y ago
    Sure, but wasn't that exactly what I wrote in my first example?
    - cheald 13y ago
      Oy, it is. Sorry; my brain is apparently missing its reading comprehension hat today.

davidroetzel 13y ago

While I do not disagree with any of the proposed features, I am not sure, what they would accomplish. Could someone point out, what kind of applications would benefit from those changes? Is this just about making ruby more like node (substituting callbacks for promises)? Also, do all of these features really need to be implemented on the interpreter level?

lobster_johnson 13y ago
It is, at least, about making Ruby more concurrent. Rubinius eliminates the global interpreter lock, which helps, but Ruby's execution model is still very much thread-oriented; Ruby's fibers are very slow, and are not good enough for Node-style concurrency. It is also about wiping the slate clean. Ruby still has some ugly stuff inherited from Perl (globals for regex results, or the use of unreadable "magical" globals such as $:). There are many areas where years of experience can help us design a better language.
- ksec 13y ago
  To me, that is more like Ruby 3.0, or a similar languages with another name. How will this turn out? Matz will approve it? If yes why not make Rubinius the default implementation? If not, then ?
- draegtun 13y ago
  >Ruby still has some ugly stuff inherited from Perl (globals for regex results, or the use of unreadable "magical" globals such as $:) And Ruby also has some pretty stuff inherited from Perl like postfix statements & first class regex so it wouldn't be good to strip out all of Perl's influences! Gosh even Ruby's blocks are (partly) inspired by Perl's list block functions... array.map {|n| n * 2} map {$_ * 2} @array; However I do agree that Ruby's magical global variables should be removed because they're not dynamically scoped like in Perl. NB. It should be noted that not all Ruby magical variables even come from Perl. For eg. $: doesn't and thankfully Perls $= does something quite different to Rubys! - https://news.ycombinator.com/item?id=5072925 https://news.ycombinator.com/item?id=5072925

heijmans 13y ago

While this sounds interesting and a lot of the features are laudable, it seems to me that such a language will no longer be "Ruby". All non-trivial Ruby code (like any library or gem) will not work in Rubinius X. So why base this on Ruby? Because the syntax is nice? Perhaps it would be better to start with something like elixir, which has a syntax based on Ruby, works with existing Erlang libraries and has good (perhaps excellent) support for concurrency and immutability.

astrodust 13y ago
It's not the point to fork, but to experiment and see which features are worth porting back into Ruby core. I think it's great.

UNIXgod 13y ago

why break regex support just because it's not what one person wants to use; the philosophy of more than one way to do it goes back to the beginning of computer science. I like Rubinius for the fact that it has educational value to see ruby implemented in ruby but feel breaking unix system programming features sounds more like turing it into someones personal DSL than actually modernizing it.

saidajigumi 13y ago
Because that's what Rubinius non-X is for. This is about an experimental Ruby-based language that has the freedom to make breaking changes. It's not just another implementation of Ruby, it's about creating a new language that learns from Ruby and other languages. I expect that we'll see some of these ideas percolate back to Ruby proper, and others will be created and/or wither on their merits within Rubinius X, so long as it remains experimental. All that said, this simplifies the language spec and implementation by eliminating features that have long been on-the-outs in the Ruby community. Note that the proposals on that page don't break regexes, they just break code that uses the old Perl-esque $1, etc. magic variables. This is almost mechanically trivial to port to use Regexp methods, MatchData, etc. IME, it's rare to see this used in Ruby code in the wild. I find it kind of startling when it does show up.

lobster_johnson 13y ago

More activity in the other thread: https://news.ycombinator.com/item?id=6553767 https://news.ycombinator.com/item?id=6553767