Porque o Rubinius é importante.

Muita gente já falou sobre o assunto, e eu percebi, até agora, que não dei minha opinião então…

Para as pessoas que estão interadas, Rubinius é uma implementação de Ruby sobre Ruby. Parece estranho, e é um pouco mesmo, então vale a pena mostrar mais como isso funciona. Nos outros interpretadores, uma boa parte das classes padrão da linguagem são implementadas em C (ou Java, no caso do JRuby). Em Rubinius, estas classes são implementadas em Ruby sempre que possível, e a máquina virtual (VM, atualmente estão usando o LLVM) é extremamente simples e otimizada. Com isso, além de Ruby ficar muito mais flexível (mais? sim, é sempre possível) ainda se ganham alguns conceitos interessantes. Para fazer esta “mágica”, é necessário um compilador que traduz código Ruby para bytecodes que serão executados na LLVM – e Rubinius escreveu este compilador totalmente em Ruby. Pode parecer um conceito absurdo, mas não é – o próprio compilador C da Gnu, o GCC, é escrito em C.

Com a maior parte de Ruby escrito em Ruby, ganham-se além de mais classes “nativas”, uma série de possibilidades interessantes – especialmente, para estender a linguagem ou criar DSLs. Inclusive, digamos que se o próprio interpretador de Ruby é escrito em Ruby, porque não criar uma classe que herda do compilador, e então usá-la para criar uma nova linguagem? Mas isso é só o começo: o próprio time desenvolvedor já citou “Pluggable Garbage Collectors”, ou seja, o sistema de Garbage Collect de Ruby poderia ser alterado, em tempo de execução. É possível imaginar uma linguagem que, em tempo de execução, altera-se desta forma? Mas calma, isso não é tudo…

Os próprios desenvolvedores já citaram em seu blog algumas otimizações que eles tem conseguido fazer. Hoje, em meus testes, o Rubinius tem quase a mesma velocidade do Ruby 1.9, e no final do artigo eles citam que apenas estão começando a estudar o que pode ser feito. Mas temos que lembrar uma coisa: é Ruby, uma linguagem simples e mais fácil de programar do que C ou Java, portanto códigos de otimização que ficariam extremamente complexos nessas duas linguagens provavelmente serão mais simples de serem feitos em Ruby. Além do que, o código deles é muito bem-feito, muito claro, e elegante. Por exemplo, eu descobri um bug na função de randomização, e mandaram uma mensagem falando que havia um erro na forma como era feita a randomização, inclusive com o código-fonte, que é o que segue:

def rand(max=0)
   max = max.to_i.abs
   x = FFI::Platform::POSIX.rand

# scale result of rand to a domain between 0 and max
   if max == 0
     x.to_f / 2147483647.0
   elsif max < 0x7fffffff
     x / (0x7fffffff / max) # <- this is the problem line
   else
     x * (max / 0x7fffffff)
   end
 end

O problema já foi corrigido, por sinal, mas achei interessante a experiência de olhar para como algo é feito no interpretador sem precisar navegar por códigos C. Mas apesar de todas essas vantagens, ainda há um motivo maior pelo qual o Rubinius é importante, e acho que tudo pode ser explicitado em uma só palavra:

Portabilidade.

A LLVM é portável. Uma parte muito pequena do Rubinius é escrito em C/C++, e a maior parte dela é só para garantir compatibilidade com bibliotecas C. Além disso, Rubinius é rápido – MUITO rápido. Logo, portar Rubinius para um sistema operacional de celular é muito mais simples do que portar as implementações “padrão” (e eu estenderia isso até para o JRuby – todos nós sabemos que o Java não é tão portável assim, não sabemos? Tente criar um aplicativo Java ME). Já há um colega meu tentando portar Rubinius para rodar usando bibliotecas tipo o nVidia CUDA, para processar códigos Ruby em placas de vídeo. Além disso, Rubinius acaba com a frase “Ruby é Lento, portanto não serve para nada” ou algo semelhante (até mesmo porque, depois de programar bastante com a linguagem, eu assumo – Ruby é lento, mas você não sente ele lento em momento algum). Com uma implementação mais rápida, talvez também quem cria gems deixaria de usar extensões em C/C++, o que traria ainda mais portabilidade. Há ainda algumas pessoas que acreditam que, no futuro, Rubinius vá substituir a implementação padrão. Embora eu não colocaria minha mão no fogo por isso, é algo que também não podemos descartar.

O futuro das implementações Ruby parece mais promissor do que nunca!