A Controvérsia do Twitter e Scala

2009 April 07, 19:06 h - tags: twitter scala obsolete

Eu estava discutindo esse assunto na Argentina com o Obie e o Evan, parece que novamente o Alex Payne pisou no tomate. E, não, isso não se trata de “ah, novamente os ruby-fanboys falando mal dos outros.” Esse é argumentos dos que buscam por pageviews de graça.

Para começar, esta é a Internet, onde qualquer coisa vira post em blog. A maioria da controvérsia vem de pessoas que justamente não fazem parte do meio onde a discussão está se passando e estão pegando o bonde andando. Para começar, o Alex Payne é velho conhecido entre os rubistas. Ele, assim como o Blaine Cook, já palestraram em RailsConf e, sim, o Twitter continua usando Ruby e Rails.

Outra coisa: até onde eu entendo, a controvérsia entre os rubistas não começou diretamente na palestra do Alex na Web 2.0 Expo sobre Scala.

Update 8/4: só para ficar bem claro (porque pelos comentários que recebi não ficou), não, eu não faço código perfeito, muito longe disso aliás. E duvido que o Obie, o Jeremy, e quem mais for faça e nem eles afirmam isso. O Twitter também não faz e isso não o torna pior que os outros. Nunca esteve em discussão algo do tipo “é errado eles fazerem código macarrônico.” O que esteve em questão foi por que, em tendo essa circunstância – tão normal em projetos, principalmente os que crescem rápido – não se discutiu na comunidade as maneiras de resolvê-las, mas precisou se usar de artifícios do tipo “a culpa do macarrão é porque Ruby é lento e porque ele não suporta tipagem estática”? Não fomos nós quem trouxemos o assunto à mesa. Tudo isso poderia não ter sido nada. A apresentação de Scala na Web 2.0 Expo foi muito boa, eu assisti e recomendo. Amigos que já leram o livro de Scala também recomendam. O que temos aqui neste artigo é um post-mortem, de como as coisas se desenrolaram. Eu dei uma atualizada por todo o texto, vamos ver se ajuda a clarificar as coisas.

A controvérsia

A controvérsia começou mesmo no infame site britânico de notícias, o The Register_, na matéria entitulada Twitter jilts Ruby for Scalascala/. Outros se seguiram como o site Tecnology.Review. O problema? Títulos no estilo “Twitter troca Ruby por Scala”, que obviamente é uma tentativa de ganhar audiência (porque obviamente colocar as palavras “Ruby” e “Twitter” na mesma frase dá pageviews, como Arrington pode atestar).

Um dos primeiros a escrever uma boa resposta foi Ikai Lan, no seu blog, com um post entitulado Twitter, Ruby on Rails, Scala e pessoas que não lêem a droga do artigo. Ikai menciona o artigo do The Register, sobre o tweet que ele mandou ao Alex e a resposta do próprio Alex Payne via Twitter :

“É realmente frustrante para mim. Eu não acredito que as pessoas que estavam lá (na web 2.0 expo) para minha palestra ficaram com essa impressão. A imprensa realmente dobrou isso.”

Os que acompanham o mundo Ruby e Rails vão reconhecer Ikai Lan do vídeo Escalando a 1 bilhão de page views por mês, onde ele e seus colegas do LinkedIn.com explicam como eles escalaram uma aplicação Ruby on Rails no Facebook a mais de 1 bilhão de pageviews (sim, Rails escala). O artigo do Ikai também saiu no Planet Scala, site agregador de artigos sobre Scala, já que Ikai – assim como a maioria dos bons programadores – não é limitado a apenas uma linguagem.

Até este ponto, tudo bem, assim como aconteceu em 2007 com o TechCrunch e o famigerado Michael Arrington, seria mais um “Rails doesn’t Scale”. Mas o que não ajudou em nada foi que dois dias depois o Bill Venners, do site Artima.com, publicou uma entrevista com o Alex Payne a respeito de Scala, entitulado Twitter on Scalaonscala.html, onde Payne disse coisas deste tipo:

“À medida que nosso sistema cresceu, muito da lógica em nossos sistemas Ruby meio que replicam um sistema de tipagem, seja em nossos testes unitários ou nas validações dos models. Acho que pode ser somente uma propriedade de grandes sistemas em linguagens dinâmicas, que eventualmente você acabe escrevendo seu próprio sistema de tipagem. Existem muitas chamadas ao método ‘kind_of?’ do Ruby, que pergunta, ‘isso é um tipo de objeto User? Porque é isso que estamos esperando. Se não recebermos isso, isto vai explodir.’ É uma vergonha ter que escrever tudo isso quando há uma solução que existiu no mundo das linguagens de programação por décadas até agora (tipagem estática).”

A partir desse ponto foi quando alguns veteranos da comunidade Ruby ficaram incomodados. Leiam os comentários da entrevista aqui, a começar pelo Charles Nutter que concluiu:

“Deixe-me ser perfeitamente claro: eu não culpo o Twitter por escolher Scala para seu código de backend, especialmente já que eles já iam mesmo fazer o próprio sistema de mensagens (para o bem ou para o mal). Scala é certamente uma boa escolha, e muito possivelmente a melhor escolha. Mas eles podem defender o Scala sem precisar falar contra o Ruby e considerando apenas a implementação em C. Quando um número considerável dos problemas deles poderiam ser resolvidos com JRuby, acaba parecendo que eles não fizeram a lição de casa. Talvez isso não seja verdade, mas não sou o único que ficou com essa impressão.”

Explicando, na entrevista eles reclamam do garbage collector do Ruby, de como Ruby não foi feito para processos que ficam de pé por muito tempo, pela falta de threading nativo, tudo coisas que já foram resolvidas no JRuby, e também nada que todos já não soubessem.

No dia seguinte, Payne escreveu em seu blog sobre a reação às coisas que ele disse. Em particular contra a forma como a imprensa online ajudou a distorcer o que ele disse. Segundo o Payne:

“Eu rapidamente cobri porque nós não usamos outras linguagens. Eu não discuti porque ninguém deveria nunca usar essas outras linguagens, mas simplesmente porque nós (Twitter) atualmente não usamos. Seria uma absurdo e desrespeitoso dizer a uma sala cheia de engenheiros porque a escolha de linguagens de seus projetos – projetos que eles sabem tudo e eu não sei nada – está errado. Eu tento falar apenas do que eu sei de primeira mão. (…) Algumas horas depois que deixei a conferência, a máquina distorciva da imprensa e a mídia social começaram a funcionar. Rapidamente, a história da minha apresentação deixou de ser ‘Scala é uma linguagem legal e você deveria pensar sobre ela em seus negócios’ para ‘Engenheiro do Twitter cospe na lápide do Ruby e exalta Scala como nova divindidade.’”

De fato, eu sou um desses culpados. O post do Obie Fernandez, que se seguiu no dia seguinte, também não ajudou muito, principalmente quando ele disse:

“Primeiro, troquei alguns tweets com o Alex, o que me alertou um pouco, e segundo Alex não perdeu tempo em criar uma estrela virtual de invencibilidade Nintendo para si mesmo com o post Mending The Bitter Absence of Reasoned Technical Discussion. Quem pode discordar com a necessidade de mais discussão técnica razoável? Ninguém, mas francamente o timing desse artigo me fez vomitar um pouco. A náusea somente cresceu esta manhã quando chequei quanto isso foi re-tweetado.”

E ele segue explicando os problemas das últimas afirmações do Payne, e como o Payne falhou em ser mais claro. Vamos ser bem claros: não existe absolutamente nada contra o Scala na comunidade Ruby. Muito pelo contrário, nós somos a comunidade que mais abraça novas tecnologias. Quem nos acompanha sabe como gostamos de Erlang, como mesclamos bem com soluções já existentes como Sphinx para searching, como existe uma boa sinergia com a comunidade Java graças aos esforços do Charles Nutter e da equipe do JRuby.

Agora o que pegou mal para o Payne foi o seguinte: ele acabou de lançar um livro sobre Scala. O Twitter ganhou notoriedade e sempre foi usado como um bom case de Rails – apesar dos problemas de 2007 com o TechCrunch. Todos nós sabemos a linha tênue entre a comunidade e a imprensa e o Payne não pode se dar ao luxo ser ingênuo na posição onde ele está. É o preço da fama, neste caso. Toda vez que ele menciona “Ruby” e “X”, a primeira página do dia seguinte sempre será “Twitter diz que vai trocar Ruby por X”.

