A Távola Redonda se Reúne!

2008 April 22, 16:00 h - tags: ruby obsolete

Ontem, dia 21/04, os principais responsáveis por implementações Ruby se reuniram para uma reunião de kick-off via IRC. O log e o resumo podem ser lidos no wiki do ruby-design.

Estiveram presente a equipe Ruby-Core japonesa, com Matz, Koichi, Nobu, Tanaka (não estava o knu, que é o responsável hoje pelo 1.8, o Matz e Koichi estão focados no 1.9). O pessoal do JRuby, Charles, Thomas, Ola. O Evan do Rubinius, o Laurent do MacRuby (implementação de Ruby feita em Objective-C). Outros poliglotas como Eric Hodel, MentalGuy, Nick Sieger. Só o John Lam, do IronRuby não pode aparecer desta vez.

Esse encontro parece que foi organizado pelo próprio Matz, deliberado principalmente pelo Charles e Evan (se Matz é o Rei Arthur, Charles seria Lancelot e Evan, Galahad :-).

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.

Comments

comentários deste blog disponibilizados por Disqus