The Future of Ruby: a RubyConf Recap
blog.bignerdranch.com
blog.bignerdranch.com
It is not the universal feeling within the Japanese ruby community that your inability to read technical Japanese morally obligates them to spend their time translating technical Japanese into English for you. It is not the universal feeling within the Japanese ruby community that this question deserves an answer phrased that politely, either. (cough "Technical documentation written only in a foreign language? That must be tough." cough)
Although I do speak more English than Dutch in the workplace, I would never expect it - rather, I am grateful for the allowances made for me.
Community fragmentation caused by language differences is going to be super tough to fix. Any thoughts on a solution?
(I'm not intimately familiar with the field anymore, but my rough guesstimate is "A fifth the cost of them in San Francisco on an hourly basis, about a third the cost of them in Tokyo.")
(Now I find myself wondering which I've memorized more of: Japanese words or Ruby keywords and names.)
Those interested in doing anything "serious" seem to be doing it on jruby. Real threading seems to be a much requested/needed feature for many Ruby projects, but Matz has indicated quite clearly that he is not interested in removing the Global Interpreter Lock (GIL) from MRI ruby. Which is fine, as his he doesn't want the hard threading problems to be exposed to ruby coders.
Its kind of a shame that the jruby guys aren't a bigger part of the conversation on new features and the future of the language. But it is quite understandable when you look at the way ruby has been used in the past, and the direction that people are taking it in the future.
But I'll say that being outside the mainstream isn't necessarily a bad thing when so many gems rely on C extensions that tend to be flaky. Watching proceedings for any ruby conference a reoccurring theme is that people doing things that everyone is interested in tend to be doing it on the jruby implementation.