Twitter muda front-end de Ruby para Java

E o Blender foi feito em cima do Netty.

[Modo ReceberPedradas=ON, source=rubistas] :lol:
-Primeiro foi uma parte do backend que foi trocada para Scala

-Agora uma do front-end trocada por java.

Agora la vai…

Afinal, Ruby nao escala!!!??? :shock:

[Modo ReceberPedradas=OFF, source=rubistas]

O que é este Blender?

BOOOMMM…

Acho que realmente as coisas estão bem mudadas na comunidade Ruby…

Se eles tiraram o Ruby do backend, pq scala funcionou melhor para o projeto deles, não sei por que demoraram mais pra trocar o front-end

Eu mecho com Ruby, e acho que cada projeto deve ser analisado qual a tecnologia empregar, e assim como o pessoal do Twitter percebeu que Ruby não serviu para o site deles, eles migraram pra Java, fizeram o que ao meu ver é o certo.

provavelmente o pessoal de ruby vai falar que os caras do twiter não sabem programar.

como se isso fosse possivel.

seguir a moda as vezes provoca um grande refactoring(brincadeira uahau) .

Felagund:

Se eles tiraram o Ruby do backend, pq scala funcionou melhor para o projeto deles, não sei por que demoraram mais pra trocar o front-end

Eu mecho com Ruby, e acho que cada projeto deve ser analisado qual a tecnologia empregar, e assim como o pessoal do Twitter percebeu que Ruby não serviu para o site deles, eles migraram pra Java, fizeram o que ao meu ver é o certo.

[2]

Gente o twitter saiu do zero para milhoes de usuários usando Ruby. Se agora eles estão mudando pra ganhar 600 ms é porque dinheiro não falta pra empresa, isso é motivo pra cair de pau na linguagem? :shock:

Conteúdo removido pela moderação!

Eu acho que o Ruby foi bom por um tempo. Talvez os criadores não tinham idéia do tamanho que isso iria tomar. Natural verem no java, uma plataforma robusta e mais aberta que a do seu concorrente direto, um substituto a altura do twiter. Não que ruby seja ruim, mas deve carecer de alguns recursos que a plataforma java tenha. Achei que iriam migrar tudo para Scala, mas pelo visto ela tambem carece de recursos, e da ultima vez que migraram para Scala é por causa do desempenho. Pelo visto nesse quisito o java ta se saindo bem apesar do seu histórico.

marcosvinicius.rj:

Gente o twitter saiu do zero para milhoes de usuários usando Ruby. Se agora eles estão mudando pra ganhar 600 ms é porque dinheiro não falta pra empresa, isso é motivo pra cair de pau na linguagem? :shock:

Tem gente que tem uma visão digamos um tanto estreita (leia-se, eu gosta da linguagem X e portando todas as outras são inuteis)

Concordo com o que disseram. Como o Twitter tem grana, contrataram programadores e se livraram dos estagiários.

O Objetivo ao meu ver é mostrar a noticia de que o twitter agora roda em java, que por sinal é o objetivo desse forum ou estou enganado?

Conteúdo removido pela moderação!

O Objetivo ao meu ver é mostrar a noticia de que o twitter agora roda em java, que por sinal é o objetivo desse forum ou estou enganado?[/quote]

se ele tem money pq não inovar e crescer mais!

O tópico será trancado na próxima mensagem de flame.

[]s

Vc chegou a ler o texto? Eles tiveram que criar um framework próprio porque não tinha em java.

Vc chegou a ler o texto? Eles tiveram que criar um framework próprio porque não tinha em java.

Não lí o texto original (li agora), mas a troca foi somente por causa do Blender e não por causa do java. Então a galera ta sentando o pau na linguagem a toa. De qualquer forma o Blender foi feito em java por um bom motivo na minha opnião.

Estou vendo os comentários aqui, tipo Ruby não é uma linguagem ruim se fosse por cases que mudaram para melhorar pontos X ou Y o .NET já teria caído na época que o Orkut migrou do .Net pra Java.

O fato é que tem lugares e lugares, onde Ruby mostrou ser legal foi até um ponto que ele já não estava tão bem e mudaram, o mesmo pode ocorrer com qualquer outra linguagem dentre elas o Java tbm.

‘It’s Not a Silver Bullet’ vale para qualquer linguagem.

A questão que deixa os “rubistas” p… da vida é o fato de mais um grande case do Ruby ter ficado na estoria…

né Luiz Aguiar ? :shock:

isso é pra mostrar mais uma vez que o java não esta morrendo, como o pessoal da moda alega geralmente.

que cada linguagem é aplicada a um tipo de projeto, e pelo que parece ruby é para projetos menores e faz muito bem isso.

Na verdade fui eu que dei uma cutucada no leão com vara curta :lol: , mas era só pra ver a discussão.

A grande questão, é que quando falavam de ruby, sempre citavam o Twitter como exemplo, na época que trocaram uma parte por scala, e o Alex Payne deu uma palestra falando alguns pros e cons do ruby, a comunidade ruby faltou querer matar o cara, mas falaram tanto, mas tanto.

Diabo Loiro:

isso é pra mostrar mais uma vez que o java não esta morrendo, como o pessoal da moda alega geralmente.

que cada linguagem é aplicada a um tipo de projeto, e pelo que parece ruby é para projetos menores e faz muito bem isso.

Caramba cara, realmente acho que a Globo.com, Groupon não tem requests suficientes para ser considerado um projeto grande usando Ruby né.

Cara, sai desse mundo de Java é o melhor e vai aprender mais coisas, aprender que não interesse o que seu time mais sabe e sim a melhor linguagem pro projeto…

chun:

A questão que deixa os “rubistas” p… da vida é o fato de mais um grande case o Ruby ter ficado na estoria…

né Luiz Aguiar ? :shock:

Hmm… Acho que não foi dessa vez então… Rails continua sendo usado no site, o mecanismo de busca que ganhou uma nova arquitetura em Java.

Felagund:

Diabo Loiro:

isso é pra mostrar mais uma vez que o java não esta morrendo, como o pessoal da moda alega geralmente.

que cada linguagem é aplicada a um tipo de projeto, e pelo que parece ruby é para projetos menores e faz muito bem isso.

Caramba cara, realmente acho que a Globo.com, Groupon não tem requests suficientes para ser considerado um projeto grande usando Ruby né.

Cara, sai desse mundo de Java é o melhor e vai aprender mais coisas, aprender que não interesse o que seu time mais sabe e sim a melhor linguagem pro projeto…

Se os “fã boys do ruby” seguissem esta sua “dica” , talvez não tivesse tanta gente “sapatiando em cima” do Ruby depois de uma noticia destas.

marcosvinicius.rj:

chun:

A questão que deixa os “rubistas” p… da vida é o fato de mais um grande case o Ruby ter ficado na estoria…

né Luiz Aguiar ? :shock:

Hmm… Acho que não foi dessa vez então… Rails continua sendo usado no site, o mecanismo de busca que ganhou uma nova arquitetura em Java.

Segundo a Infoq, por pouco tempo

chun:

marcosvinicius.rj:

chun:

A questão que deixa os “rubistas” p… da vida é o fato de mais um grande case o Ruby ter ficado na estoria…

né Luiz Aguiar ? :shock:

Hmm… Acho que não foi dessa vez então… Rails continua sendo usado no site, o mecanismo de busca que ganhou uma nova arquitetura em Java.

Segundo a Infoq, por pouco tempo

Infoq? Sugiro que leia o blog do twitter (caso saiba inglês claro!). Não fala nada sobre mudança no site, apenas no novo mecanismo de busca. Acho que você esta confundindo as bolas, (ou o que é mais provável, trolando o tópico). Uma empresa como twitter tem vários sistemas e não tem porque usar Ruby em tudo só porque o site é feito em Rails.

Você não usa só Java nos seus projetos né? :shock:

que que tem haver o RJ com isso?
vamos manter o respeito com os demais membros.

marcosvinicius.rj:

chun:

marcosvinicius.rj:

chun:

A questão que deixa os “rubistas” p… da vida é o fato de mais um grande case o Ruby ter ficado na estoria…

né Luiz Aguiar ? :shock:

Hmm… Acho que não foi dessa vez então… Rails continua sendo usado no site, o mecanismo de busca que ganhou uma nova arquitetura em Java.

Segundo a Infoq, por pouco tempo

Infoq? Sugiro que leia o blog do twitter (caso saiba inglês claro!). Não fala nada sobre mudança no site, apenas no novo mecanismo de busca. Acho que você esta confundindo as bolas, (ou o que é mais provável, trolando o tópico). Uma empresa como twitter tem vários sistemas e não tem porque usar Ruby em tudo só porque o site é feito em Rails.

Você não usa só Java nos seus projetos né? :shock:

