Rumo à paridade de implementações
Dentre os principais assuntos discutidos o que me chamou a atenção pela importância foi o pedido ‘formal’ de benção do pacote de suíte de rspec do Rubinius como o suíte oficial. Ou seja, para que o MRI e o YARV sejam testados também contra esse suíte de forma que todas as implementações sejam compatíveis entre si. O IronRuby, JRuby, Rubinius já usam, só faltava mesmo o apoio oficial do Matz para colocar o pacote para rodar contra o trunk tanto do MRI 1.8 quanto 1.9.
Quando começaram a discutir a versão 1.8.7-preview, chegaram a um problema que todos nós já enfrentamos: erros de regressão. Coisas que funcionavam na versão 1.8.6 e quebraram na 1.8.7 sem precisar (não é uma feature).
Ao que parece o pessoal do Ruby Core é um pouco menos disciplinado em termos de robustez em testes e especificações do que o pessoal do JRuby/Rubinius. Mas acho que sendo otimista está se caminhando para fazer o MRI também se adequar ao que todos os outros estão usando, inclusive com RSpec em vez de RUnit.
O pessoal do Ruby Core está um pouco receoso de como essa migração será feita. Eles também não tem muito domínio de RSpec, mas o Evan e o resto do pessoal se prontificou a auxiliar o máximo possível. O próprio Charles estará no Japão daqui 2 meses e mais sprints deverão acontecer no local.
Isso é extremamente importante porque teremos alguns resultados muito relevantes. Antes de mais nada está se caminhando para a adesão de uma metodologia de desenvolvimento que o Charles já incorpora no JRuby e que garante muito menos bugs e mais velocidade na resolução de bugs. Isso garantiria releases de MRI/YARV muito mais estáveis no futuro.
A segunda coisa é, claro, a esperada paridade de funcionalidades entre todas as implementações de Ruby paralelas ao MRI. Uma vez o MRI passando nas mesmas suites que o JRuby e os outros já passam, nossos códigos de aplicação teriam muito mais chance de rodar em qualquer uma delas.
A discussão é interessante porque eles ainda estão discutindo como fazer para fechar as pontas no 1.8 e como criar um procedimento para cobrir o 1.9
Multi-VMs
Como anunciamos algum tempo atrás no episódio 7 do podcast, a Sun está colaborando com a Universidade de Tokyo para o desenvolvimento de suporte de múltiplas VMs no Ruby.
Isso tem tudo a ver com a técnica do pessoal do Phusion que expliquei neste post. A idéia é que uma virtual machine Ruby seja capaz de ou fazer spawn (subir novos processos independentes), ou fork (cópia do processo atual) ou suba sub-vms em threads nativas (approach do Rubinius e JRuby). Cada uma delas tem dificuldades.
Pense num mongrel cluster. Agora imagine um mongrel cluster controlado por uma primeira VM-pai que gerencia novas VMs filhas. Agora imagine uma instância Ruby como essa rodando lado a lado dentro da mesma VM-pai. Esse é o desafio do Multi-VM.
Atualmente o JRuby tem uma implementação funcionando mas não tem uma boa API (é dependente de muita coisa do Java). O Rubinius tem uma API razoável mas ainda só tem uma implementação experimental. A idéia é unificar esforços, criar uma API única que tenha a bênção do Matz. Essa discussão ainda vai prosseguir na lista do Ruby Core.
Multi-VMs tem a ver com thread-safety, mas é complementar. A idéia é importante quando falamos de lightweight-processes, como actors, em linguagens como Erlang. Em determinados cenários, é muito mais vantajoso (simples de entender e dar manutenção) em múltiplos processos do que múltiplas threads. Novamente: thread é importante, mas não é a única solução e nem necessariamente a melhor.
Conclusões
Essa reunião não é a primeira que junta um pessoal do calibre desses participantes e tem sido extremamente importante principalmente envolver o pessoal japonês para que tudo aconteça com coerência e transparência. Nenhum deles tem o objetivo de ‘substituir’ o MRI, pelo contrário, a idéia é criar mais alternativas aos desenvolvedores. Para isso é muito importante que o desenvolvedor não precise ficar criando gambiarras de casos especiais para cada VM. O ideal é que o mesmo código Ruby rode em todas as VMs sem modificação.
Além disso está se estabelecendo alguns workflows e boas práticas de como gerenciar projetos open source desse tipo. Uma coisa crucial: specs e testes. É o que tem garantido que eles caminhem em conjunto. Cada decisão importante é tomada entre os stakeholders do projeto, novos objetivos são traçados e documentados no Wiki do grupo. É um tipo de processo Agile informal acontecendo em tempo real e que podemos observar.
Com o tempo deveremos ganhar VMs mais robustas, estáveis, compatíveis, com bom suporte de documentação e testes. Só temos a ganhar.