Isto é, se você deseja empregar sempre o que é tido como
state-of-the-art, eu recomendaria adotar uma agenda de reciclagem e
pesquisa de novas tecnologias a cada 2 anos.

Estou sentindo isso com algumas recentes jornadas de programação em
Python no trabalho. Comecei com Python 2.0 e Apache/mod_python há 5
anos, se entender muito bem os requirementos e soluções para alta
disponibilidade de aplicativos web.

Trabalhei em um projeto com versões primordiais do Rails por 2
anos. Neste tempo, o próprio Rails evoluiu consideravelmente o que
justificou a continuidade de outro ciclo de 2 anos com ele, estando
entre as versões 2.0 e a recentemente lançada 2.2.2.

Neste período mergulhei de cabeça em todos aspectos da arquitetura
de alta disponibilidade, caching, reverse proxies, database
replication e sharding, além de ferramentas de monitoração. As
ferramentas deste universo ainda estão caminhando mas algumas já
estão estáveis o suficiente para fazer parte da stack padrão.

Paralelamente, surgia o Merb, spin-off do Rails que visa ser mais
leve, rápido e flexível. Em menos de dois anos, o Merb conseguiu
um suporte impressionante da comunidade, e já chegou a uma
versão 1.0. Para muitos, já é uma alternativa viável ao Rails.

Dentro da minha teoria, isso aconteceu por dois motivos:

 1) O Rails não é bala de prata. Ou melhor, O Ruby não é. O Ruby é
 uma linguagem dinâmica que consome uma quantidade histérica de
 memória devido ao fato de tudo ser um objeto completo. O Ruby é
 uma linguagem totalmente OO, o que é uma vantagem para a
 engenharia e concepção de modelos complexos de programas, mas
 torna-se uma desvantagem em estabilidade e alta disponibilidade.
 Inevitavelmente, o GC do Ruby tem tarefa mais pesada que torna o
 fluxo de reciclagem de dados na memória mais lento, o que influi
 diretamente no número de requests por segundo que uma única
 instância de apliação Rails pode processar. Outra falha é a
 complexa ramificação da tree do código fonte do Rails, com uma
 bagagem muito grande de items desnecessários.

 Isso não é problema para se manter uma aplicação Rails em pé,
 podendo ser resolvido com a expansão horizontal de servidores e
 ferramentas de monitoração que reiniciam processos Ruby de vez em
 quando (monit). Mas é fato que o custo operacional do Rails fica
 inviável para aplicações de tráfego muito elevado. Isso causou um
 êxodo de aplicações para outras plataformas mais leves e mais
 rápidas, como o bom e velho Python e mais recentemente, Erlang. O
 Twitter teve que receber um toque de Erlang este ano.

 2) O Rails não fez muito esforço para profilaticamente acompanhar
 e atender essas necessidades. O consenso parece ser de que Rails
 de fato não deveria sequer ser considerado para isso e que outras
 tecnologias e linguagens vão inevitavelmente fazer parte de uma
 mesma arquitetura. Este consenso vem de grande coerência. O
 problema é que o Rails também deixou de acompanhar evoluções
 dentro da própria comunidade Ruby.

 Rack, o equivalente do Ruby do padrão WSGI do Python, demorou para
 ser notado pelo Rails. O Rack, como API padrão de comunicação
 entre servidores e aplicações, traz inúmeras vantagens incluindo
 maior concisão de código, e foi prontamente adotado pelo Merb.

 Basicamente, o Rails chegou a um ponto onde novas releases
 passaram a ser releases de manutenção e adição de recursos ainda
 essenciais. A mais recente versão, 2.2.2, inclui finalmente
 suporte embutido a I18n e patches que garantem thread safety.

***

O mais importante a se observar aqui é que Rails não recebeu muito
refactoring em seus pilares de sustenção. Não há mais tantos
backward-incompatible updates e não há esforço mental em tentar
conceber maneiras mais inteligentes de se lidar com várias das
necessidades básicas de uma aplicação web.

O Django infelizmente já está chegando nesse estado também. O Merb,
agora em sua versão 1.0, deve provavelmente permanecer em sua fase
experimental por mais um ciclo de 2 anos, enquanto detém
sua qualificação state-of-the-art.

Quem continuar com Rails vai provavelmente se acomodar numa
arquitetura já bem definida, estável e sem muitas mudanças futuras.
Talvez daqui 2 anos venha o Rails 3.0, com refactoring completo. Um
tanto improvável mas não impossível.

O Python está próximo mais uma vez de se tornar state-of-the-art
com sua iminente versão 3.0, com dúzias de modificações
state-of-the-art, e claramente o resultado de anos de pesquisa e o
claro objetivo de tentar refazer tudo de maneira melhor.

A estagnação do Rails não é necessariamente algo ruim, é sinal que
a tecnologia está madura e confiável. E particularmente, continuará
sendo a opção padrão para a construção de sites nos meus projetos.

Mas para aplicações de domínio específico, ou serviços internos,
Python torna-se a opção padrão pelos próximos 2 anos. Frameworks
compatíveis com WSGI, como web.py, já estão bem maduros. E para
ORM, SQLAlchemy já se tornou uma opção melhor que SQLObject. A
maioria dos servidores têm adaptadores WSGI, até mesmo o nginx.

Isto é, se você deseja empregar sempre o que é tido como
state-of-the-art, eu recomendaria adotar uma agenda de reciclagem e
pesquisa de novas tecnologias a cada 2 anos.