Repito , segundo o Infoq , por pouco tempo :lol:

ps: Calma cocada como nosso colega disse… tem o Globo.com , o Groupon… calma

chun:

marcosvinicius.rj:

chun:

marcosvinicius.rj:

chun:

A questão que deixa os “rubistas” p… da vida é o fato de mais um grande case o Ruby ter ficado na estoria…

né Luiz Aguiar ? :shock:

Hmm… Acho que não foi dessa vez então… Rails continua sendo usado no site, o mecanismo de busca que ganhou uma nova arquitetura em Java.

Segundo a Infoq, por pouco tempo

Infoq? Sugiro que leia o blog do twitter (caso saiba inglês claro!). Não fala nada sobre mudança no site, apenas no novo mecanismo de busca. Acho que você esta confundindo as bolas, (ou o que é mais provável, trolando o tópico). Uma empresa como twitter tem vários sistemas e não tem porque usar Ruby em tudo só porque o site é feito em Rails.

Você não usa só Java nos seus projetos né? :shock:

Repito , segundo o Infoq , por pouco tempo :lol:

ps: Calma cocada como nosso colega disse… tem o Globo.com , o Groupon… calma ;)

Estou calmo, apenas sugeri pra ler a notícia na fonte para não pagar mico. rs

InfoQ

O Blender foi construído sobre o Netty, uma biblioteca NIO (New IO) extremamente escalável e escrita em Java, que foi criada com o objetivo de tornar mais rápidos o desenvolvimento e a manutenção de aplicativos em rede. O Netty foi a alternativa escolhida pelos engenheiros do Twitter, depois de também avaliarem o Mina e o Jetty. Entre os motivos para a escolha do Netty, foram apontados uma API mais limpa, maior documentação e o fato de o Netty já ser usado em outros projetos do Twitter.

Para garantir a disponibilidade do seu serviço de pesquisas, o Twitter continuará por algum tempo usando o front-end antigo em Ruby on Rails e roteando as requisições para o Blender. A próxima etapa será eliminar totalmente o front-end em Rails e conectar os usuários diretamente ao novo front-end.

Repito , Segundo o Infoq…

ps: se entenda com eles , não comigo

chun:

Felagund:

Diabo Loiro:

isso é pra mostrar mais uma vez que o java não esta morrendo, como o pessoal da moda alega geralmente.

que cada linguagem é aplicada a um tipo de projeto, e pelo que parece ruby é para projetos menores e faz muito bem isso.

Caramba cara, realmente acho que a Globo.com, Groupon não tem requests suficientes para ser considerado um projeto grande usando Ruby né.

Cara, sai desse mundo de Java é o melhor e vai aprender mais coisas, aprender que não interesse o que seu time mais sabe e sim a melhor linguagem pro projeto…

Se os “fã boys do ruby” seguissem esta sua “dica” , talvez não tivesse tanta gente “sapatiando em cima” do Ruby depois de uma noticia destas.

A questão não é sobre “fã boys do ruby”, mas sobre “fã boys do java” que não entendem que não é por que existem projetos feitos em Ruby que todo mundo vai mudar pra Ruby, e que sim existem aplicações de grande porte escritas em Ruby, como tem escritas em Java, Python, .NET, etc.

Dai saí uma noticia dessas lá vem os “fã boys do java” dizendo: “Ruby não serve pra grandes aplicações, só pra projetos pequenos”

chun:

Para garantir a disponibilidade do seu serviço de pesquisas

:shock:

Acho que seu problema não é com Ruby, e sim com o Português.

Felagund:

chun:

Felagund:

Diabo Loiro:

isso é pra mostrar mais uma vez que o java não esta morrendo, como o pessoal da moda alega geralmente.

que cada linguagem é aplicada a um tipo de projeto, e pelo que parece ruby é para projetos menores e faz muito bem isso.

Caramba cara, realmente acho que a Globo.com, Groupon não tem requests suficientes para ser considerado um projeto grande usando Ruby né.

Cara, sai desse mundo de Java é o melhor e vai aprender mais coisas, aprender que não interesse o que seu time mais sabe e sim a melhor linguagem pro projeto…

Se os “fã boys do ruby” seguissem esta sua “dica” , talvez não tivesse tanta gente “sapatiando em cima” do Ruby depois de uma noticia destas.

A questão não é sobre “fã boys do ruby”, mas sobre “fã boys do java” que não entendem que não é por que existem projetos feitos em Ruby que todo mundo vai mudar pra Ruby, e que sim existem aplicações de grande porte escritas em Ruby, como tem escritas em Java, Python, .NET, etc.

Dai saí uma noticia dessas lá vem os “fã boys do java” dizendo: “Ruby não serve pra grandes aplicações, só pra projetos pequenos”

Eu não concordo que Ruby é uma porcaria… acho que tem o seu espaço… mas confesso que fiquei com vontade de dar uma sapatiada tmb…

Ainda mais quando vejo um monte de gente dando palestras por ai METENDO O PAU no Java , e dizendo que o Ruby é perfeito , performatico e simplesmente intocável…

ehehehe

marcosvinicius.rj:

chun:

Para garantir a disponibilidade do seu serviço de pesquisas

:shock:

Acho que seu problema não é com Ruby, e sim com o Português.

Ahhh esqueci… as pesquisas são só uns 2% do twitter né ?

Desculpa

HEhehehe, concordo plenamente, acho ridiculo vc ir em um evento ou ver um palestra e os cara falando mal de tudo o resto e endeusando o Ruby.
Gosto de Ruby, acho a sintaxe muito bonita, mas isso não quer dizer que nenhuma outra não preste

.

chun:

marcosvinicius.rj:

chun:

Para garantir a disponibilidade do seu serviço de pesquisas

:shock:

Acho que seu problema não é com Ruby, e sim com o Português.

Ahhh esqueci… as pesquisas são só uns 2% do twitter né ?

Desculpa :)

Aqui eu concordo com vc. Só estou dizendo que Rails continua sendo usado, ainda que seja apenas no website.

