Ruby Fuzzy Edition

Antes de mais nada, um personal disclaimer: eu sou um cara que aprendeu Ruby com a MRI e que gostou logo de cara da comunidade em volta do Ruby (pelo menos na época – alguns canais de IRC hoje são simplesmente insuportáveis), então eu sou o cara mais suspeito do mundo para emitir opinião sobre outras implementações sem ser a MRI.

Por mais que hoje em dia haja um certo burburinho sobre o jeito que Matz e cia. tocam a coisa, eu ainda acho que é um jeito bem consistente. Aprender a gostar e confiar na linguagem e nas pessoas que a fazem é uma coisa muito forte.

Dito isso, o assunto desse artigo é a Ruby Enterprise Edition. Alguns outros sites daqui e do exterior já deram uma descrição muito boa do que ela é e do que ela se propõe, mas no meio do hype começaram a aparecer algumas opiniões meio ácidas, gente ficando irritada e alguns “chutes” sobre o que está acontecendo, o que em minha opinião só traz mais barulho – do ruim – para o assunto, desnecessariamente.

A coisa começou a ficar mais estranha depois de um post do Magnus Holm, chamado Ruby Fish Edition. Nesse post, o Magnus meio que acusou a galera que desenvolveu o Ruby Enterprise Edition de aplicar alguns patches na MRI e fazerem um marketing agressivo em cima da coisa, meio que deixando parecer que eles haviam criado tudo e não somente aplicado alguns patches. Vale lembrar que eles fizeram os patches e os enviaram para a apreciação dos devenvolvedores da MRI, como pode ser comprovado pelos emails da Ruby-core, onde discutiram sobre benchmarks e eficiência.

Eles disponibilizaram os patches livremente, mostraram o que fizeram e o que acreditam que seria a melhor solução. E, ver para crer, eles tem o site da Ruby Enterprise Edition que é disponibilizada livremente (as in speech) e o site do Phusion Passenger, que também é disponibilizado livremente, com a opção da Passenger Enterprise License, que, como eles mesmos citam no site, nada mais é do que uma doação para o projeto, onde você doa o que quiser. As doações na Sourceforge funcionam faz muito tempo e ninguém cria caso por causa disso. Todo mundo tem as contas para pagar e uma doação é uma coisa que realmente ajuda. Por isso que eles também tem suporte comercial. Vejam bem, nós fazemos código livre (e grátis) mas acredito que ninguém é um hippie que volta para casa da árvore no final do dia.

Depois dos emails iniciais trocados na lista, a coisa deu uma reduzida no ritmo. Alguns mencionaram motivos como “razões não-técnicas”, “ciúmes” e outras coisas do tipo, mais por chute do que tentando pensar um pouco sobre o que aconteceu. Vejam bem: não estou defendendo uma forma de censura, mas eu realmente fico incomodado com esse tipo de comportamento em uma comunidade (isso tá parecendo papo hippie) tão legal como a de Ruby. Depois do catalisador Rails, parece que aumentou muito esse tipo de coisa, mas enfim,é um preço a pagar.

Curioso sobre tudo isso, resolvi entrar em contato com as partes envolvidas.

Mandei um email para o Magnus, mas ainda não obtive resposta.

Mandei alguns emails para o Hongli Lai e trocamos algumas idéias sobre o que estava acontecendo. Ele confirmou as minhas suspeitas: após os emails trocados na Ruby-core, eles ficaram meio que de saco cheio para esperar alguma resposta da turma do MRI e criaram o seu próprio fork, afinal, os caras estavam animados e trabalhando a mil. Copiando algumas partes dos emails trocados com ele:

One of the reasons why we released Ruby Enterprise Edition is indeed so that we don’t have to wait for the copy-on-write patches to be integrated into upstream … So we decided that, for the time being, it would be best to maintain a fork that’s closely related to the upstream version, but with our changes applied.

Aí resolvi entrar em contato com o Matz sobre todo esse “auê”. Como eu desconfiava, eles consideraram os patches, mas estão bem ocupados (se alguém duvidar que pegue os Changelogs das séries 1.8 e 1.9 para confirmar) com outras coisas, inclusive vão trabalhar em melhorar o bitmark marking. Mas não agora. O Matz também tem algumas considerações sobre o uso do tcmalloc. Apesar de eu ser utilizar GNU/Linux durante todo o tempo, se eu fosse responsável de uma linguagem multi-plataforma eu também ficaria meio apreensivo lendo algo como

For some systems, TCMalloc may not work correctly on with applications that aren’t linked against libpthread.so (or the equivalent on your OS). It should work on Linux using glibc 2.3, but other OS/libc combinations have not been tested.

Vejam bem: não estou falando que a Ruby Enterprise Edition não é segura e que o TCMalloc não é bom. Não é isso. Mas como disse acima, se eu fosse responsável por uma coisa do tamanho de Ruby eu listaria minhas prioridades e colocaria os patches recebidos, mesmo que tratassem de coisas “quentes”, em uma posição para serem muito bem analisados e testados. Não é porque eu, você ou Papa que mandamos um patch para lá dizendo que está tudo ok e que é a próxima maravilha da linguagem que eles vão incorporar na hora. Enquanto que para uns isso possa parecer paranóia, para outros é responsabilidade. Para alguns pode parecer lerdeza, para outros, prioridades.

A parte legal de tudo isso é que se aprende e discute um pouco (ou muito) com todas as outras implementações (como JRuby, Rubinius, IronRuby (m$! argh!), MacRuby, Maglev), mas como falei no começo do artigo, eu me mantenho com o pessoal da MRI, pela confiança no que eles fazem. Não estou também dizendo que as outras implementações não sejam confiáveis, mas que pelos anos acompanhando a MRI eu tenho total confiança nos seus desenvolvedores. Espero que esse post traga alguma luz sobre os mistérios do fork Ruby Enterprise Edition. Com certeza, por razões não-técnicas é que não foi a razão pela qual os patches não foram aplicados na MRI. Se uma boa análise de código não é razão técnica, não sei o que pode ser. Vamos evitar criar polêmica desnecessária. Vamos é fazer código! 🙂