Estou sentindo isso com algumas recentes jornadas de programação em
Python no trabalho. Comecei com Python 2.0 e Apache/mod_python há 5
anos, se entender muito bem os requirementos e soluções para alta
disponibilidade de aplicativos web.

Trabalhei em um projeto com versões primordiais do Rails por 2
anos. Neste tempo, o próprio Rails evoluiu consideravelmente o que
justificou a continuidade de outro ciclo de 2 anos com ele, estando
entre as versões 2.0 e a recentemente lançada 2.2.2.

Neste período mergulhei de cabeça em todos aspectos da arquitetura
de alta disponibilidade, caching, reverse proxies, database
replication e sharding, além de ferramentas de monitoração. As
ferramentas deste universo ainda estão caminhando mas algumas já
estão estáveis o suficiente para fazer parte da stack padrão.

Paralelamente, surgia o Merb, spin-off do Rails que visa ser mais
leve, rápido e flexível. Em menos de dois anos, o Merb conseguiu
um suporte impressionante da comunidade, e já chegou a uma
versão 1.0. Para muitos, já é uma alternativa viável ao Rails.

Dentro da minha teoria, isso aconteceu por dois motivos:

 1) O Rails não é bala de prata. Ou melhor, O Ruby não é. O Ruby é
 uma linguagem dinâmica que consome uma quantidade histérica de
 memória devido ao fato de tudo ser um objeto completo. O Ruby é
 uma linguagem totalmente OO, o que é uma vantagem para a
 engenharia e concepção de modelos complexos de programas, mas
 torna-se uma desvantagem em estabilidade e alta disponibilidade.
 Inevitavelmente, o GC do Ruby tem tarefa mais pesada que torna o
 fluxo de reciclagem de dados na memória mais lento, o que influi
 diretamente no número de requests por segundo que uma única
 instância de apliação Rails pode processar. Outra falha é a
 complexa ramificação da tree do código fonte do Rails, com uma
 bagagem muito grande de items desnecessários.

 Isso não é problema para se manter uma aplicação Rails em pé,
 podendo ser resolvido com a expansão horizontal de servidores e
 ferramentas de monitoração que reiniciam processos Ruby de vez em
 quando (monit). Mas é fato que o custo operacional do Rails fica
 inviável para aplicações de tráfego muito elevado. Isso causou um
 êxodo de aplicações para outras plataformas mais leves e mais
 rápidas, como o bom e velho Python e mais recentemente, Erlang. O
 Twitter teve que receber um toque de Erlang este ano.

 2) O Rails não fez muito esforço para profilaticamente acompanhar
 e atender essas necessidades. O consenso parece ser de que Rails
 de fato não deveria sequer ser considerado para isso e que outras
 tecnologias e linguagens vão inevitavelmente fazer parte de uma
 mesma arquitetura. Este consenso vem de grande coerência. O
 problema é que o Rails também deixou de acompanhar evoluções
 dentro da própria comunidade Ruby.

 Rack, o equivalente do Ruby do padrão WSGI do Python, demorou para
 ser notado pelo Rails. O Rack, como API padrão de comunicação
 entre servidores e aplicações, traz inúmeras vantagens incluindo
 maior concisão de código, e foi prontamente adotado pelo Merb.

 Basicamente, o Rails chegou a um ponto onde novas releases
 passaram a ser releases de manutenção e adição de recursos ainda
 essenciais. A mais recente versão, 2.2.2, inclui finalmente
 suporte embutido a I18n e patches que garantem thread safety.

***

O mais importante a se observar aqui é que Rails não recebeu muito
refactoring em seus pilares de sustenção. Não há mais tantos
backward-incompatible updates e não há esforço mental em tentar
conceber maneiras mais inteligentes de se lidar com várias das
necessidades básicas de uma aplicação web.

O Django infelizmente já está chegando nesse estado também. O Merb,
agora em sua versão 1.0, deve provavelmente permanecer em sua fase
experimental por mais um ciclo de 2 anos, enquanto detém
sua qualificação state-of-the-art.

Quem continuar com Rails vai provavelmente se acomodar numa
arquitetura já bem definida, estável e sem muitas mudanças futuras.
Talvez daqui 2 anos venha o Rails 3.0, com refactoring completo. Um
tanto improvável mas não impossível.

O Python está próximo mais uma vez de se tornar state-of-the-art
com sua iminente versão 3.0, com dúzias de modificações
state-of-the-art, e claramente o resultado de anos de pesquisa e o
claro objetivo de tentar refazer tudo de maneira melhor.

A estagnação do Rails não é necessariamente algo ruim, é sinal que
a tecnologia está madura e confiável. E particularmente, continuará
sendo a opção padrão para a construção de sites nos meus projetos.

Mas para aplicações de domínio específico, ou serviços internos,
Python torna-se a opção padrão pelos próximos 2 anos. Frameworks
compatíveis com WSGI, como web.py, já estão bem maduros. E para
ORM, SQLAlchemy já se tornou uma opção melhor que SQLObject. A
maioria dos servidores têm adaptadores WSGI, até mesmo o nginx.

Talvez eles tenham mais desse inconformismo do seu ponto 6 e comecem
primeiro a fazer alguma coisa nova. Ou talvez porque o número de gente que
desenvolve aqui é menor do que o que desenvolve no resto do mundo, por isso
a ocorrência fora é maior. (espero que não tenha ficado confuso)

--
Camilo Oliveira

On 22 nov, 16:31, "Jonas Galvez" <jonasgal...@gmail.com> wrote:

a maturidade de juntar 2 ótimas soluções é algo que geralmente não se
vê no mundo opensource, onde geralmente acontece justamente o
contrário: forks, forks e... forks.