Project

General

Profile

Actions

Feature #5482

closed

Rubinius as basis for Ruby 2.0

Added by trans (Thomas Sawyer) over 12 years ago. Updated almost 6 years ago.

Status:
Rejected
Target version:
[ruby-core:40322]

Description

I'll give you three great reasons why:

  1. It's Ruby in Ruby (mostly).
  2. Ruby is better.
  3. Read #1 and #2, again.

As Rubyists, if we truly believe that Ruby makes software development more enjoyable and more productive, then it only stands to reason that Rubinius be the future of Ruby.

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

  • Category set to Joke

Cute.
+1.

Updated by headius (Charles Nutter) over 12 years ago

I think we should roll back to Evan's original pure-Ruby implementation and get rid of all that nasty C++. After all, if we truly believe that Ruby makes software development more enjoyable and more productive, then it only stands to reason that we should eliminate all non-Ruby languages from Ruby implementations.

Also...JRuby instead!

Updated by ko1 (Koichi Sasada) over 12 years ago

(2011/10/25 12:46), Yusuke Endoh wrote:

Come back when all 1.9 features and callcc are implemented :-)

Off topic:
I plan to propose that removing callcc from 2.0.

--
// SASADA Koichi at atdot dot net

Updated by headius (Charles Nutter) over 12 years ago

Remove fork, the C extension API, and ObjectSpace, and JRuby can be the new Ruby 2.0!

Updated by spatulasnout (B Kelly) over 12 years ago

Charles Nutter wrote:

Remove fork, the C extension API, and ObjectSpace, and JRuby can be the new Ruby 2.0!

Add the JVM to the list and I'm sold!

;)

(Sorry Could Not Resist)

Bill

Updated by headius (Charles Nutter) over 12 years ago

How about we run on the Dalvik "I swear I'm not a JVM" VM and call it even? I think it can even fork!

Updated by normalperson (Eric Wong) over 12 years ago

Charles Nutter wrote:

I think we should roll back to Evan's original pure-Ruby
implementation and get rid of all that nasty C++. After all, if we
truly believe that Ruby makes software development more enjoyable and
more productive, then it only stands to reason that we should
eliminate all non-Ruby languages from Ruby implementations.

More seriously, I agree that Ruby should be used whenever it makes sense
and I feel MRI uses too much C.

However, I still spend more time with MRI (than Rubinius) for the
following reasons:

  1. From my experience, Rubinius aims to provide a Ruby environment.
    I don't want a "Ruby environment", I want Ruby to be a /part/ of my
    existing Unix environment (which includes sh/awk/sed/perl among
    others). I like MRI startup is still reasonably fast. I can
    easily swap out existing pieces of awk/sed for one-off Ruby scripts
    instead of one-off C programs when I need something I can't do as
    easily in awk/sed.

    I could use Perl instead of Ruby, but I prefer Ruby to Perl as a
    language.

  2. I have no interest/skill in debugging/fixing C++ bugs in Rubinius.
    I usually fix C bugs in MRI without much effort. I suspect
    more potential contributors are capable of debugging/fixing C code
    written_by_other_people than C++.
    Of course, more Ruby code would open the door to more maintainers, still.

