

Rubinius X, an experiment in modernizing Ruby - slowernet
http://x.rubini.us/

======
heijmans
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
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.

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

~~~
draegtun
> _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)

------
lobster_johnson
More activity in the other thread:
[https://news.ycombinator.com/item?id=6553767](https://news.ycombinator.com/item?id=6553767)

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

------
comex
> Global Variables

> Gone. Period.

That's pretty extreme. What is supposed to replace them?

~~~
lobster_johnson
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
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
Sure, but wasn't that exactly what I wrote in my first example?

~~~
cheald
Oy, it is. Sorry; my brain is apparently missing its reading comprehension hat
today.

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

~~~
lobster_johnson
As far as I can see, this is all Brian Shirai (aka brixen), who is the current
maintainer of Rubinius.

~~~
diminish
i m also curious why rubinius failed to gain traction, how it all started and
why EY abandoned their support?

~~~
lobster_johnson
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...](https://blog.engineyard.com/2013/engine-yard-expands-support-for-
rubinius)

[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
I thought all the hipster Brogrammers moved onto Node and JS? Didn't they get
the memo?

~~~
lobster_johnson
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
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.