pra mim o que de pior a ‘comunidade’ ruby on rails tem é a ‘marra’, a ‘pose’ de ‘rockstar’ que eles têm… ô gente arrogante, e que ‘defende’ a arrogância, como se eles fossem ‘a última bolacha do pacote’! :shock: tem gente arrogante em todo canto, até mesmo aqui; mas o criador do rails (david h!@#$%& hanson) é a arrogância em pessoa… e fez muitos discípulos… alguns, aqui no brazil… #nojo

até agora, o twitter era o maior ‘case’ de aplicação desenvolvida em rails… se os caras mudaram o back-end para scala e o front-end pra java, eles devem saber o que estão fazendo… falando em rede social, tempos atrás o orkut mudou de .net para java… acho que eles também sabiam do que estavam fazendo…

pra mim o que fica disso tudo é que ruby on rails nunca foi a solução para tudo, como alguns ‘agilistas’ pregam… e java ainda é uma solução ‘parruda’ para aplicações ‘enterprise’… penso que a oracle vai investir justamente nessa coisa do ‘enterprise’, claro.

Felagund:

A questão não é sobre “fã boys do ruby”, mas sobre “fã boys do java” que não entendem que não é por que existem projetos feitos em Ruby que todo mundo vai mudar pra Ruby, e que sim existem aplicações de grande porte escritas em Ruby, como tem escritas em Java, Python, .NET, etc.

Dai saí uma noticia dessas lá vem os “fã boys do java” dizendo: “Ruby não serve pra grandes aplicações, só pra projetos pequenos”

1 - Cara voce ja conversou com algum fan boy? é o cara que acha quer uma linguagem é a chave para tudo.

2 - fiz um comentario porque todo mundo fala que a linguagem java vai morrer, [color=red]cada linguagem tem que ser usada onde for melhor.[/color]
E o que nos vimos foi que não serve pro twiter.

3 - a linguagem da moda é ruby e ta cheio de fan boys que saem atacando todas as outras linguagens… java ja não tem mais a necessidade de ter fã boys.

Que isso pessoal. Parem de brigar. Confesso que já ouvi um monte de rubistas e alguns poucos “pythonistas” atacando o Java. Ontem mesmo em um grupo que participo me atacaram pq usei Java e tals…

Essas coisas são das duas uma: marketing ou imaturidade de quem critica o outro…

E outra coisa, são duas tecnologias Free, livres! Pronto! \o/

Uma duvida , o Twitter não tava usando JRuby ?

quero ver alguem que ja trabalhou em alguma aplicação de um banco gigantesca enterprise, aprender ruby, tudo facinho , codigo gerado ,lindo e maravilhoso.

quero ver usar active record na base de dados do banco… para min ruby não é feito para aplicações enterprise.

Bom, esta imagem explica muita coisa:

ps: desculpa , não resisti :lol:

Jesuino Master:

“Pedro de Lara”:

Cada qual com o seu cada qual. Sem o seu cada qual todo mundo é igual!

Que isso pessoal. Parem de brigar. Confesso que já ouvi um monte de rubistas e alguns poucos “pythonistas” atacando o Java. Ontem mesmo em um grupo que participo me atacaram pq usei Java e tals…

Essas coisas são das duas uma: marketing ou imaturidade de quem critica o outro…

E outra coisa, são duas tecnologias Free, livres! Pronto! \o/

Pronto! Chegou o fanboy do opensource… pode trancar o tópico.

Eu acho que não faz sentido criticar Ruby, dizer que é mais adequada para projetos pequenos, apenas por um caso pontual, baseado em questões técnicas que desconhecemos em profundidade, e de um projeto completamente atípico como é o Twitter. E quem acha por conta disso que Java é a bala de prata também está errado. Provavelmente foi uma decisão conveniente de acordo com a base instalada deles. Se o twitter fosse iniciado agora, não há garantias de que seria feito parcialmente ou completamente em Java.

E esse papo de Java vai acabar, nunca comentei nada disso pq achei besteira.

Na empresa que eu estava o que mais contratava era Cobol e C, e eu estava muito bem empregado com ABAP e ainda hoje recebo muitas propostas, ambas linguagens < 90…

Quantidade de linhas de código não definem uma tecnologia como morta/viva.

A plataforma Java nunca parou também, por outro lado, sofreu a maior prova nos últimos anos e mostrou estar preparada para muitas empreitadas… Modularidade, Closures, Mirah, JRuby, Groovy, Scala são exemplos…

E outro dia aqui o pessoal falando que o Java 8 já está em movimento :o [acho]Cada release tem um tempo de vida de ~6 anos[acho], Java 7 nem foi lançado oficialmente, ou seja, temos muitos anos pela frente…

Isso pq agora cheguei no JEE 6 :o Que evolução! Olha que eu comecei com JEE 5 e já vejo o 6 como uma super evolução.

É claro que temos que estudar bastante para aprender os padrões por trás do mundo Java e fazer um sistema enterprise (IoC, ORM e coisas a lot), mas no pain no gain E sistemas bem feitos ficam por ae por anos com total flexibilidade e boa performance. Viva!

Isso pq nem tenho tantos conhecimentos tão avançados como alguns aqui para apontar mais pontos fortes e pontos para se trabalhar, estou vendo as coisas a nível de desenvolvedor ainda

Sei que é fora do foco do tpc, mas rachei da parte “Haskel Programmers” da imagem… kkkkkk

Nada contra haskel, mas sério, ainda não vi ninguém programando em haskel ahuahuhah… o quadrinho “Assembly programmers” também fico legal d+ hehe

Pessoal não existe linguagem perfeita, essas discussões me lembram Java VS .NET, vai longe…

Não existe bala de prata…

Desculpem, mas essa discussão toda me lembrou esse quadro comparativo:

Ri muito inclusive da minha situação uhahuauhauhauhauhauhau

Ah… não vou discutir qual linguagem é melhor, qual escala, qual isso, qual aquilo… Mesmo porque programo nas duas… srrssr

Mas que vou encher o saco dos meus amigos rubistas, ah isso eu vou… :twisted: :twisted: :twisted: :twisted: :twisted: huauhahuahuuhauhahuauhauhhua

Crianças, hora de dormir… A brincadeira tava boa, mas tá na hora ´de alguém trabalhar de verdade… srrsrssrrss

Pra mim, o link serviu pra duas coisas: mostrar que Ruby não é solução pra tudo, como os fanboys adoram dizer. E mostrar que Java ainda tem muita, muita força e continua a crescer, ao contrário do que os profetas do apocalipse adoram pintar.

E que venha o Java 7 dessa vez!

Obs: eu, como fã de Haskell, sofri com a piada. heheheh

Muito boa esta nova arquitetura do twitter… o ganho de performance foi demais. :shock:
Vou defender a minha linguagem tbm… a melhor é a C kkkkk

Acredito que isso em nenhum momento dismerece a linguagem, é somente um caso é importante falar que linguagens são ferramentas e não religiões.
Comparar linguagem é como comparar garfo de faca cada situação é mais indicada.

Felagund:

Diabo Loiro:

isso é pra mostrar mais uma vez que o java não esta morrendo, como o pessoal da moda alega geralmente.

que cada linguagem é aplicada a um tipo de projeto, e pelo que parece ruby é para projetos menores e faz muito bem isso.

Caramba cara, realmente acho que a Globo.com, Groupon não tem requests suficientes para ser considerado um projeto grande usando Ruby né.

Cara, sai desse mundo de Java é o melhor e vai aprender mais coisas, aprender que não interesse o que seu time mais sabe e sim a melhor linguagem pro projeto…

O globo.com é feito em python não?

Eu acho que, vendo o porte que o twitter tem, a linguagem pouco importa.
Pelo que eu entendi eles usaram o java ali muito mais por causa do netty…

Mas a galera podia pegar mais leve na trollagem, né… ruby on rails continua sendo fantástico!
E para quem nunca usou, aconselho a dar uma olhada. Isso vai torná-los melhores programadores java.
O fanboyzismo também é inevitável… eu tenho minhas quedas por C++ e Python, é só não exagerar e iniciar flame só por isso

[modo fanboy=“on”]
Só num fala mal do “gcc” QUE A CASA CAI!
[modo fanboy=“off”]

nofan:

Felagund:

Diabo Loiro:

isso é pra mostrar mais uma vez que o java não esta morrendo, como o pessoal da moda alega geralmente.

que cada linguagem é aplicada a um tipo de projeto, e pelo que parece ruby é para projetos menores e faz muito bem isso.

Caramba cara, realmente acho que a Globo.com, Groupon não tem requests suficientes para ser considerado um projeto grande usando Ruby né.

Cara, sai desse mundo de Java é o melhor e vai aprender mais coisas, aprender que não interesse o que seu time mais sabe e sim a melhor linguagem pro projeto…

O globo.com é feito em python não?

A maioria desses grandes portais utilizam várias tecnologias, eu sei que tambem tem projeto em Rails rodando lá sim.

Anyway, esses fanboys xiitas nunca vão muito longe…

onde ficam os “girl fanboys”?

fangirls?

Engraçado que a maior parte das pessoas fala e reclama e briga mas não em a menor noção do real problema. O problema do twitter e da maior parte dos sites de porte absurdo (e não grande porte, grande porte é o sitezinho da igreja) é que chega a um momento em que milisegundos fazem diferença do ponto de vista financeiro e também de uso. Pra maior parte dos sites feitos hoje, demorar 800 milisegundos pra trazer um resultado é normal, natural até, quem faz site usando JSF e componentes de terceiros provavelmente está bem pior do que isso porque a maior parte desses arquivos são enviados via filtros e não diretamente como arquivo pelo servidor HTTP e o tempo vai ser tão ruin quanto seria se fosse feito em Ruby, mas ninguém vai se preocupar com isso porque você vai ter lá os seus 5 usuários simultâneos rodando dentro de uma intranet da vida.

O twitter chegou onde chegou porque eles tinham um turnaround altíssimo em Ruby pra adicionar novas funcionalidades e criar coisas novas, coisas que eles não teriam no início em Java e qualquer pessoa que já tenha feito um projeto web em java na vida sabe exatamente isso. A linguagem se prestou perfeitamente pra transformar o site no sucesso que ele é hoje, mas infelizmente o interpretador do Ruby está anos luz atrás da JVM, na verdade TODOS os interpretadores da atualidade comem poeira feio pra JVM a exceção do Mono e do .Net runtime da Microsoft. PHP? Python? Perl? Todos brincadeira de criança quando comparados ao trabalho de engenharia que levou a máquina virtual do Java que nós temos hoje.

Pro twitter cortar esses milisegundos foi não apenas uma diminuição de custos de hardware como também uma melhora do ponto de vista do usuário que vai notar uma diferença grande na busca final.

O problema é da linguagem? Sim e não, o problema é do interpretador primitivo (assim como os do Python, Php e Perl ) e das vantagens que a linguagem oferece e que também e transformam em custos em tempo de execução para o interpretador. Não existe almoço grátis, ter classes abertas, closures, tudo como sendo objetos em Ruby tem um custo alto no tempo de execução. A grande pergunta que as pessoas devem fazer é, será que esse custo se paga pro meu caso? Será que ter todas essas vantagens hoje do ponto de vista da linguagem cobrem as desvantagens da compicação que é pro interpretador lidar com isso?

Teoricamente, deveríamos todos ser partidários da lógica, já que somos todos programadores, mas as pessoas teimam em trbalhar com tecnologia como times de futebol, defendendo um em detrimento do outro, precisamos deixar dessa infantilidade e enxergar os fatos pelos fatos. Me dá pena ver pessoas que criam “ódio” por ferramentas, frmeworks ou linguagens de programação sem nem ao menos tê-los testado, porque essas pessoas simplesmente sinalizam que não serão capazes de continuar no mercado de TI, que é necessariamente sincretista e propenso aos meshes de coisas completamente diferentes.

Vivemos eternamente no problema onde a única ferramenta a mão é o martelo e queremos que tudo o que aparece na nossa frente são pregos.

Mauricio Linhares:

Engraçado que a maior parte das pessoas fala e reclama e briga mas não em a menor noção do real problema. O problema do twitter e da maior parte dos sites de porte absurdo (e não grande porte, grande porte é o sitezinho da igreja) é que chega a um momento em que milisegundos fazem diferença do ponto de vista financeiro e também de uso. Pra maior parte dos sites feitos hoje, demorar 800 milisegundos pra trazer um resultado é normal, natural até, quem faz site usando JSF e componentes de terceiros provavelmente está bem pior do que isso porque a maior parte desses arquivos são enviados via filtros e não diretamente como arquivo pelo servidor HTTP e o tempo vai ser tão ruin quanto seria se fosse feito em Ruby, mas ninguém vai se preocupar com isso porque você vai ter lá os seus 5 usuários simultâneos rodando dentro de uma intranet da vida.

O twitter chegou onde chegou porque eles tinham um turnaround altíssimo em Ruby pra adicionar novas funcionalidades e criar coisas novas, coisas que eles não teriam no início em Java e qualquer pessoa que já tenha feito um projeto web em java na vida sabe exatamente isso. A linguagem se prestou perfeitamente pra transformar o site no sucesso que ele é hoje, mas infelizmente o interpretador do Ruby está anos luz atrás da JVM, na verdade TODOS os interpretadores da atualidade comem poeira feio pra JVM a exceção do Mono e do .Net runtime da Microsoft. PHP? Python? Perl? Todos brincadeira de criança quando comparados ao trabalho de engenharia que levou a máquina virtual do Java que nós temos hoje.

Pro twitter cortar esses milisegundos foi não apenas uma diminuição de custos de hardware como também uma melhora do ponto de vista do usuário que.

O problema é da linguagem? Sim e não, o problema é do interpretador primitivo (assim como os do Python, Php e Perl ) e das vantagens que a linguagem oferece e que também e transformam em custos em tempo de execução para o interpretador. Não existe almoço grátis, ter classes abertas, closures, tudo como sendo objetos em Ruby tem um custo alto no tempo de execução. A grande pergunta que as pessoas devem fazer é, será que esse custo se paga pro meu caso? Será que ter todas essas vantagens hoje do ponto de vista da linguagem cobrem as desvantagens da compicação que é pro interpretador lidar com isso?

Teoricamente, deveríamos todos ser partidários da lógica, já que somos todos programadores, mas as pessoas teimam em trbalhar com tecnologia como times de futebol, defendendo um em detrimento do outro, precisamos deixar dessa infantilidade e enxergar os fatos pelos fatos. Me dá pena ver pessoas que criam “ódio” por ferramentas, frmeworks ou linguagens de programação sem nem ao menos tê-los testado, porque essas pessoas simplesmente sinalizam que não serão capazes de continuar no mercado de TI, que é necessariamente sincretista e propenso aos meshes de coisas completamente diferentes.

Vivemos eternamente no problema onde a única ferramenta a mão é o martelo e queremos que tudo o que aparece na nossa frente são pregos.

Concordo plenamente com o Mauricio, principalmente na parte de termos torcedores ao invés de profissionais.

marcio_gs:

Mauricio Linhares:

Engraçado que a maior parte das pessoas fala e reclama e briga mas não em a menor noção do real problema. O problema do twitter e da maior parte dos sites de porte absurdo (e não grande porte, grande porte é o sitezinho da igreja) é que chega a um momento em que milisegundos fazem diferença do ponto de vista financeiro e também de uso. Pra maior parte dos sites feitos hoje, demorar 800 milisegundos pra trazer um resultado é normal, natural até, quem faz site usando JSF e componentes de terceiros provavelmente está bem pior do que isso porque a maior parte desses arquivos são enviados via filtros e não diretamente como arquivo pelo servidor HTTP e o tempo vai ser tão ruin quanto seria se fosse feito em Ruby, mas ninguém vai se preocupar com isso porque você vai ter lá os seus 5 usuários simultâneos rodando dentro de uma intranet da vida.

O twitter chegou onde chegou porque eles tinham um turnaround altíssimo em Ruby pra adicionar novas funcionalidades e criar coisas novas, coisas que eles não teriam no início em Java e qualquer pessoa que já tenha feito um projeto web em java na vida sabe exatamente isso. A linguagem se prestou perfeitamente pra transformar o site no sucesso que ele é hoje, mas infelizmente o interpretador do Ruby está anos luz atrás da JVM, na verdade TODOS os interpretadores da atualidade comem poeira feio pra JVM a exceção do Mono e do .Net runtime da Microsoft. PHP? Python? Perl? Todos brincadeira de criança quando comparados ao trabalho de engenharia que levou a máquina virtual do Java que nós temos hoje.

Pro twitter cortar esses milisegundos foi não apenas uma diminuição de custos de hardware como também uma melhora do ponto de vista do usuário que.

O problema é da linguagem? Sim e não, o problema é do interpretador primitivo (assim como os do Python, Php e Perl ) e das vantagens que a linguagem oferece e que também e transformam em custos em tempo de execução para o interpretador. Não existe almoço grátis, ter classes abertas, closures, tudo como sendo objetos em Ruby tem um custo alto no tempo de execução. A grande pergunta que as pessoas devem fazer é, será que esse custo se paga pro meu caso? Será que ter todas essas vantagens hoje do ponto de vista da linguagem cobrem as desvantagens da compicação que é pro interpretador lidar com isso?

Teoricamente, deveríamos todos ser partidários da lógica, já que somos todos programadores, mas as pessoas teimam em trbalhar com tecnologia como times de futebol, defendendo um em detrimento do outro, precisamos deixar dessa infantilidade e enxergar os fatos pelos fatos. Me dá pena ver pessoas que criam “ódio” por ferramentas, frmeworks ou linguagens de programação sem nem ao menos tê-los testado, porque essas pessoas simplesmente sinalizam que não serão capazes de continuar no mercado de TI, que é necessariamente sincretista e propenso aos meshes de coisas completamente diferentes.

Vivemos eternamente no problema onde a única ferramenta a mão é o martelo e queremos que tudo o que aparece na nossa frente são pregos.

Concordo plenamente com o Mauricio, principalmente na parte de termos torcedores ao invés de profissionais.

Concordo plenamente com o Mauricio, principalmente na parte de termos torcedores ao invés de profissionais. [2]

E só pra complementar um pouco mais, estou trabalhando atualmente exatamente em migrar o backend da empresa de Ruby pra Java, porque estamos tendo um aumento muito grande na quantidade de acessos e os processos em Ruby consomem muito tempo implementando mágica que não precisamos já que o trabalho é basicamente fazer parse de XML, JSON, gerar imagens de PDF e extrair texto de PDFs. O problema é simples e as soluções em java tem um ganho de performance absurdo contra qualquer outra linguagem. Com os benchmarks que fizemos aqui, a extração de texto de arquivos PDF demorava 0.1 segundos em Java e 0.25 com um SDK de terceiros em C e precisamos que isso seja o mais rápido possível, se em C fosse mais rápido, com certeza teríamos ficado com a solução em C.

Já na nossa aplicação web, existe zero de interesse de re-escrever ela em Java, ela é toda em Ruby e deve continuar assim por muito tempo ainda já que ela atende muito bem as nossas necessidades atuais. No dia que ela não atender mais, vamos com certeza mudá-la para que ela seja a melhor possível para os nossos clientes.

Acho que todo mundo deveria por na cabeça que o único time que existe é o time do cliente e você está sempre jogando nele, então é o seu trabalho procurar a melhor solução tecnológica pra ele. E pra fazer isso você tem que procurar conhecer novas tecnologias e novas formas de se resolver os problemas. A comunidade Java produziu muita coisa interessante, gerou projetos que todos nós dependemos até hoje, mas será que não existem em outras linguagens outras soluções que podem ser melhores pros nossos problemas.

Torça pro seu time de futebol, mas pegue todas as linguagens de programação, é a melhor forma de levar a sua carreira de TI, tanto do ponto de vista profissional quanto financeiro, pois quanto mais você sabe, mais você vale e mais vão pagar pelo seu passe.

Na verdade isso tem mais a ver com a API de NIO que utilizaram e design assíncrono /Event-driven. Quando falamos nesse tipo de arquitetura, significa: imutabilidade de objetos, não blocante ! Lembrando que essa é a chave, pois eles lidam com streams.

O Rails é um framework Request-Driven, síncrono e isso traz problemas quando você precisa escalar para milhares de nós, entrentato em Ruby você poderia escrever design Non-Blocking, event-driven utilizando Goliath, que utiliza Fibers ( Ruby 1.9) para endereçar - http://www.infoq.com/news/2007/08/ruby-1-9-fibers.

Dêem uma lida em performance: http://postrank-labs.github.com/goliath

Para Java e Scala, existe uma alternativa bem bacana para esse tipo de design, que é a utilização de Actors Model com Akka Framework - http://www.akka.io , desenhado pelo Jonas Bóner, engenheiro do Terracota.

O Akka trabalha com isolamento, atores remotos acessados através do Protobuf - http://code.google.com/p/protobuf e isso garante uma rápida comunicação.

Uma outra solução, seria utilizar SEDA (http://www.eecs.harvard.edu/~mdw/proj/seda) e talvez até mesclar, implementar SEDA com ActorsModel.

Resumindo, a JVM é parruda e ninguém discute, entretanto se utilizar com a arquitetura “convencional” request-driven síncrono, talvez o benefício não seja tão grande.

A questão da equipe do Twitter pode ter sido maturidade dos projetos, já que o Netty possui mais tempo e o código dele realmente é limpo, olhei o repositório logo quando vi a notícia, enquanto o Akka que eu citei, é muito sujo, pessoal que vem do C.

Como o Maurício disse, também acho que estão fugindo muito por aqui da discussão técnica e caindo para o mesmo pensamento que critico em developers Microsoft, que não enxergam um palmo à sua frente.

Todas as linguagens são interessantes, gostaria de ter tempo pra estudar diversas outras, pois cada linha de pensamento diferente, como programação funcional do lisp e haskell, ou a facilidade de metaprogramação do Ruby vai te tornar um programador melhor.

Quem aqui já escreveu uma DSL ? Veria Ruby com outros olhos.

Pra finalizar: Isso aqui não é futebol pra ter torcida !!

PS: Gostaria de discutir por aqui alternativas de design, SEDA vs Actors, combinação, Fibers - JVM e por aí vai…

º´~s

Kenobi

É importante lembrar também que usar IO assíncrono não significa ser mais rápido, IO assíncrono normalmente é mais lento que IO síncrono, as pessoas procuram IO assíncrono porque elas reduzem a quantidade de threads necessárias pra fazer o mesmo trabalho, já que você não precisa de uma thread lendo e outra escrevendo do socket pra fazer o trabalho e com menos threads você estressa menos o SO e fica mais fácil de aceitar uma quantidade maior de clientes, já que a quantidade de threads que podem existir no SO é finita e cada thread também aumenta o trabalho do scheduler e o consumo de memória com o seu stack.

Bem lembrando Maurício, inclusive o Porcelli fez uma experimento com o Akka e o achou lento, comparando ao multithread tradicional, entretanto a proposta do mesmo é escalabilidade.

Acredito que vão conseguir ainda otimizar e comunicação remota é uma das coisas que pega em qualquer ambiente distribuído.

Falando no design de Actors, na verdade a Thead fica em Loop, esperando atores processarem, portanto, uma Thread consegue endereçar diversos atores, consequentemente respondendo a diversos requests.

Mauricio Linhares:

E só pra complementar um pouco mais, estou trabalhando atualmente exatamente em migrar o backend da empresa de Ruby pra Java, porque estamos tendo um aumento muito grande na quantidade de acessos e os processos em Ruby consomem muito tempo implementando mágica que não precisamos já que o trabalho é basicamente fazer parse de XML, JSON, gerar imagens de PDF e extrair texto de PDFs. O problema é simples e as soluções em java tem um ganho de performance absurdo contra qualquer outra linguagem. Com os benchmarks que fizemos aqui, a extração de texto de arquivos PDF demorava 0.1 segundos em Java e 0.25 com um SDK de terceiros em C e precisamos que isso seja o mais rápido possível, se em C fosse mais rápido, com certeza teríamos ficado com a solução em C.

Já na nossa aplicação web, existe zero de interesse de re-escrever ela em Java, ela é toda em Ruby e deve continuar assim por muito tempo ainda já que ela atende muito bem as nossas necessidades atuais. No dia que ela não atender mais, vamos com certeza mudá-la para que ela seja a melhor possível para os nossos clientes.

Acho que todo mundo deveria por na cabeça que o único time que existe é o time do cliente e você está sempre jogando nele, então é o seu trabalho procurar a melhor solução tecnológica pra ele. E pra fazer isso você tem que procurar conhecer novas tecnologias e novas formas de se resolver os problemas. A comunidade Java produziu muita coisa interessante, gerou projetos que todos nós dependemos até hoje, mas será que não existem em outras linguagens outras soluções que podem ser melhores pros nossos problemas.

Torça pro seu time de futebol, mas pegue todas as linguagens de programação, é a melhor forma de levar a sua carreira de TI, tanto do ponto de vista profissional quanto financeiro, pois quanto mais você sabe, mais você vale e mais vão pagar pelo seu passe.

Interessante esse caso. Está aí uma demonstração do enorme poder da plataforma Java. Pena que não há como comparar com todas as plataformas…

Olá

Só para reafirmar alguns conceitos…

IO pode ser bloqueante e não bloqueante. IO bloqueante é sempre síncrono. IO não bloqueante pode ser síncrono (padrão Reactor) ou assíncrono (padrão Proactor).

E o Maurício tem razão. IO Assíncrono não garante operação mais rápida do que IO síncrono (para fazer uma única coisa por vez). Até porque para ser assíncrono precisa usar software muito mais complexo. Mas se a gente trabalha com recursos finitos, IO assíncrono não bloqueante permite usar os mesmos recursos de forma mais efetiva e responder maior número de solicitações. E também facilita o aumento de recursos escalando horizontalmente.

Outra coisa que quero lembrar…

O Netty atual foi feito pelo coreano Trustin Lee que fez o Apache Mina baseado no antigo Netty igualmente feito por ele. Como o próprio manual do Netty chama a atenção, tratar Streams tem lá suas dificuldades. O tem um modelo de threads que atende um modelo de eventos tal como o SEDA.

E atenção que o Netty também tem a fragilidade de ter pouca gente que o entenda e capaz de evoluí-lo. Com a notícia desta semana que o Trustin Lee está procurando emprego, aumentaram minhas preocupações. Mesmo assim pretendo usar em um próximo projeto porque acho melhor do que o Mina e já fracassei tentando usar o Grizzly.

Quanto ao Akka acompanho o projeto com muito interresse, acho que pode ser muito útil para trocar mensagens, mas para construir um servidor ou um gateway, a menos que futuros testes me provem em contrário, o Netty ainda é meu favorito.

Abraços
Luca Bastos

Acredito que esse foi o maior motivo por optarem em mudar a arquitetura. Hoje o Twitter é muito acessado através de suas apis e possui integração com os mais diferentes devices, gerando uma quantidade de tráfego altíssima.

Por tanto, performance não era somente o objetivo. Acredito que foi um efeito colateral provido pela JVM e uma linguagem estaticamente tipada.

Posso estar errado, mas o maior problema era escalonamento, o que não é fácil de fazer com a arquitetura Rails. Eles conseguiram isso no backend, criando um filhote de AMQP em Scala, mas faltava resolver o input.

Luca, você que estudava SEDA também, o que você acha do Blend - http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html ? Vi que o Netty faz pools de thread, na documentação.

PS: Coisinha pra estudar: http://en.wikipedia.org/wiki/Directed_acyclic_graph

Olá

Kenobi:

Luca, você que estudava SEDA também, o que você acha do Blend - http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html ?

Realmente, já tive meus tempos de entusiasmo com o SEDA. Principalmente depois que assisti uma palestra sobre seu uso em um projeto de telecom. Mas é tudo muito complicado. A menos que algum especialista crie um framework (como o Netty), é muito difíicil fazer algo com o SEDA.

Sobre o blender tudo que sei é o que está no texto da notícia. E me parece que NÃO se refere a front end como está no título deste tópico e no Infoq. Desconfio que meu entendimento sobre o que é front end não é o mesmo do Eder Magalhães. Mas posso estar errado porque para mim frameworks baseados em componentes como Wicket e JSF pecam justamente por misturar excessivamente front end com back end.

Abraços
Luca Bastos

Acredito que Frontend se trata da API Rest em cima de HTTP, que recebe os streams (inputs). Também acho que não tem a ver com a interface gráfica, pois poderia fazer algo completamente besta, usando JQuery diretamente se quisesse.

nunca a frase “não existe bala de prata” fez tanto sentido.

O Twitter tem um problema e trocar Ruby para Java resolve. Não diminui o Ruby em nada, pelo contrario a comunidade poderia se esforçar duplamente para fornecer uma alternativa nesse caso. A maquina virtual de Smalltalk é mais antiga que a jvm e ruby e pode ser uma boa fonte de inspiração (MagLev?).

Perl, quando vc programa com Moose ou Mouse (frameworks que adicionam uma camada de orientação a objetos em runtime, tornando mais legivel e meta programavel) existe a opção de tornar a Classe imutável, assim não é possivel adicionar metodos on the fly porém uma camada em XS é criada acelerando o resto da classe e benchmarks mostram um ganho consideravel. Claro que existem outros problemas, mas talvez Ruby tenha que ir fazer uma escolha dessas: abrir mão do monkey patching em determinados momentos.

Vejamos as cenas dos próximos capitulos. Será que vão migrar tudo para Go?

Tiago, dá uma lida nas minhas colocações, do Luca e Maurício. Acho que o caminho está muito mais em design da solução que linguagem :-).

Mas não adianta trocar o design se a implementação não acompanha

Luca, só uma curiosidade, o Mule implementa Seda então, para muitos cenários de integração você pode usar Seda facilmente :-).