Fora isso existem agendas secretas, o Twitter tem investidores, não dá para saber até onde tudo isso foi apenas um escorregão não intencional do Payne ou uma manobra de marketing para aumentar o alvoroço em torno deles. E o que falha aos olhos de todos é o seguinte: falar mal de Ruby dá audiência, porque Ruby e Rails estão em alta.

A Discussão Técnica

Vou tentar resumir muito do que foi discutido no fórum do Artima, no blog do Tony Arcieri, no blog do Ikai Lan, no blog do Obie Fernandez. Não há certo ou errado aqui, apenas o que foi discutido.

Quando o Payne disse na entrevista do Artima sobre ter que praticamente recriar um sistema de tipagem usando ‘kind_of?’, seriam códigos parecidos com este (isso é um exemplo grosseiro, não quer dizer que seja assim):

1
2
3
4
5
6
def alguma_coisa(obj)
  throw :invalid_type unless obj.kind_of?(TipoEsperado)
  throw :invalid_type unless obj.respond_to?(:metodo_esperado)
  # faz alguma coisa com obj
  ...
end

Imagine esse tipo de coisa espalhado por todo seu código. Este é absolutamente o jeito errado de se usar Duck Typing e é comumente chamado de Chicken Typing, como Rick DeNatale explicou em seu blog em 2007. Frente às discussões recentes, o Ola Bini também blogou sobre este tópico. Ele disse:

“Vejamos isso do começo. Toda a razão para duck typing como uma filosofia ao escrever código Ruby é que você não deve se preocupar com a classe de um objeto que você recebeu como argumento. Você deve esperar que as operações que precisa realmente estejam lá, e assumir que estejam. (…) Os tipos em um sistema bem definido serão implicitamente definidas através do que o método realmente faz – e especificado pelos testes a esse método. Mas se você tentar fazer um design de tipos explícitos, acabará com um sistema estático de tipos em seus testes, o que não é a melhor maneira de desenvolver nessas linguagens.”

Esse é apenas um dos pontos e foi explicado desta forma pelo próprio Payne na entrevista da Artima. Outros pontos envolvem o Payne admitindo que o código que eles tem no Twitter hoje é um grande espagueti, difícil de manter, com vários bugs não-determinísticos (literalmente bugs aleatórios) e que, em vez de corrigir na raíz, refatorar, eles preferiram colocar várias gambiarras como esse monte de kind_of? que ele menciona. Novamente, sendo repetitivo, não está em discussão eles deveriam ou não fazer isso, afinal apenas eles sabem tudo que tem na infraestrutura deles.

O problema foi que, no final, a culpa disso foi simplesmente jogada ao Ruby, e não ao fato deles próprios terem feito as gambiarras. Esse é um dos argumentos do artigo do Obie.

Com toda certeza, não é da nossa conta se o código deles é cowboy ou não. Porém, usar o Ruby como “desculpa” para isso é a parte que todos discordamos. Usar Ruby não torna o código automaticamente bom, tudo depende do programador, e isso vale em qualquer linguagem. Dizer que isso acontece porque se está usando uma linguagem dinâmica, é meramente uma desculpa.

Outros aspectos envolvem as características conhecidas do Ruby MRI (a implementação C) de não ter threads nativas, de não ser bom com concorrência, de não ser maduro para fazer daemons. Quando Bill Venners foi questionado pelo Charles de porque ele não mencionou JRuby – que efetivamente resolve esses problemas – eles atualizaram a entrevista no Artima com isto:

Na época em que olhamos para isso, simplesmente não conseguíamos bootar nossa aplicação Rails em JRuby. Muitas Gems de Ruby requerem extensões em C e ainda não haviam sido portadas para Java. A performance do JRuby também não estava perto do Ruby MRI, menos ainda de uma linguagem como Scala. Estamos abertos a tentar JRuby novamente no futuro, mas estamos esperando que alguns patches de Ruby ajudem por enquanto.

Aqui o Payne não respondeu à pergunta de maneira efetiva e ainda gerou mais confusão. Isso porque primeiro faz muito tempo que eles testaram JRuby, muito antes dele estar estável e com performance melhor que o JRuby. Segundo porque ele fala de testes para rodar o front-end e não no caso atual que é substituir o middleware. Eles estão retirando o middleware que era em Ruby para Scala, não o front-end Web – que permanece em Rails.