With better Ruby APIs (like String#byteslice in 1.9.3) and proposed
non-blocking IO methods[1], I think more parts of MRI could be
implemented in Ruby without significant performance loss.

[1] http://redmine.ruby-lang.org/issues/5138

Updated by headius (Charles Nutter) over 12 years ago

On Tue, Oct 25, 2011 at 5:15 PM, Eric Wong wrote:

More seriously, I agree that Ruby should be used whenever it makes sense
and I feel MRI uses too much C.

I agree wholeheartedly. This is perhaps the biggest reason I want MRI
to phase out the current C extension API in favor of one that's less
invasive, and why I'm excited for any promising JIT work for MRI. If
MRI can run Ruby fast enough, there will be less motivation to keep
moving libraries into C. That will make my life (and Evan's life) a
whole lot easier.

However, I still spend more time with MRI (than Rubinius) for the
following reasons:

And those are also reasons I don't think MRI will go away any time
soon. Suggestions to the contrary are just plain silly.

MRI is the most compatible Ruby implementation.

MRI is for many things still the fastest Ruby implementation (startup
time, some POSIX situations, C extensions).

MRI has the largest pool of regular contributors.

MRI is a solid, known quantity.

I will often recommend MRI when people need things that MRI does
better than JRuby, like fast startup, low-level POSIX stuff, or
features we can't support like callcc and fork. MRI is a vitally
important part of the Ruby implementation world.

Now, it would be nice if MRI didn't make changes to "Ruby the
language" without some direct participation and buy-in from the other
implementers, but that's a completely separate issue.

With better Ruby APIs (like String#byteslice in 1.9.3) and proposed
non-blocking IO methods[1], I think more parts of MRI could be
implemented in Ruby without significant performance loss.

Agreed. And those APIs could easily translate to other
implementations, giving us a much smaller implementation target to
keep up with. Let's make it happen!

  • Charlie

Updated by Anonymous over 12 years ago

On Mon, Oct 24, 2011 at 9:58 PM, SASADA Koichi wrote:

(2011/10/25 12:46), Yusuke Endoh wrote:

Come back when all 1.9 features and callcc are implemented :-)

Off topic:
I plan to propose that removing callcc from 2.0.

Can we have partial continuations instead? They allow for much better
optimization and have been shown to be more powerful. shift/reset style
continuations, maybe?

Updated by headius (Charles Nutter) over 12 years ago

On Tue, Oct 25, 2011 at 11:45 PM, Tim Felgentreff wrote:

Can we have partial continuations instead? They allow for much better
optimization and have been shown to be more powerful. shift/reset style
continuations, maybe?

Fun hack of the night: https://gist.github.com/1315794

I'm sure it's not perfect, but it runs simple things correctly.

  • Charlie

Updated by mame (Yusuke Endoh) over 12 years ago

Hello, Charles

2011/10/26 Charles Oliver Nutter :

On Tue, Oct 25, 2011 at 11:45 PM, Tim Felgentreff wrote:

Can we have partial continuations instead? They allow for much better
optimization and have been shown to be more powerful. shift/reset style
continuations, maybe?

Fun hack of the night: https://gist.github.com/1315794

I'm sure it's not perfect, but it runs simple things correctly.

That is not a partial continuation.
A shift should first evaluate the given block, and then
jump to the corresponding reset with the result.
The execution must not return to reset's block.

reset { 2 * shift {|k| 2 } } #=> must be 2, not 4

The feature can be implemented by using callcc.

require "continuation"

def shift
  callcc {|c1| $ctn[yield(proc {|v| callcc {|c2| $ctn = c2; c1[v] } })] }
end

def reset
  callcc {|c| $ctn = c; v = yield; $ctn[v] }
end

You may think you can implement the feature in pure Ruby
by an exception or catch/throw. But I guess it is
difficult because it requires reentrant to a shift's
block. For example,

p reset { [1] + shift {|j| [2] + j[[3]] } + shift {|k| [4] + k[[5]] } }

prints [2, 4, 1, 3, 5].

It is difficult for me to explain how it does in English :-)
I just show a pseudo reduction diagram:

p reset { [1] + shift {|j| [2] + j[[3]] } + shift {|k| [4] + k[[5]] } }
#=> reset { [1] + [3] + shift {|k| [4] + k[[5]] } }
#=> reset { [1] + [3] + [5] }
#=> reset { [1] + shift {|j| [2] + j[[3]] } + shift {|k| [4] + [1,3,5] } }
#=> reset { [4,1,3,5] }
#=> reset { [1] + shift {|j| [2] + [4,1,3,5] } + shift {|k| [4] + k[5] } }
#=> reset { [2,4,1,3,5] }
#=> [2, 4, 1, 3, 5]

Check out Olivier's original paper if you are interested.

  • Olivier Danvy and Andre Filinski (1990). "Abstracting Control".

If callcc would be removed in 2.0, we should lose a right
to play with such an interesting puzzle. Bummer.

--
Yusuke Endoh

Updated by headius (Charles Nutter) over 12 years ago

I think it is more important for Ruby to be fast, expressive and easy to use
rather than filled with "interesting puzzles" but perhaps I am in a minority
there. In any case, I doubt that 99% of developers would care if callcc went
away, and it is not supported in several implementations already.

  • Charlie (mobile)

Updated by naruse (Yui NARUSE) over 11 years ago

  • Priority changed from 5 to Normal

mruby should be the basis of Ruby 3.0.

Updated by ko1 (Koichi Sasada) about 11 years ago

  • Assignee set to matz (Yukihiro Matsumoto)

Some spies may be here.

Updated by hsbt (Hiroshi SHIBATA) almost 6 years ago

  • Status changed from Open to Rejected

We are working Ruby 3.0 now.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0