Tiago, linguagem dinamicamente tipada vai ter uma performance inferior e talvez isso com o tempo seja amenizado, até mesmo pela JVM com suporte à linguagens dinâmicas - JSR 292. Para os amantes de Ruby há o Mirah, uma linguagem parecidíssima com Ruby, onde a diferença básica consiste em tipos.

Com essa diferença, a performance de Mirah é comparável à outras linguagens como Scala.

Mas ainda acho, que o problema estava muito mais no escalonamento e não na performance, até pq como disseram, se quisessem somente performance talvez tivessem usado uma outra abordagem.

Um abraço,

Kenobi - akka @scaphe

O site do twitter vive dando problema, muito mau feito, se é culpa da linguagem não sei, mas se eles são ninjas e rockstars não conseguem fazer um sistema rails decente, imagina nós, pobre mortais.

Diabo Loiro:

quero ver alguem que ja trabalhou em alguma aplicação de um banco gigantesca enterprise, aprender ruby, tudo facinho , codigo gerado ,lindo e maravilhoso.

quero ver usar active record na base de dados do banco… para min ruby não é feito para aplicações enterprise.

Senhor Certified, eu teria vergonha de publicar isso que você escreveu em um fórum público. Procure estudar mais!

Acho que esses caras que começaram a discutir a partir da página 5 deveriam comparecer mais vezes ao GUJ. A discussão deu uma melhorada animal.

