To answer a question on RubyTalk the other day, I had to reference Mauricio Fernandez’s nicely compiled list of Changes in Ruby 1.9. While I was there I took another walk through the whole thing.

There are of course some features I *don’t* like.

a = ->(b,c){ b + c }
 a.call(1,2) # => 3

But there are quite a few that I do, and here I’ve listed ten I think will totally rock. I use Mauricio’s examples, so all credit goes to him. Also, this article is from February, so if you find any features below that have changed, shout and I’ll update.

Nice introductory tutorial on Rake from the guys @ Rails Envy, which provides a brief history, introduces concepts such as tasks and namespaces and talks about its role within Rails.

It really makes me happy to see the increasing international interest in Rails and in Ruby. As I reported earlier, the official Ruby site is available in many languages (currently English, French, Japanese, Korean, Polish and Spanish), with more in the works. My original Rolling with Ruby on Rails was translated into Japanese, French, and Spanish. And now Bill Walton’s updated version of Rolling with Ruby on Rails has been translate to Brazilian Portuguese thanks to Gabriel Bogéa Perez!

Of course there is much more. If you know of Ruby and Rails resources in other native languages, please post the links in a comment and tell the rest of us about it!

Consider this fact: Multi-core CPUs are not only the future, they’re the only way CPUs can continue to grow at their current pace. It’s also a hotly debated subject in the software world. Multi-threaded programming is different and not seen as often as procedural programming, and therefore it’s not yet as well understood. So the question is, how can programming languages (and Ruby in particular) make it easier to harness these systems?

As Ruby struggles to graduate from its current implementation into something more powerful, we’ve already seen several projects attempt to update Ruby to help developers cope. Those who’ve been working with Ruby for awhile may remember YARV, which promises to provide more threading support. JRuby offers all the power of Java’s threads to Ruby, if it can harness it. And Evan Phoenix’s small but rapidly growing project Rubinius is attempting to be the next big contender.

No matter what implementation becomes the next de-facto Ruby platform, one thing is clear: People are interested in taking advantage of their newer, more powerful multi-core systems (as the recent surge in interest in Erlang in recent RailsConf and RubyConfs has shown). As Ruby becomes increasingly part of solutions that deal in high volumes of data processing, this demand can only increase.

That’s why it’s so very surprising to see David Heinemeier Hansson dismiss the whole notion out of hand regarding Rails. His argument seems to be that Rails already scales to multiple cores in the same way it scales to multiple machines, via UNIX process distribution. After all, isn’t this the very crux of “Share Nothing?”

We’ve got yet another project announcement to share, as Google’s Summer of Code begins to pick up steam. The following announcement is from Andreas Launila about his project Gecode/R. Andreas is pursuing a masters in Computer Science at KTH (The Royal Institute of Technology - Sweden).

Here’s an open question that I’m hoping will get some interesting discussion going:
Why are there so few Ruby jobs out there?

Those of you who have been to RubyConf in recent years have been asked the question “How many people get paid to write Ruby?”, and you’d see that in the last year or two, the number of people who raise their hand has absolutely skyrocketed.

However, at Gotham Ruby Conference, someone asked “How many people are paid to write plain Ruby, no Rails”. I think like 3 hands went up, and I was one of them, out of 120 or so people. It’s possible that we just have a lot of Rails work in NYC, but I think the issue might be deeper than that.

I’ve seen so many of my friends say “Oh, I’d rather be writing pure Ruby, but at least working in Rails gets me close to that, and it’s better than working in <insert_language_here>”.

Is Ruby really only viable for database driven web applications? I doubt it. I think it can stand its ground anywhere Perl or Python could. So why is it that most job postings you see are for some sort of “Web Rockstar”, and not like, a sysadmin with scripting experience, or an internal applications developer?

I guess it could be a lot of things, any of the below or a combination might be to blame:

• Lack of good marketing for non-web oriented Ruby
• Assumption that Ruby is not general purpose as a side effect of the success of RoR’s marketing
• Technical issues that I can’t think of that make it an inferior choice to other languages
• Ruby adoption might be in nature slower than Rails adoption, but on it’s way
• MRI isn’t robust enough for the ‘enterprise’, so companies are waiting on JRuby

I don’t really know what it is. I understand when corporate politics get involved, all things go out the window, but I think that Ruby’s success as a commercially viable language outside of Rails is less than what it should be at this point. Do other people feel the same way?

UPDATE: Buried deep within the mixed replies to this post is a great writeup by Andy Peters which states more assertively what I was implying here…

I was not mowing my lawn like Gregory, but I was reading this blog when I got an idea for a Rails version of the Ruby Project Spotlight series Gregory is spinning up.

The idea is that I’ll post an entry once or twice a month about a new and active Rails project that’s looking for more exposure. The project can be a gem, a plugin, an open source Rails application: basically anything that’s related to Rails. The process for getting a project mentioned is simple: send me an e-mail about your project. It should follow these simple rules:

• Keep it fresh — I’d rather not look at code from pre-Rails 1.0 or that’s been sitting on Rubyforge for 11 months with no activity.
• Keep it real — Project should be released before the time I post.
• Keep it brief — A code sample, a project link, and up to two sentences of commentary is all I need.
• You must be a developer on the project. (Sorry. No clever phrase for this one.)

The rules are so specific because the coverage is plentiful of things that don’t fit within them, but a lot of the newer and (usually) more interesting projects aren’t really gaining the exposure they need to get a flourishing community to spring up around them.

So, if you’re a developer on one of these projects, e-mail me your submission by June 30th. I’ll judiciously pick through them and make my rather subjective choice for July soon after. Hopefully this can bring some really cool Rails projects some exposure, and expose our readers to tools and projects they can make use of.