A aparente raíz do problema foi eles teram feito um sistema de message queue em Ruby, o Starling. Talvez em 2004 não existisse muitas boas opções – embora escrever esse tipo de sistema em Ruby foi um grande risco mesmo. Como o Ikai diz, em 2008, existem boas opções, como RabbitMQ e outros.

Daí ele reclamou que existem gems que eles usam que não rodam em JRuby. Verdade, as que tem extensões em C. Porém, esse argumento não vale muito aqui porque no final eles reescreveram o middleware todo em Scala, o que se tornou o projeto Kestrel. Sobre isso o artigo do Tony Arcieri é mais enfático (recomendo ler o artigo todo dele):

“Em vez de escolher entre as centenas de message queues já disponíveis (incluindo alguns em Ruby mesmo), o Twitter sucumbiu à sindrome do Não-Foi-Inventado-Aqui (”NIH":http://en.wikipedia.org/wiki/Not_Invented_Here) e escreveram o próprio. O resultado foi o Starling, um message queue que fala o protocolo do memcached (sem mencionar que já existe um message queue que faz exatamente isso). (…) Starling é possivelmente um dos message queues mais lentos e com o pior design em existência (…) Sim, com absolutamente zero experiência em escrever um servidor de rede de alta performance em Ruby, a síndrome de NIH do Twitter os levou a escrever seu próprio message queue. E surpresa, surpresa, eles falharam miseravelmente! Qual foi a reação do Twitter? Eles começaram a procurar por sistemas melhor, open source, escrito por pessoas que efetivamente são competentes em desenvolver message queues? Não, claro que não, mais NIH (…) Sim, claramente Ruby é o problema, e mais NIH é a solução. O resultado foi Kestrel, um novo message queue escrito em Scala que ninguém além do Twitter usa. Ele tem performance muito melhor que o Starling, claro! Apenas não tão bom quanto RabbitMQ, uma fila tão rápida que certos loucos que conheço fazem streaming de video nele em tempo real."

Entendem o problema? Dada a informação que o próprio Payne discorreu, a única coisa que dá para concluir – de forma cínica, eu sei – é que eles tem programadores ruins (fazer sucesso e ter boa qualidade de serviço não são características mutuamente dependentes, vide o Windows). Agora, isso é uma especulação e também não há problema nisso contanto que se faça as coisas direito: decidiu que as alternativas open source do mercado não servem e quer escrever o próprio em Scala? Ótimo, mas não coloque a culpa no Ruby. Esse é o ponto!

Novamente: o problema não é o Scala, o problema não é reescrever o middleware, o problema não é ignorar outras alternativas. O problema é o aparente oportunismo do Payne (que pode ter sido meramente um acidente de timing) em se lançar como o novo profeta do Scala escalando nas costas do Ruby, e falhando em se explicar. Ele mesmo reclamou da falta de boas discussões técnicas e é exatamente o que estamos todos tentando fazer agora: já que levou tudo isso a público, falar mal de Ruby. Faltou mais detalhes em perguntas como:

  • vocês testaram JRuby recentemente? Atualmente JRuby, em produção, é mais rápido do que o Ruby MRI e resolve muitos dos pontos de descontentamento: interoperabilidade com a enorme base de bibliotecas em Java; threads nativas; rodar diretamente na JVM, e mais. Antes que mencionem os artigos que eu mesmo linkei notem: faz muito tempo que eles testaram JRuby e não foi para o middleware e sim para o front-end. O JRuby 1.2 está uma ordem de grandeza melhor que 1 ano atrás.
  • vocês testaram alternativas open source de message queue recentemente? Como já dissemos RabbitMQ, MemcacheQ e outros estão aí. Basta pegar e usar. Até onde deu para ver o Kestrel não é nada complexo, o Starling nunca foi. O requerimento é que precisa falar o protocolo do memcache, porém esse protocolo não é difícil, na pior das hipóteses fazer um anti-corruption layer ainda é menos trabalhoso do que fazer um message queue inteiro do zero.
  • vocês podem explicar melhor porque precisam de um sistema de tipagem estática numa linguagem dinâmica como Ruby? Podem mostrar que não se trata de code smell – como nós já sabemos que só pode ser. Como disse antes, fazer código ruim não é da nossa conta, mas dizer que isso é de alguma forma “culpa” do Ruby é se desviar completamente o foco.

E quem somos nós para questionar essas coisas. Não é da nossa conta, de fato, mas de novo: essas questões foram trazidas por eles mesmos. Vejam a situação: cá estamos todos, a comunidade Ruby, cuidando do nosso dia-a-dia, evangelizando, dando consultoria. De repente vem um gigante chamado Twitter que, não intencionalmente, também trás a imprensa marrom no vácuo, fazem várias meias-afirmações, colocam a comunidade em má situação e todos esperam que nós fiquemos quietos e ignoremos, enquanto todos os outros vem a nós agora, perguntando “o que aconteceu?”

Conclusão

Finalmente, a todos que não acompanharam toda a história: o Twitter NÃO está saindo de Ruby para Scala. Ruby on Rails é tão escalável quanto qualquer outra linguagem moderna. Ruby de fato não é muito usado para middlewares e exatamente para isso existem plataformas maduras como Erlang ou newcomers como Scala. Web é uma “arquitetura”, existem muitas camadas como front-end (Rails), middleware (Erlang). Tentar simplificar isso sempre vai dar confusão. E, novamente, escalabilidade e performance também não são características mutuamente dependentes.

O que está acontecendo é muito simples: por qualquer razão o Twitter decidiu reescrever seu middleware em Scala. Excelente, a empresa é deles, o capital é deles, a decisão é deles e – como o Charles disse – Scala é uma ótima opção para isso. O front-end continua sendo em Ruby on Rails – que é exatamente para isso que ele foi feito. Ponto final – e nós não estamos sendo cínicos ou sarcásticos ao dizer isso.

Eu não vejo ninguém fazendo matérias entituladas “Google está cuspindo no Python ao usar Java no backend”. Ou “Yahoo está trocando PHP ao usar C++ no backend”. Primeiro, porque qualquer engenheiro lhe dirá que sistemas complexos sempre usarão múltiplas tecnologias (“the best tool for the job”, já ouviram falar?). Segundo, porque esse tipo de título não gera audiência.

O fato é que qualquer menção a Ruby on Rails atrai muita mídia e essa é a raíz da controvérsia. Eu até acredito que o Alex Payne nem ninguém do Twitter teve nenhuma má intenção direta de falar prejudicar a comunidade Ruby. Basta ser um programador para entender. Mas a marca “Twitter” gera problemas e sites mal intencionados como o The Register não ajudam.

A razão de porque nós, rubistas, ficamos incomodados? Porque nós estamos há alguns anos já investindo nossos escassos recursos, criando um mercado de nicho que vem crescendo muito bem, e estamos à mercê de intrigas como essas. Ou seja, quem tem que fazer o “damage control” agora somos cada um de nós. Eu mesmo já recebi perguntas de pessoas dizendo “então o Ruby não escala em projetos grandes?” E lá vamos nós gastar tempo explicando tudo novamente. Se desse para mandar a conta do PR pro Twitter, não teria tanto problema :-)

