O que muitos me perguntam é: “Já posso usar Ruby 1.9 em produção?” E a resposta curta é: “Sim.” A resposta longa, como sempre, é “depende.” O Ruby on Rails, por exemplo, acabou de ganhar uma atualização para 2.3.5 onde ganhou mais correções e ajustes para torná-la mais compatível com a 1.9. Mas ainda restam as centenas de gems que precisamos. Se seu projeto tem testes, experimente rodá-los com o Ruby 1.9, se tudo passar a chances são boas que vai funcionar. Para facilitar pesquise sites como o Is It Ruby 1.9. Use tecnologias como o RVM que permite instalar diversas versões diferentes de Ruby em paralelo na sua máquina de desenvolvimento para testar sua aplicação.
Fora isso existem as implementações em paralelo. Graças ao projeto Rubinius iniciou-se um projeto complementar chamado RubySpec que hoje é amplamente utilizado pela maioria dos outros projetos para tentar garantir compatiblidade funcional entre as diversas implementações. Vale a pena entender e colaborar para esse projeto. O Rubinius está em Beta 1. Ele ainda não é 100% completo e está em desenvolvimento pesado, mas é um dos projetos mais promissores. A idéia é implementar o máximo possível em Ruby puro em vez de usar tantas extensões em C por causa de performance. Vale a pena acompanhar de perto esse projeto.
A que está mais madura, robusta neste momento é de longe o JRuby, que oferece mais compatibilidade e diversas vantagens graças à JVM, como threads nativas, suporte nativo a UTF-8, etc. Porém ela tem a mesma desvantagens das outras implementações: incompatibilidade com gems que dependem de extensões nativas.
Muitas gems, por performance, vem com código-fonte em C. Quando a gem é instalada esse código é compilado numa extensão binária. Por causa disso virtual machines isoladas como a JVM, o CLR do .NET, e qualquer outra, precisa de uma “ponte” para falar com o binário. Um dos projetos que tenta solucionar esse problema é o FFI. Ela é a única solução, mas ainda é considerada de baixa performance. Esperamos que ela evolua. Existem sites como o Is It JRuby para tentar facilitar encontrar gems compatíveis.
Para entender mais sobre JRuby, o Tom Enebo, um dos mantenedores, acabou de publicar um artigo explicando as vantagens e desvantagens, tecnicamente, de usar JRuby. Vale a pena entender o que você ganha com a JVM.
A outra implementação que me parece mais promissora é o MacRuby liderada pelo excepcional Laurent Sanzonetti dentro da própria Apple. Ela ainda está na versão 0.5 beta 2. Em vez da JVM aqui a idéia é tirar proveito do backend em Objective C que a Apple vem amadurecendo faz anos, incluindo novas tecnologias que saíram no Snow Leopard como o Grand Central Dispatch, que permite tirar proveito de múltiplos cores de maneira muito mais simples do que usar threads diretamente. Uma das pessoas mais empolgadas com o projeto é o Rich Kilmer que está à frente do projeto HotCocoa. O objetivo é tornar ultra-trivial escrever aplicações com look-and-feel nativo de Mac usando uma poderosa DSL em Ruby com MacRuby. Mais ainda, um dos objetivos do MacRuby é ter velocidade praticamente idêntica à de Objective-C puro. Isso deve tornar o desenvolvimento de aplicações Mac muito mais simples.
O MRI tem um fork, mantido pelos garotos da Phusion, a mesma que nos trouxe a excelente solução Passenger também nos trouxe o Ruby Enterprise Edition. Atualmente ele é um fork do MRI 1.8.7. A diferença é que eles aplicam patches que otimizam o uso de memória. Dependendo do uso, podemos ter ganhos reais de mais de 30% no uso de memória e até mesmo mais performance. Ele é largamente usando em produção, é totalmente compatível com o MRI, incluindo com as extensões nativas das gems. Considere o REE como um MRI ++. Vale a pena usá-la, sem preocupações.
O JRuby ganha as vantagens da JVM, o MacRuby ganha as vantagens da plataforma Objective-C, mas há outras plataformas. A que está mais próxima de se tornar estável é o IronRuby, implementado sobre a CLR do .NET. É outro projeto promissor especialmente para usuários de Windows e de Mono. Neste estágio ele já é capaz de rodar algumas aplicações de Rails. Imagino que, assim como MacRuby, ele se torne importante também para desenvolver aplicações Desktop usando Ruby somado a WPF e também para Silverlight/Moonlight. Se você é desenvolvedor hardcore de C#, não deixe de apoiar o projeto.
Outra plataforma promissora é a mais do que madura Smalltalk, especificamente da Gemstone. O projeto é o Maglev. Ele ainda não está estável, já roda algumas coisas em Ruby, pequenas aplicações em Sinatra. Ela pretende explorar o potencial do Smalltalk para rodar Ruby. Não imagino que ela se torne 100% para rodar qualquer aplicação Rails, por exemplo. Mas o intuito é outro: tornar disponível a programadores Ruby as maravilhas do seu robusto repositório de objetos. Em uma época em que estamos falando tanto de NOSQL, bancos de dados não-relacionais, pode ser uma excelente hora para voltarmos a falar de bancos de dados verdadeiramente orientados-a-objetos.
No campo mais experimental, temos o BlueRuby, particularmente interessante para mim que fui programador ABAP/4. Para quem não sabe, ABAP é a linguagem 4GL que equipa o gigantesco pacote de aplicações corporativas da SAP. Com décadas de maturidade não existe outra plataforma na indústria que se compare. O ABAP em si mostra sua idade, com uma cara meio de COBOL. A idéia, novamente, não é fazer qualquer aplicação Ruby rodar em SAP, mas sim de dar uma alternativa mais elegante para a nova geração de programadores corporativos.
Dois outros projetos que eu não conheço muito bem são o SmallRuby, que é o mais recente de todos e também pretende implementar Ruby com Smalltalk, mais especificamente para a plataforma Smalltalk/X. Outra é o REIA uma prova de conceito de implementar a sintaxe de Ruby sobre a plataforma Erlang. Assim como no caso do BlueRuby, também não se busca 100% de compatibilidade mas sim uma forma de expor o potencial de multi-processamento do Erlang para uma nova geração de programadores que não gostam muito da sintaxe do Erlang. Vale a pena explorar.
Eu imagino que o Ruby é a linguagem com um dos maiores números de implementações alternativas em plataformas tão diferentes. Via de regra, dê preferência ao MRI Ruby 1.9. O Matz deve lançar a 1.9.2 até o ano que vem que, teoricamente, será a última da série 1.9. A partir daí o Ruby Core Team deve voltar seus esforços para a versão 2.0.
No dia a dia de desenvolvimento, pode continuar usando as versões 1.8.7 que vem instaladas nas diversas distros. Em produção com Linux, recomendo muito usar o Passenger somado ao Ruby Enterprise Edition para máxima performance. Mas o 1.9 também já pode ser usado com o Passenger em produção.
Se você tem bibliotecas legadas em Java, precisa se integrar com sistemas que só tem drivers/adapters em Java, não hesite: JRuby é maduro, robusto, completo e roda nos servidores de aplicação que você já conhece: Jetty, Tomcat, Glassfish, JBoss. Pode usar sem medo.
Se quiser desenvolver aplicações para Mac vale muito a pena já usar o MacRuby, mesmo se for a 0.5 RC1 com HotCocoa. Aplicações como o 1Password por exemplo já são feitas em MacRuby (versão mais antiga, acho que 0.3, e não era HotCocoa, mas RubyCocoa). Para .NET acho que já dá para começar a desenvolver com IronRuby, especialmente se for aplicação para Desktop.
Rubinius, BlueRuby, Maglev, SmallRuby, Reia, ainda não estão prontas. Mas a sensação é que em 2010 a maioria delas terá atingido estágio de “pronto o suficiente”. Portanto vale a pena acompanhá-las de perto.
O horizonte de desenvolvimento Ruby está crescendo, rápido, não fique de fora disso!