Update: Como eu disse que ia acontecer, saiu o primeiro contra-ataque contra a EY, direto do pessoal da Phusion. Isso foi motivado por um blog post recente do Tom Mornini, CEO da EY.

Faz algumas semanas que temos Rails 2.2. Como já dissemos inúmeras vezes antes, a melhor parte é a Internacionalização. Mas há mais a ser dito.

Uma coisa que nunca teve muita atenção foi a parte de thread-safe. Talvez tenha sido só coincidência, mas é fato que o Merb provavelmente incomodou o Rails Core Team um pouco alguns anos atrás quando ele colocou como meta ser thread-safe. Nunca fez muita diferença porque o Ruby MRI, também como já falamos inúmeras vezes, apenas usa green-threads. Ou seja, não fazia sentido investir muito tempo num recurso que daria pouco retorno.

A esperança do Ezra e da EngineYard era criar um framework thread-safe em Ruby e ao mesmo tempo uma nova implementação de Ruby que também fosse thread-safe. Daí o motivo de adquirir o projeto Rubinius. Foi nessa época em que o Ezra falava de mod_rubinius. Porém, infelizmente o Evan ainda não conseguiu evoluir muito e recentemente, devido à crise econômica, a EY foi obrigada a dissolver a equipe do Rubinius. O sonho do “turtles all the way” ficou para depois.

Por outro lado, um desenvolvimento que o Rails Core ignorou foi o JRuby. No começo esse projeto ainda era lento, mas o Charles, Tom, Ola, Nick, e muitos mais da comunidade Java/Ruby foram extremamente rápidos. Do 1.0 ao 1.1.5 foram poucos meses e a performance sempre aumentou muito. Com a diferença de poder contar com a JVM, que lhe dá um garbage collection geracional, suporte a threads nativa, Strings UTF-16 e muito mais de graça.

Nesse cenário, sim, um framework thread-safe faz bastante diferença! E o Merb seria o framework mais completo e thread-safe. Por isso fez sentido o Rails Core também correr atrás disso, motivado pelo Merb estar se aproximando de lançar sua versão 1.0.

Mais do que isso, o lançamento do Merb 1.0 fez o DHH entrar em modo de evangelização. Foi quando ele começou sua série de posts de Mitos Rails. Até então ele praticamente não blogava e nem twitava, agora ele twita todos os dias. A EY também sempre atacou o Passenger. Mais explicitamente, em suas palestras recentes o Ezra diz que o Passenger só é bom para pequenos projetos. E o CTO da EY, o Tom Mornini disse muito mais contra o Passenger. Por isso, a 37signals e o próprio DHH passaram a apoiar bem explicitamente o Phusion Passenger como a melhor maneira de deployment.

Isso porque a EY, até agora, sempre vendou serviços de Rails mas evangelizou que a única maneira de escalar muito seria com nginx + mongrel + merb. O DHH está disposto a vender que a melhor opção é apache + passenger + rails. O desenvolvimento do Rails 2.3 já está evoluindo bem rápido. Em pouco tempo eles adicionaram o plugin Rg que dá templates: uma resposta aos Merb Stacks. E também começou um movimento em torno de melhorar a plugin Engines: outra resposta ao Merb Slices. Outra coisa que o Rails 2.3 está perseguindo – e o Merb também – é lazy loading. Na hora que li isso imaginei que fosse quebrar pois o Ruby não sendo thread-safe por natureza, a metaprogramação também não é. Nesse caso o auto loading de classes on demand facilmente poderia quebrar em 2 threads o que foi confirmado nessa discussão. Isso ainda vai evoluir, mas não sei o quanto isso é realmente eficiente.

No mundo Unix isso não faz muita diferença. O Windows (e isso não é um fanboyismo, apenas um fato) que tem o ineficiente CreateProcess mas não tem o equivalente a Fork e muito menos a copy-on-write. Com essas capacidades básicas um processo Unix pode criar uma cópia de si (fork) mesmo consumindo quase nada de recursos se a memória alocada interna for sempre constante (copy-on-write): que é o que o Ruby Enterprise Edition faz para economizar RAM. Aliás, ambos REE e Passenger tiveram novas versões lançadas recentemente, ambas apoiadas pela 37signals.

O Merb tem um suporte nativo a controlar clusters de processos Mongrel, de forma parecida como o Passenger faz com Rails, mas com a diferença que ele não é um módulo de Apache e ainda precisa configurar proxy reverso de HTTP manualmente. Além disso o Merb ainda não tem suporte a filas e monitores de CPU e Ram como o Passenger já tem.

Neste exato momento o clima está quente. Muitas coisas estão acontecendo nos bastidores que infelizmente poucos vão ficar sabendo. Mas o Rails deve dar uma boa acelerada neste momento por causa disso e algumas notícias interessantes vão começar a aparecer muito em breve.

comentários deste blog disponibilizados por Disqus