Ruby ainda tem muito que evoluir ,está mil anos do Java e .Net no mercado corporativo. Pra pagina da padaria do Tio Joao o Ruby realmente eh bem mais agil . Agora pra mercado corporativo…

Por favor, não alimentem os trolls novamente nesse tópico!

[]s

É mais fácil o site da padaria do Tio Joào, que tem algumas centenas de clientes, cair, do que uma aplicação “corporativa” numa intranet sendo usada por 5 pessoas.

Enquanto isso como antecedia a imagem postada:

FIGHT !!! FIGHT !!! FIGHT !!! FIGHT !!! FIGHT !!! FIGHT !!!

Com certeza! Lendo a discussão de pessoas assim percebo quanto tenho ainda a aprender. Houve uma ótima discussão do Luca e do Kenobi no Tectura também.

Poderia ter mais discussões desse nível no GUJ a comunidade agradece.

Se vc lembrar de algum tempo atrás, vai ver que tinham muitas discussões de alto nível, mas com a proliferação dos trolls e de quem os alimenta, quem tem conteúdo interessante pra compartilhar acaba indo pra outros lugares.

[]s

saudades do guj…

Ruby foi bom por um tempo, agora pra manter o ritmo de crescimento os caras precisão de uma linguagem mais robusta onde Java se aplica perfeitamente, as complicações que envolvem um crescimento exponencial é inerente ao desenvolvimento de soluções escaláveis, Java está pronto a anos luz para isso! Eles deveriam ter escolhido Java desde o começo do projeto, se pensavam em um crescimento tão rápido.