A ironia disso tudo? O Twitter continua com problemas como vocês devem ter notado nos últimos dias. Agora alguém pode começar com a brincadeira idiota de “ahá, Scala não escala!” E quem diz esse tipo de coisa é puramente um bloguer procurando desesperadamente por audiência descartável.

Moral da história: todos nós fazemos código ruim. Como eu disse no meu artigo anterior, cowboy é aquele que não admite isso. Bons desenvolvedores buscam melhorar. O Twitter não é mal, apenas atrai os maus elementos. Não custaria nada ajudar a dissipar os rumores que eles mesmos criaram ou simplesmente não jogar meias-afirmações ao vento. Claro que também ajudaria se nós rubistas fôssemos um pouco menos agressivos e nesse caso eu também sou culpado de jogar lenha na fogueira. Como eu disse antes, isto é um post-mortem para que todos entendam a sequência dos acontecimentos. E espero que tenha ficado claro que este episódio todo não tem nenhum pingo de flame do tipo “linguagem X vs linguagem Y” e nem de “rubistas vs o Twitter” porque se assim o fosse nós não estaríamos usando o Twitter, já teríamos migrado pra Identi.ca ou qualquer outra coisa. Continuamos a gostar do Twitter, esperamos que da próxima vez a discussão ocorra, como o próprio Payne blogou, dentro de parâmetros mais técnicos.

Comments

comentários deste blog disponibilizados por Disqus