Rubinius X, an experiment in modernizing Ruby(x.rubini.us)
x.rubini.us
Rubinius X, an experiment in modernizing Ruby
http://x.rubini.us/
7 comments
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?
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?
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.
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.
>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...
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
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;
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
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 ?
How will this turn out? Matz will approve it? If yes why not make Rubinius the default implementation?
If not, then ?
More activity in the other thread: https://news.ycombinator.com/item?id=6553767
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.
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.
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.
> Global Variables
> Gone. Period.
That's pretty extreme. What is supposed to replace them?
> Gone. Period.
That's pretty extreme. What is supposed to replace them?
It's not really extreme. You can, and should, easily provide globals through attributes on classes and modules (which are globals themselves):
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
class << self
attr_accessor :size
end
end
Foot.size = 8
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::SIZESans 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"Sure, but wasn't that exactly what I wrote in my first example?
Oy, it is. Sorry; my brain is apparently missing its reading comprehension hat today.
Any word on the progress of this / who is behind it?
As far as I can see, this is all Brian Shirai (aka brixen), who is the current maintainer of Rubinius.
i m also curious why rubinius failed to gain traction, how it all started and why EY abandoned their support?
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...
[2] http://blog.fallingsnow.net/2008/11/18/a-sad-day/
[3] https://news.ycombinator.com/item?id=424000
[1] https://blog.engineyard.com/2013/engine-yard-expands-support...
[2] http://blog.fallingsnow.net/2008/11/18/a-sad-day/
[3] https://news.ycombinator.com/item?id=424000
I thought all the hipster Brogrammers moved onto Node and JS? Didn't they get the memo?
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.
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.
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.
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/
discussion: https://news.ycombinator.com/item?id=6553767
Personally I believe in "the best tool for the job".
discussion: https://news.ycombinator.com/item?id=6553767
Personally I believe in "the best tool for the job".
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.