Acho que nem o mais otimista dos investidores previa que o Twitter ia chegar onde já chegou, e pagando isso como raciocínio, eles estão fazendo a coisa certa mesmo.
Usaram uma tecnologia que lhes desse uma produtividade grande no início pra ter um “startup” rápido no mercado, e foram evoluindo sua arquitetura conforme a necessidade foi surgindo. Lembrando que a primeira troca que fizeram de Ruby por Scala, também teve falha técnica da equipe do Twitter que fez uma implementação de tosca de um componentes Ruby e acabou não lhes atendendo, possivelmente eles trocariam mais pra frente, mas essa falha antecipou uma escolha por trocar o componente.
Se hoje a necessidade que eles tem, vai ser suprida com o uso da JVM (e os componentes que rodam sobre ela, como o próprio Scala), então realmente fizeram a escolha correta e estão mais uma vez escalando sua arquitetura.
Independente do uso da tecnologia X ou Y, acho que hoje o Twitter é um case a ser estudado em termos de arquitetura e como gerir a escalabilidade da mesma, alguns podem chegar a conclusões ruim, outros a boas, mas de toda forma, merece ver mais de perto e absorver os pontos que podem ser usados em nossas decisões de arquitetura no dia-a-dia.

[]s

Esse era outro problema do Twitter, eles começaram como um Ruby Shop shiita como o pessoal que estava brigando aqui nessa thread era Java Shiita também e acharam que valia a pena inventar os seus próprios componentes em Ruby pra tudo, como o Starling/Workling pra filas de mensageria, que eram basicamente uma atrocidade. Pobres de código, instáveis e pouco testados, quando haviam diversas soluções em Java e em Erlang pra resolver esse problema.

Acho que hoje eles finalmente estão indo no caminho certo, indo onde a boa tecnologia está e não tendo mais “opiniões” sobre o que deve ser usado ou não. Agora se usa o que dá mais certo pro problema em questão.

Com certeza! Lendo a discussão de pessoas assim percebo quanto tenho ainda a aprender. Houve uma ótima discussão do Luca e do Kenobi no Tectura também.

Poderia ter mais discussões desse nível no GUJ a comunidade agradece.

O Kenobi é um dos melhores arquitetos que frequentam o GUJ. Geralmente os posts dele são uma verdadeira aula. heheh

O nível do GUJ já foi bem mais alto mesmo, caiu bastante com a chegada de vários trolls, mas recentemente vem melhorando o nivel de novo.

:shock:

Twitter é um aplicação web, isso quer dizer:

1. pode mudar a linguagem quando quiser sem afetar seu funcionamento

2. twitter não deu certo porque “escalonava” e sim porque foi adotado pelos usuários, e pra isso a linguagem não teve a menor importância, e sim o produto. Se tivessem focado em “linguagem robusta” como vc sugeriu provavelmente teriam fracassado, e não teria os “problemas” que tem agora.

3. Twitter mudou para aumentar performance em milisegundos, não para aumentar escalabilidade. Até porque escalabilidade na web se da por meio do uso correto do HTTP, novamente a linguagem usada em cada servidor não influencia muito. Para sua informação, o sistema mais acessado do mundo é feito em PHP.

Se estiver falando do Facebook, a forma como eles trabalham com PHP não é a mais trivial, tanto que existe o projeto HipHop para converter o php em C++

http://developers.facebook.com/blog/post/358/

Agora, o facebook mesmo é um exemplo de aplicação que não é 100% HTTP pois no seu interior existem filas assincronas e mensageria que utiliza outras tecnologias como XMPP. O twitter mesmo utiliza mecanismos de detecção de spam assincronos, por exemplo. Não vamos simplificar os sistemas demais

peczenyj:

Se estiver falando do Facebook, a forma como eles trabalham com PHP não é a mais trivial, tanto que existe o projeto HipHop para converter o php em C++

http://developers.facebook.com/blog/post/358/

Acho que é trivial quando se tem ex-engenheiros do google. :twisted:

Acho que nem o mais otimista dos investidores previa que o Twitter ia chegar onde já chegou, e pagando isso como raciocínio, eles estão fazendo a coisa certa mesmo.
Usaram uma tecnologia que lhes desse uma produtividade grande no início pra ter um “startup” rápido no mercado, e foram evoluindo sua arquitetura conforme a necessidade foi surgindo. Lembrando que a primeira troca que fizeram de Ruby por Scala, também teve falha técnica da equipe do Twitter que fez uma implementação de tosca de um componentes Ruby e acabou não lhes atendendo, possivelmente eles trocariam mais pra frente, mas essa falha antecipou uma escolha por trocar o componente.
Se hoje a necessidade que eles tem, vai ser suprida com o uso da JVM (e os componentes que rodam sobre ela, como o próprio Scala), então realmente fizeram a escolha correta e estão mais uma vez escalando sua arquitetura.
Independente do uso da tecnologia X ou Y, acho que hoje o Twitter é um case a ser estudado em termos de arquitetura e como gerir a escalabilidade da mesma, alguns podem chegar a conclusões ruim, outros a boas, mas de toda forma, merece ver mais de perto e absorver os pontos que podem ser usados em nossas decisões de arquitetura no dia-a-dia.

[]s

Desculpa corrigindo, onde lê-se linguagem refiro-me a plataforma, (falha tosca…). Sim concordo, Ruby garante sim uma alto produtividade, mas o que me referia é que se implemento um projeto de Micro-Blog, espero sim uma alta adesão , mesmo em sonho! Daí escolher desde o inicio a melhor plataforma para essa arquitetura é só previsão de mercado, exercício simplista de qualquer inicio de projeto. Não estou questionando que Ruby não dá conto do serviço, pelo visto, até agora ele se garantiu muito bem! Só que estou querendo puxar um brasa pra nossa sardinha… Java é a melhor plataforma escalável do mercado! E isso evita um bocado de reestruturação futura como neste caso.

Eu também acho que um dos motivos para eles escolherem utilizar java foi a maturidade do projeto netty. Trabalho em um projeto de integração entre sistemas que trocam informações em tempo real. A maioria dos sistemas é escrita em c ou c++ e qualquer latência que é colocada no percurso da informação (que vem de bolsas
de valores) é ruim para o negócio da empresa, já que um dos motivos dos produtos da empresa serem um sucesso é justamente o tempo de resposta. No início do projeto utilizamos webservices soap porém logo ficou claro que eles seriam uma barreira para a performance (como já esperávamos), então modificamos a implementação de referência para utilizar webservices rest utilizando o jax-rs, o que melhorou muito a performance da aplicação. Conseguimos também melhorar
o tempo de resposta utilizando um mecanismo de cache distribuído que implementamos utilizando um produto da oracle (Oracle Coherence), mas mesmo assim, em algumas situações, dependendo do número de acessos simultâneos, o tempo de resposta poderia comprometer o funcionamento das aplicações. Eu cheguei a implementar uma nova forma de acesso utilizando nio com io “não blocante”, o que obviamente melhorou a performance comparando com a implementação utilizando
o jax-rs, porém, para utilizar esta nova implementação, as outras aplicações teriam que ser todas alteradas para conectar-se diretamente via sockets ao invés de utilizar o protocolo http para as chamadas rest e, além disso, a manutenção da aplicação seria mais complicada, já que a maioria dos desenvolvedores não estava acostumada com o desenvolvimento utilizando sockets, nio, etc.
Foi aí que conheci a biblioteca netty e estudei o seu funcionamento. Desenvolvi os mesmos cenários anteriores utilizando esta biblioteca para processar as requisições rest que necessitavam de performance maior e realizando os testes de performance foi constatado que a performance era pior do que a implementação com sockets e nio (o que era esperado, já que mesmo utilizando a biblioteca netty as chamadas ainda eram feitas utilizando o protocolo http), porém a performance foi extremamente mais rápida se compararmos com as implementações do jax-rs (testei com o apache-cxf e jersey), mesmo eu tendo separado esta camada da aplicação e realizado o deploy no jetty e no tomcat em servidores diferentes dos que faziam parte do cluster do servidor de aplicações. A meu ver isto tem a ver com o fato de, com a biblioteca netty, podermos implementar um servidor http bem mais leve e dedicado ao trabalho que queremos fazer, ou seja, ao invés de termos um container web ou um servidor de aplicações “genérico” que, além de atender as requisições web, tem que “se preocupar” com vários outros processos da aplicação e dividir os recursos com todos estes processos, temos um pequeno servidor http extremamente leve, dedicado apenas a uma pequena parte da aplicação e com todos os recursos disponíveis utilizados para processar estas requisições. Desta forma nós distribuímos esta nova camada da aplicação desenvolvida com o netty por alguns outros servidores (os mesmos que antes rodavam o tomcat ou o jetty), que ficaram responsáveis apenas por atender estas requisições mais críticas e as outras requisições continuaram na implementação padrão que foi criada inicialmente, no cluster original do servidor de aplicações.
A implementação utilizando a biblioteca netty revelou-se extremamente mais performática em todos os cenários de teste que fizemos, e por fim conseguimos atingir o tempo de resposta especificado para a aplicação, e nenhuma aplicação “na ponta” que faz chamada aos webservices rest precisou ser alterada. Além disso, os desenvolvedores acharam muito mais fácil trabalhar com a biblioteca netty do que programar com sockets, nio, etc, o que vai facilitar a manutenção da aplicação. Eu recomendo muito o estudo e implementação utilizando esta biblioteca para casos onde o tempo de resposta é um requisito não funcional de extrema importância.

Primeiro, obrigado marcosalex. Estou muitíssimo lisonjeado com seu comentário e espero fazer jus.

Rogério, bacana seu depoimento e um case prático para podermos estudar.

Bom, acho que muitos possuem visão divergente. Enquanto acredito que não se tratava somente de performance, outros decordam e isso é normal, já que estamos apenas conjecturando com base no que lemos.

Mas precisamos separar 2 coisas: Linguagem e VM - Virtual Machine.

Java não é uma linguagem tão bem desenhada e está anos luz à frente como disseram, pelo contrário. Ela tem falhas graves de design e não precisa nem ir muito longe, falar dos generics types. Basta olhar a API de data.

A VM entretanto é avançadíssima realmente e como o Maurício disse, vai demorar muito até outras chegarem no nível. Contudo, a idéia da VM é se tornar cada vez mais plural e talvez no futuro tenhamos uma outra linguagem, melhor desenhada, fazendo uso dos seus recursos.

Scala é uma forte candidata, isso sem contar com coisas que estão vindo, como The Ceylon Project - http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html

Cheers,

Kenobi

Scala mal desenhada ? De onde você tirou isso ? Scala é uma linguagem muitíssima bem desenhada. Aqui vai só um exemplo de types do Rafael - http://blog.rafaelferreira.net/2008/07/type-safe-builder-pattern-in-scala.html.

