File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Ruby and the fly likes WG Rubyist: What does YARV bring to Ruby 1.9, future of Ruby, more... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Languages » Ruby
Bookmark "WG Rubyist: What does YARV bring to Ruby 1.9, future of Ruby, more..." Watch "WG Rubyist: What does YARV bring to Ruby 1.9, future of Ruby, more..." New topic
Author

WG Rubyist: What does YARV bring to Ruby 1.9, future of Ruby, more...

Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
Apart from speed, what does the YARV implementation bring to Ruby 1.9? I've read that Rails ActiveRecord is slower (right now) and that there might be some changes to the threading model. Do you think that any of the features of Ruby 1.9 will translate directly into core features in Rails?

I feel very fortunate to have found Ruby, and have a newfound appreciation for programming due to the language. Where do you see Ruby going post 1.9? Do you see Ruby becoming mainstream-enough to get serious consideration from conservative organizations?

Finally, if you could either add one feature or enhance an existing aspect of Ruby, what would that be?

Thanks again for stopping by the 'ranch!



David Black
author
Greenhorn

Joined: Aug 16, 2009
Posts: 13
Hi Michael --

My impression has always been that the main point of YARV is the gain in speed. It's definitely had an impact in at least some other areas -- for instance, ParseTree doesn't work in 1.9.1, which I know is a big issue for people who have been doing stuff that involves AST manipulation. (I don't follow that very closely but it sounds like there's progress toward coming up with a new approach that will work.)

Koichi is definitely still at work on the threading model. There's an interesting interview with Koichi on threading and GC.

I'm not sure I understand your question about 1.9 and Rails. Do you mean will Rails start taking advantage of 1.9-only features? If so, I think it will, though as far as I know Rails 3.0 will still run on 1.8 (but I could be wrong about that).

Good question about the future of Ruby. I have no answer, though :-) I think the adoption of Ruby will increase, though there will always be organizations that simply don't look at open-source alternatives at all. It also depends on where in the organization. I've always felt, for example, that Rails is really great for intra-organizational applications, and in many cases it's a lot easier to have wide latitude of tool choice for those than for the public-facing ones.

Ruby after 1.9... well, we haven't heard as much about 2.0 in the recent past as we used to, but I believe in part that's because 1.9 is probably fairly close to what 2.0 will be. At least, as far as I know, 2.0 will use YARV and so forth. I suspect that the 1.8.6 to 1.9.1 transition will be looked back on as by far the most major change in the history of Ruby up to that point.

If I could add a feature to Ruby, it would be to restore some behavior that enumerators had for a little while and then lost. At some point during 1.9.0 development, you could do this:

array = [1,2,3]
enum = array.enum_for(:map, &lambda {|x| x * 10 })
enum.next # 10
enum.next # 20
enum.next # 30

In other words, the enumerator carried inside itself not only the hookup with the object (array) and the method (map), but also a block. That is no longer the case. I exchanged some email with Shugo on ruby-core about it, and I gather it's a performance issue. I think it's really too bad, and frankly it makes enumerators a lot less interesting to me.

An enhancement to the language I would like to see is the removal of class variables. But I don't think I'm going to win that one :-) I'd also like to see :: removed as a method-calling operator (a dot synonym). I keep seeing things like:

Array::new

and I have no idea what the appeal is of it. The dot does the job just fine.

For a long time I've wanted:

class Object
def singleton_class
class << self; self; end
end
end

so then you could do:

some_object.singleton_class.class_eval ...

but I know Matz has been reluctant to add this, partly because of all the disagreement about what singleton classes should be called, and partly because he's not convinced (as I recall) that being able to grab hold of a singleton class is that important or common. Judging by how many times people end up writing that method, though, I think it would be good to have it.

I'm very glad to hear that you're enjoying Ruby and that it's rekindling your interest in programming!


Ruby training coming up in September! David A. Black and Erik Kastner team up for fast-paced, four-day Ruby intro, in New Jersey, September 14-17. See http://rubyurl.com/vmzN or contact David.
Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
I agree about the :: notation, which never has felt as comfortable as dot notation. I wonder if YARV, written in C, will mean anything (aka slowdown) in the implementation of the other interpreters (JRuby, Rubinious, IronRuby). In some ways, it's interesting that the fastest Ruby interpreters are still C based.

Rails 3 on Ruby 1.8.x... that would be a surprise, but given that so much work has already gone into R3, I guess it's unavoidable. One advantage to this (that I can see) is that Rails 3 will be ported to both 1.8 and 1.9... good news for developers and hosts.

Thanks for your comments!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: WG Rubyist: What does YARV bring to Ruby 1.9, future of Ruby, more...