We interviewed Yugui, the 1.
This interview also appears on the December 23, 2009 issue of "WEB+DB PRESS Vol.
Translated by Hiro Asari, edited by Leonard Chin
Ruby "Now"
- Q： Ruby 1.
9.1 was released in the beginning of 2009. What are the important changes from 1. 8.x to 1. 9.x? A： The most important is multilingualization. In 1.
9.x, a CSI (Code Set Independent) approach to multilingualization was chosen. This allows multiple languages to be handled simultaneously. Ruby treats all encodings equally, rather than standardizing system's internal encoding. With CSI, it is possible to avoid the overhead of unnecessary transcoding because the same external and internal encodings can be used. Another important change is the adoption of YARV as the evaluator. It's faster, and enables the use of native threads. The speedup from 1.
8.x to 1. 9.x is significant enough that irb's startup time is noticeably shorter. Once you get used to the new features and speed of 1. 9.x, it's hard to go back to 1. 8.x. - Q： Tell us about the new features in 1.
9.2. A： First, the Socket API in 1.
9.2 feels more object-oriented. Until 1. 9.1, it was just a simple wrapper around the C library code, with a Perl-ish API. The new API has a certain degree of compatibility, so moving to 1. 9.2 shouldn't be very painful. Second, the Time class has been reimplemented. This was also a C library wrapper. On some platforms, it was only able to express times (UTC) between the years of 1970 to 2038. Now the Time class can even express times from before the birth of our solar system, as well as time after 2038. The internals have changed significantly, but there is no loss of performance.
Third, a new Random class was added. We can guarantee the correctness of random number generator in multithread execution.
Currently, I am working on adding DTrace hooks to 1.
9.2, allowing dynamic tracing with minimal overhead. This is already available in MacRuby and the Ruby bundled in Mac OS X, but I would rather not have a buggy implementation become the accepted standard ;)
Ruby on the "bleeding edge"
- Q： What is the position of 1.
9.2 in the 1. 9.x development series? A： The 1.
9.2 won't add any exciting new features. I believe that most people won't find the new features in 1. 9.2 to be very interesting, because the new features address very specific problems. This is because 1. 9.1 successful introduced a new "grand design" to Ruby. 1. 9.2 addresses some minor design flaws and improves usability, bringing Ruby 1. 9 to a stage of maturity. In future releases, significant new features such as MVM are likely to be added again. During the development of Ruby 1.
9.2, we have been working with the cooperation of the Ruby on Rails 3 team. Rails 3 should work with 1. 9.2 when it is released. Also, I plan to release Ruby 1.
9.2 as the first version of Ruby that passes RubySpec. - Q： What is RubySpec?
A： There are now many implementations of the Ruby languages, such as JRuby, besides MRI (Matz's Ruby Impmentation). RubySpec is a project to develop tests which can be used by all such implementations. The Rubinius developers started the project, and JRuby also uses it. The project is currently focused on 1.
8.x, but work on 1. 9.2 is also in progress. The reason for RubySpec failure can vary. It could be a problem with the test case, it could be a bug with MSpec (RubySpec's test driver), it could be a bug with 1.
9.2, or it could be a problem with the language specification itself. The wide range of failure points is the largest roadblock to the release of 1. 9.2. However, it is important for 1. 9.2 to pass RubySpec; it shows that 1. 9.2 is as stable as 1. 8.6. - Q： What are plans for Ruby after 1.
9.2? A： There is no definite plans, since 1.
9.2 is not released yet. The features that had been planned for 1. 9.3 are now included for 1. 9.2. Mr. Sasada, the developer of YARV, said that he would like to introduce MVM around 1. 9.5. There are some general ideas for Ruby 2. 0, but there are no plans at all as to which features are going to be implemented when. - Q： How can people contribute to the development of 1.
9.2? A： Bug fixes would be greatly appreciated. You can find plenty of open bug reports on the official bug tracker. so please submit patches to the ruby-core and the ruby-dev mailing lists.
Of course, there are other ways to contribute. We would like Ruby to run on as many different environments as possible, but there are many environments that are not available to the core developers, such as Mac OS X on PowerPC. Building and testing Ruby in such environments and sending us build reports would be of great help. We are thinking about standardizing such build reports. Also, contribution to documentation projects such as the "Ruby Reference Manual (RuReMa)"
[1] is also welcome. I also encourage contributing to RubySpec, by running it on 1. 9.2, finding and fixing bugs.
Ruby "Project"
- Q： How do you track problems and bugs?
A： We use the mailing lists and the official bug tracker. I personally check "Hatena Diary" （※2） and other blogs, and occasionally the questions posted on "OKWave" （※3）
. If I find anything, I add it to the official bug tracker. Threads on 2ch （※4） used to be a frequent source of bug reports. Fortunately, 2ch denizens have lately encouraged posters to add bugs directly to the bug tracker, which has saved me a lot of work. Which reminds me, I once received a good suggestion in a thread called "The Anti-Ruby Thread"! 
To make sure that we won't miss anything, please file suggestions and bug reports on the official tracker.
- Q： Does anyone ever raise objections to Are there cases where objections are raised against Matz's proposals?
A： Because Matz's role is mainly the design of Ruby's grammar, he usually remains quiet when it comes to the details of individual libraries.
There are occasionally disagreements between Matz and other contributors over changes to grammar and core libraries. In such cases, Matz can be convinced with sufficiently logical arguments.
For example, once Matz changed nil.
to_ s to return nil instead of an empty string. This was, however, very inconvenient when performing simple text manipulation in Ruby. After being presented with several examples from the community, he was convinced to revert the change. In general, however, Matz's language design ideas are superb and, ultimately, most are both well thought out and convincing. For instance, in 1.
9.x, you can use "->" can be used as a synonym for anonymous functions (lambda). I was initially against this syntax, but once I got used to it, it was very convenient. Ultimately, it turned out to be a good idea. - Q： As the release manager, what did you learn from the Ruby development project?
A： I learnt that it is a waste of time to discuss ideas without a working example. Always deal with working code. Also, it is impossible to do release management without knowing what each member of the dev team is doing. The manager must possess sufficient technical ability to understand what each team member is doing. I think the Ruby project is going smoothly because I have managed to accomplish this.
I also learnt that the manager doesn't have to be the team's ace, either. One reason I became the release manager was because no one else wanted to do it! Of course, I like Ruby, so I want to see it become even better. That is my motivation for contributing to the development of Ruby. Having said that, if you want to develop Ruby, you have to possess a certain level of competency. We can't have the release manager, for instance, not knowing what an "int" was!
- Q： Why do you think that the development of Ruby is going so well? What can other projects learn?
A： To be honest, Ruby became what it is today, not by design or plan, but by pure accident; the right volunteers just happened to join, and before we knew it, it grew to become the project it is today. We were also fortunate to have contributors who were interested in maintaining tests and using continuous build integration. However, I do understand that in business situations you cannot rely on such accidents. It is, then, important to implement source code version control and write tests in order to maintain working code.
"A New Revolution" by Ruby 1.9
- Q： The Ruby community, with it's strong emphasis on testing, has been closely intertwined with te Agile/
XP movements. Why Ruby? A： I think it is partly because leading figures in the Agile/
XP movements, such as Dave Thomas and Martin Fowler, like Ruby. I also think that Rails contributed significantly to this aspect of the Ruby community. Merb core developer Matt Aimonetti, in his blog entry "The Ruby Revolution is Over"
[5] , wrote that Ruby and Rails had changed the world. That coding should be fun, and that testing is important, are now widely excepted ideas. I, too, believe that Ruby has finally joined the ranks of the major languages, thanks to Ruby 1. 8.x and Rails. In 1.
9, we implemented multilingualization with a CSI approach. I believe that this approach, too, may eventually become an unsurprising, standard choice. Looking further ahead, MVM, Classbox and other new architectural changes are planned to be included. Ruby will continue to get better and better. Perhaps another library will manage to take full advantage of Ruby's flexibility, not unlike Rails, and bring about yet another revolution.. Ruby 1.
9 is a great new version of Ruby that fixes much of the awkwardness in Ruby 1. 8.x. We do not anticipate major changes leading up to 2. 0; so migration from 1. 9 to 2. 0 should be much easier than from 1. 8 to 1. 9. If you are maintain any Ruby libraries, we encourage you to migrate to 1. 9. If you are a Ruby user, you can already run 1. 9. The next revolution won't be on 1. 8. Rather, it will be on Ruby 1. 9.
- プロフィール
Yugui
（Yuki Sonoda） The release manager of Ruby 1.
9 series. MtF-TS. She wants to bring more value from the base reality to other realities and develops softwares for the purpose. She is developing an ad distribution engine for Scaleout Inc..