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 post é a Ruby Enterprise Edition. Alguns outros blogs 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! :-)

E agora apenas um rápido toque: o Hongli Lai e o Ninh Bui vão estar no Rails Summit Latin America, nos dias 15 e 16 de Outubro, em São Paulo. Eu vou (até já paguei), vocês vão? :-)

English Version

Just a personal disclaimer before talking about all this stuff: I'm a guy who learned Ruby with MRI and loved the Ruby community at first sight (at least when I started - nowadays there are some annoying IRC channels), so I'm a kind of suspicious to talk about other Ruby implementations. There are some opinions of the rhythm Matz and the MRI guys develop MRI, but I still think it's a consistent way. Learn to like and trust a language and the people who develop it it's a very strong thing.

Said that, the reason of this post is Ruby Enterprise Edition. Some other blogs already gave some good explanations about what it is and what is it purpose, but among all the hype started some acid opinions, people going angry and some guessing on what is happening, what in my opinion just bring some more - bad - noise, unnecessarily.

Things became more weird after a Magnus Holm post called Ruby Fish Edition. On that post, Magnus kind of accused the Ruby Enterprise Edition developers of apply some patches on MRI and make some aggressive marketing about it, maybe trying to give the idea they created all the stuff. We must remember that they made the patches and send it to the MRI guys, as can be proved for some emails on Ruby-core mailing list, where they discussed about benchmarks and efficiency. They made the patches aviailable freeley, talked about what they did and what they believe it's the best solution. And, seeing is believing, they keep the Ruby Enterprise Edition web site, which is freely available (as in speech) and the Phusion Passenger web site, which it's also freely available, with the Passenger Enterprise License option, which is, as they say, nothing more than a contribution for the project, where you donate the ammount you want. TheSourceforge donations work for a long time and nobody complains about it. Everybody has bills to pay, and a donation is something that really helps. That's why they also have commercial support. We made free (and gratis) code, but I think that nobody is a hippie that returns for the tree house on the end of the day.

After some emails on the mailing list, things slowed down. Some guys talked about some reasons like "non-technical reasons", "jealousy" and some other things like that, more trying to guess what was happening than thinking a little before talking about it. See: I'm not saying that we need some kind of censorship, but this kind of behaviour on a cool community (this is really looking like some hippie talking) like the Ruby communit really annoys me. After the Rails cataliser, seems this kind of behaviour increased, but, that's a price to be paid.

Curious about all that stuff, I decided to contact people involved.

I emailed Magnus but still had no answer.

I emailed Hongli Lai and we talked about what was happening. He confirmed my deductions: after some emails on Ruby-core, they were kind of boring waiting some answer and forked MRI. After all, they were excited and working fast. Let me copy some parts of the emails:

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.

So I emailed Matz about all that fuzzy stuff. As I suspected, they considered the patches, but are very busy (if there is any doubt about this just check the Changelogs of the 1.8 and 1.9 series) with other things, and they will work to make bitmark marking better. But not now. Matz already told me there are some considerations about the use of tcmalloc. Despite the fact I'm a full time GNU/Linux user, if I was responsible for a multiplatform language I'd be a little apprehensive reading something like

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.

See, I'm not saying that Ruby Enterprise Edition is not safe and TCMalloc is not good. But as I told before, if I was responsible for such a thing like Ruby I'd make a list with my priorities and list the contributed patches, even if they are hot stuff, on a place where they could be extremely analised and tested. If me, you or the Pope send a patch to the MRI guys telling that everything is right and it's the next wonder of the language is not a sign that the patch will be automatically merged. For some it can looks like paranoia, for me it's responsability. For some it can looks like slowness, for some, priorities.

The cool part about all that stuff is that we can learn and discuss a little (or very much) with all the other Ruby implementations (like JRuby, Rubinius, IronRuby (m$! argh!), MacRuby, Maglev), but as I told on the first paragraph, I still keep my main focus on the MRI guys, for the trust on what they do. I'm not saying that the other implementations are not trustable, just that for all the years working and seeing how MRI is done, I fully trust its developers. I hope that this article make things more clear about the MRI fork named Ruby Enterprise Edition. I'm sure that non-technical reasons where not the reason the patches were not applied on MRI. If a good code analysis are not a technical reason, I don't know what is. There is no need to create unneeded polemics.Let's make code! :-)

And now just a quick tip: Hongli Lai and Ninh Bui will be on the Rails Summit Latin America, on October 15/16, in São Paulo, Brazil. I'll be there (already payed it), who else? :-)

Comentários

Comentários fechados.

• Mereghost ter, 19 de agosto de 2008, 16:39:54 -0300

  "operadores de framework e criadores de auê"

  HUahuahua! Boa Shairon. Engraçado é que peguei uma birra com isso, como o TaQ ficou sabendo quando esteve aqui. Ninguém mais fala de Ruby sem ser junto com o RoR. Cadê os scripts de automação? Cadê as coisas feitas pro seu desktop?

  TaQ: Continuo seguindo o MRI também, pelo mesmo motivo, só não acompanho Ruby a tanto tempo =). Podem dizer que é pela minha birra com Java etc, mas duvido que terei necessidade de sequer usar uma outra implementação por qualquer motivo (tivo o MagLev).

• Shairon Toledo ter, 19 de agosto de 2008, 06:49:04 -0300

  Concordo com vc Taq, "Para alguns pode parecer lerdeza, para outros, prioridades.". Acho que tem que ponderar mesmo o caminho da linguagem e fico MRI.

  O povão só que saber de Rails hoje, esquecem a linguagem, como eu sempre digo operadores de framework e criadores de auê.

  Conhecer a linguagem e ele vos libertará(do Rails :)

• Diego Carrion sex, 15 de agosto de 2008, 17:18:33 -0300

  Excelente post, muito interessante.

• Wagner Andrade sex, 15 de agosto de 2008, 07:38:39 -0300

  A comunidade de Ruby está ficando fofoqueira, atritos gerados por implementações diferentes estão cada vez mais freqüentes, cada um quer fazer o melhor Ruby.

  Mas acho que é o ciclo normal da popularização de uma técnologia. E o Ruby está em um "ciclo intermediário", a tendencia é estabilizar e daqui a um tempo isso diminui... tomara.

  Ótima analise, belo post, parabéns.

• Hongli Lai sex, 15 de agosto de 2008, 02:53:01 -0300

  Hehe, nice article. :) I'm just wondering where the confusion comes from, because most of the information that I gave is also documented on the FAQ page of the Ruby Enterprise Edition website.

  As for tcmalloc, we realize that it's not compatible with all operating systems. But by bundling it with Ruby Enterprise Edition we are quickly learning which platforms exactly are and aren't compatible. Since 32-bit Linux is one of the most widely used server operating systems, even conditionally enabling tcmalloc for 32-bit alone will yield great benefits.