Com Scala você consegue ter programação funcional, oop, metaprogramação, script direto do shell (http://www.scala-lang.org/node/166). Se você pensar então em aplicações distribuídas, tem Actors embutida (http://www.scala-lang.org/node/242), Collections Paralelas http://infoscience.epfl.ch/record/150220/files/pc.pdf . Vale à pena estudá-la à fundo, antes de dizer que o design dela é ruim. Analisar superficialmente por uma sintaxe que você não compreende, é um grave equívoco.

Quanto à “oficial” eu não gosto muito dessa idéia, espero que com a evolução da JVM ao longo do tempo, perca o sentido e a liberdade de escolha em detrenimento à necessidades.

1 - Olhar para os dois lados antes de atravessar a rua;
2 - Nunca, nunca, mas nunca mesmo, alimentar os trolls.

Kenobi por favor não resposta os posts do malconL, isso serve para os outros também.

Adicionei esse tópico ao favoritos pra voltar aqui quando eu for gente grande e conseguir entender a maior parte o.O

Me senti A caloura do ano.

Alguém tem ideia de como é realizada a troca, como é que eles “dizem” que a partir de agora será uma o front de Java e não o de Ruby? Deve ter algum processo por trás disso, não deve ser só subir a versão :lol:

[mode troll on]
Com certeza se tivessem desenvolvido o twitter em assembly não teriam estes problemas
[mode troll of]

[color=olive](em ordem aleatória)[/color] kenobi, luca, marcosalex, chun, kicoloco, cv, vini godoy, josenaldo, thingol, paulo silveira, mauricio linhares, felegund… esses são os que lembro agora… sempre leio o que escrevem… todos muito bons!

[color=olive](em ordem aleatória)[/color] kenobi, luca, marcosalex, kicoloco, cv, vini godoy, josenaldo, thingol, paulo silveira, mauricio linhares, felegund… esses são os que lembro agora… sempre leio o que escrevem… todos muito bons!

esse felegund so eu? nossa quase chorei agora :shock:

qualquer latência que é colocada no percurso da informação (que vem de bolsas
de valores) é ruim para o negócio da empresa

Falta de integração é ruim. Se twitter usa http corretamente não precisava reescrever tudo pra ganhar 600 milisegundos.

Vergonha!

não vou nem me aprofundar nessa questão… :roll:

Kenobi:

A VM entretanto é avançadíssima realmente e como o Maurício disse, vai demorar muito até outras chegarem no nível. Contudo, a idéia da VM é se tornar cada vez mais plural e talvez no futuro tenhamos uma outra linguagem, melhor desenhada, fazendo uso dos seus recursos.

Scala é uma forte candidata, isso sem contar com coisas que estão vindo, como The Ceylon Project - http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html

Eu diria que já temos essa linguagem melhor desenhada e ela é Scala. Hoje Scala já é mais rápida que o Java inclusive pra muitos trabalhos, ela está evoluindo a passos largos e não tem nenhuma grande empresa enterprisey por trás pra congelar a linguagem numa versão específica. Já vi muita gente dizendo, inclusive, que as vezes a linguagem muda até demais.

Agora na versão 2.8 eles resolveram muitos dos pain points mais conhecidos (e reclamados) da linguagem e eu acredito que a partir de agora seja seguro investir na linguagem pra deployments em larga escala. Já temos muitos big players investindo e o ecosistema ao redor da linguagem só faz crescer. Além disso muitos dos frameworks conhecidos funcionam perfeitamente com ela, então você não perde o seu investimento já feito no Java.

Quanto a Ceylon, eu, pessoalmente, não boto fé. A idéia deles parece ser um Groovy 2, essa coisa de “vamos fazer um java mais legal” não vai muito longe não, porque você vai acabar batendo de frente com outros problemas que a linguagem tem e que não foram resolvidos porque fazem parte da cultura do java. Sem contar que eles ainda vão começar o projeto, existem vários detalhes pra serem encarados na hora de se implementar uma nova linguagem pra JVM e não e aprende isso do dia pra noite não.

Recomendo quem tiver interesse em ler mais sobre isso a ir dar uma olhada no blog do Charles Nutter, um dos desenvolvedores do JRuby, onde ele fala muito sobre como é desenvolver uma linguagem pra JVM.

Maurício. Interessante… A maioria dos programadores ruby que conheço prefere clojure.

Disse bem, programadores Ruby. Clojure é uma obra de arte, mas é distante demais do Java pra ter algum apelo real pro programador Java comum. Seria ótimo ver pessoas migrando pra Clojure hoje, mas eu não tenho fé que isso vá acontecer tão cedo. Scala é uma linguagem bem mais próxima e as chances de se ver programadores Java realmente usando ela são bem maiores.

Se qualquer uma das duas sair na frente eu já fico feliz, mas se Ceylon ou Groovy terminarem se tornando o padrão eu vou realmente ficar muito desapontado. Vamos ver o que o futuro guarda pras linguagens da JVM.

Na verdade os dois colegas nunca sairiam do GUJ, apenas não encontraram uma oportunidade para discutir o assunto.

Vamos valorizar os tópicos assim colocando opiniões e de preferência sempre citando as fontes.

Quanto à discussão desse tópico, cada caso é um caso, vejam o do Linkedin que começou com tudo em Java e hoje está com Scala/JRuby.

Na verdade os dois colegas nunca sairiam do GUJ, apenas não encontraram uma oportunidade para discutir o assunto.

Vamos valorizar os tópicos assim colocando opiniões e de preferência sempre citando as fontes.

Quanto à discussão desse tópico, cada caso é um caso, vejam o do Linkedin que começou com tudo em Java e hoje está com Scala/JRuby.

OMG, isso quer dizer que java não é enterprise? Corram para as colinas

sim, é vc!

acreditem se quiser, mas tem gente que acha que a decisão do twitter por mudar pra java foi equivocada, que ‘nem tudo é performance’ etc… vai entender… :roll:

No caso do twitter, foi. Mas tem muitos casos que é melhor o sistema ficar um pouco mais lento e ganhar produtividade, por exemplo. Claro, dependendo do quão mais lento.

Sem falar que o Ruby aguentou um volume muito grande, até que a equipe do twitter precisou migrar. Creio que os “meros mortais” vão passar longe desse limite.

Pra 99% das empresas isso é fato, nem tudo é performance. Pra o 1% que o twitter faz parte a diminuição de custos que isso pode gerar deve bater nos milhões de dólares

O maior problema que temos hoje é que a maior parte das pessoas que está nos 99% acha que está, na verdade, nos 1%.

Pra 99% das empresas isso é fato, nem tudo é performance. Pra o 1% que o twitter faz parte a diminuição de custos que isso pode gerar deve bater nos milhões de dólares

O maior problema que temos hoje é que a maior parte das pessoas que está nos 99% acha que está, na verdade, nos 1%.

Mas eu acho que ha duas fases no que diz respeito a produtividade, uma coisa é quando se esta no inicio do projeto, ou sequer temos o produto pronto ainda, ou até mesmo temo o produto pronto, mas devido ao grande sucesso temos que fazer mudanças muito rapidas;
Outra coisa é quanto ja temos um sistema maduro, e temos apenas que ir melhorando, neste caso não ha aquela pressao enorme no quesito produtividade, e é nesta situação que eu acho que se encontra o twitter atualmente.

se fizeram isso, estão jogando fora o que eles tem mais de valor as pessoas, não é a linguagem que defini se o twitter é uma boa ferramenta. E se foram os estagiarios que fizeram isso, puts, os programadores deveriam aprender com eles então, pois eu sentir no comentario um certo tipo preconceito com estagiarios.

Mauricio Linhares:

Pra 99% das empresas isso é fato, nem tudo é performance. Pra o 1% que o twitter faz parte a diminuição de custos que isso pode gerar deve bater nos milhões de dólares

O maior problema que temos hoje é que a maior parte das pessoas que está nos 99% acha que está, na verdade, nos 1%.

[]s

fredferrao:

Mas eu acho que ha duas fases no que diz respeito a produtividade, uma coisa é quando se esta no inicio do projeto, ou sequer temos o produto pronto ainda, ou até mesmo temo o produto pronto, mas devido ao grande sucesso temos que fazer mudanças muito rapidas;
Outra coisa é quanto ja temos um sistema maduro, e temos apenas que ir melhorando, neste caso não ha aquela pressao enorme no quesito produtividade, e é nesta situação que eu acho que se encontra o twitter atualmente.

O Twitter tinha vários problemas pra se resolver:

• Base de código em Ruby difícil de se extender
• Alta latência
• Modelo single threaded do Rails
• VM lenta e pouco confiável pra quantidade de acessos que eles tinham (o Twitter foi um dos primeiros grandes clientes do pessoal do Passenger e do Ruby Enterprise Edition)

Na hora de resolver isso, eles não tinham como resolver os problemas do Rails ou do interpretador do Ruby e eles já tinham muito código rodando na JVM com Scala e Java, por que não ir pro lado do Java que seria capaz de fazer o mesmo trabalho? O sistema teria que ser reescrito de qualquer forma, seja em Ruby ou em Java, mas se eles escrevessem o sistema em Ruby continuariam com as desvantagens de estarem executando no MRI, Nada mais correto do que ir além e pular direto pro Java que já ia dar vários avanços de graça.

Quanto a manutenção, acho que entre Java e Ruby não haja uma distância tão grande. Tenho codebases em Ruby e em Java que trabalho diariamente e o maior problema não é a linguagem, mas sim quem escreve o código. É possível escrever código ruim e difícil de manter em qualquer linguagem, a única vantagem do Java nesse caso é que refactorings são mais fáceis.

Me identifico bastante com esta discussão.

Atualmente estou trabalhando em um projeto de enorme concorrência e consumo de dados para um jogo, dos grandes.

Quanto entrei na empresa, o ex “líder técnico” havia feito uma implementação em Ruby (não finalizada) com Mongo DB, com argumentos mais pelo hype e pelo gosto pessoal do que coerência técnica.

A maturidade da JVM é algo inquestionável frente a outras VMs, inclusive a do Ruby, seja ela qual for. Indo além, a maturidade de APIs para o Membase (leia-se, basicamente Memcached persistido) também não era bacana, entre outras soluções já maduras, há anos, para o Java.

Minha proposta foi parar de brigar com a solução, que na verdade era nosso maior problema, e jogar fora tudo feito em Ruby e usar Java puro.

Refiro-me, acrescentando a discussão, que o Java tem soluções (libs, etc) bem mais maduras e estáveis que as providas pelo Ruby, em muitos casos.

Eu adoro programar em Ruby, porém é necessário colocar de lado predileções e decidir com responsabilidade o que você vai sugerir como solução para os projetos que você venha a participar.

Por fim, digo que rendeu muita conversa até resolverem jogar no lixo o que estava pronto, ato este que, por definição, não soa bem para nenhum gerente ou padrinho de projeto, no nosso caso. Hoje estamos muito bem, mais rápidos e tranquilos usando Java puro.