100% Rails ou JRuby?

boa pergunta, embora eu ñ me interesse por ruby

Tambem gostaria de saber a opiniao do Fabio.

Estou MUITO interessado em projetos Ruby, mas nao existem muitas vagas no Brasil (pelo que andei vendo).

Obrigado

Olá

Vou dar meu pitaco antes do Fábio para não me influenciar pela opinião dele.

Como já disse em outros tópicos, para mim, Ruby é uma linguagem com comandos concisos e poderosos, que permite fazer muitas coisas em menos tempo e escrevendo menos código. Os frameworks Ror ou Merb permitem desenvolver aplicações web com muita agilidade.

Mas há alguns fatores determinantes que poderiam determinar a exclusão de Ruby do leque de escolhas. Um exemplo seria a necessidade de consultas complexas à base de dados em que o modelo simples do Active Record não atenda. Outro exemplo seria a necessidade de usar facilidades disponíveis em Java de um modo que mesmo com JRuby fique muito complicado.

Ainda acho que a resposta deste tipo de pergunta depende muito do grau de conhecimento da equipe e do domínio das tecnologias envolvidas.

Em resumo: não vejo como responder a este tipo de pergunta sem saber todas as informações do projeto. Pode até ser que a melhor escolha não seja Java ou Ruby. Aliás este tipo de escolha foi tema da palestra de ontem do Guilherme e eu concordo 100% com o que ele disse.

[]s
Luca

e prefiro ter um pé em j2ee e o outro em .NET, daqui a pouco ruby fica como php. Eu prefiro apostar minhas fichas no groovy e grails e nas idéias
do seaside

Concordo

LuksS:

e prefiro ter um pé em j2ee e o outro em .NET, daqui a pouco ruby fica como php. Eu prefiro apostar minhas fichas no groovy e grails e nas idéias
do seaside

Ponha suas idéias a discussão, isso iria agregar muito mais ao fórum do que pitacos sem relevância.

Olá

Concordo

Será? Acho que o PHP propiciou fazer o YouTube em pouco tempo. Se ao invés de gente boa em PHP, lá estivessem javeiros de qualidade o site ficaria igualmente bom mas o tempo de desenvolvimento poderia ser um pouco maior.

Na verdade muita gente se prende na discussão sobre qual a melhor linguagem para desenvolver um site e às vezes se esquece de estudar a infra-estrutura. Os caras do YouTube, além de bons em PHP, eram feras nas questões de infra-estrutura. Isto ficou claro para mim em uma entrevista que li de um dos caras da área técnica do you tube.

[]s
Luca

Oi Luca, acho esses bem interessantes esses pontos e isso também me passou pela cabeça, principalmente a parte da grande quantidade de blibliotecas java disponíveis para tudo que é tipo de coisa, por isso a dúvida em analisar as opções de uso ou não do JRuby mesmo se tendo a opção de usar um ambiente “ruby puro”.

Não ache que seja tão complexo/genérico assim minha pergunta, qualquer portal hoje tem esse tipo de necessidade, milhares de acessos concorrentes, gostaria de ater apenas à questão de arquitetura mesmo para a aplicação, claro que é relevante fatores como equipe, tempo de desenvolvimento, mas apenas conceitualmente acho que não precisamos nos “prender” a esses pontos, vamos supor que o intuíto é ditático apenas.
Senão vai aparecer um monte de subdiscuções paralelas que acho que não vão ajudar tanto.

Valeu pelo seu ponto de vista.

ok, concordo contigo

Antes de tudo eu não trabalho diretamente com php(Deus me livre) e nem ruby
, só com j2ee e .net.

Com Ruby tive minhas experiências pessoais e tirei minhas conclusões pessoais, veja bem pessoais:

• O rails foi e é o tchan tchan tchan tchan do ruby. Sem dúvida alguma ele contribui de forma gigantesca
  p/ ampliar as idéias tão dinâmicas que ele traz consigo p/ a comunidade de desenvolvedores
• A comunidade rails tá meio estática … cadê aquele alvoroço quando do lançamento do framework,
  sim é dinâmico, tudo integrado, uniforme … cadê mais ??
  -Eu ñ consegui obter o alto grau de independência entre os componentes de uma aplicação, com tecnologia
  j2me vc tem um punhado de opções. Tdb que no java tem que se aprender 1000 e 1 frameworks p/ fazer uma única
  coisa e então a curva de aprendizado é maior, mais o grau de liberdade oferecido tb é maior
• Gostei de groovy e ainda mais do grails, redescubri a dinâmica de código depois de ter decepciondo-me com python

Não quero gerar confusão, prefiro parar de postar sobre isso p/ ñ gerar intrigas, só respondi o que foi perguntado.

Concordo

Essa história de q Ruby é lento, ruby não vira, era a msm história de Java há alguns anos atrás…

Acho que se hj eu tivesse q fazer uma aplicação de pequeno e médio porte eu arriscaria JRuby, não por apenas aprender, mas porque tem muitos conceitos úteis, mtas coisas que me dão vantagens e isso agilizaria meu tempo.

Luiz Aguiar:

A pergunta seria endereçada direto pro Fabio Kung, após algumas duvidas que surgiram com a palestra dele no FJ2008, achei mais produtivo compartilhar a dúvida aqui pois outros também vão poder expor seus pontos de vista.

Fabio (e demais) , hoje se tu fosses criar uma aplicação, com uma média de 1.000 acessos concorrentes, vamos usar esse valor para arredondar apenas, e tu tens a opção de moldar toda a arquitetura/infra para disponibilizar essa aplicação.
Levando-se em conta os pontos que citou em sua palestra, tanto os fatores de multi-thread, caches, libs javas disponíveis para uso em ambiente jruby, compartilhamento ou não de dados, essas coisas, tu farias essa aplicação num ambiente 100% ruby ou colocaria um container java para rodar essa aplicação em JRuby?

Queria só que comentasse um pouco (apesar de já ter falado e muito bem na palestra) o por quê de sua escolha e principais disvantagens que vê nos dois ambientes.

A pergunta é meio longa, um pouco genérica, mas espero que tenha ficado claro a dúvida.

Valeu!

Mil acessos concorrentes? Essa volumetria está muito, mas muito errada; ou você está trabalhando em um site de gigantesco volume. Para ter mil acessos concorrentes, um site com tempo de resposta médio de meio segundo (que é lento) estaríamos falando de 2000 requisições por segundo. Isso dá 6.4 milhões de requisições por hora. Um volume desses é compatível com a página de entrada de portais como globo, uol e terra. Você tem certeza?

A grande vantagem em usar JRuby é que o deployment é muito mais simples. Achar mão de obra capaz de lidar com o deployment e operação de java no Brasil é muito mais fácil que para mongrel, mod_rails ou sei lá oque.

Em termos de performance não vai faz muita diferença, ainda mais se for para escalar para esse volume que você sugeriu.

Eu também vi a apresentação do Fabio Kung, e gostaria de dar um pitaco, um tanto quanto polêmico:

1- Não escolha se o Rails vai sobre JRuby ou MRI levando-se unicamente em consideração a performance de cada um. Existe uma “corrida armamentista” entre as várias implementações de Ruby para ver quem é o mais rápido. Portanto, independente de sua escolha, saiba que ela ficará mais rápido com o tempo, basta se preparar (testes automatizados, por exemplo) para fazer atualizações.

2- Não caia no conto do vigário dos “JayRubistas” de que com JRuby “além das bibliotecas do Ruby, você ganha as bibliotecas do Java”, isso é parcialmente verdade. Apesar do Rails puro ser 100% Ruby, algumas bibliotecas extras são implementações nativas em C, que NÃO funcionam em Java e que NEM SEMPRE existem alternativas satisfatórias. Não estou querendo dizer pra nunca se usar JRuby, às vezes se está utilizando Java justamente para aproveitar uma biblioteca ou framework que existe nessa linguagem. Mas é bom pensar um pouco nas suas necessidades, antes de cair de cabeça no JRuby.

3- Se você quer inovação, fique com o MRI (ou YARV, a partir do Ruby 1.9). Esta é a implementação de referência para todas as implementações Ruby existentes, e é onde surgem as novidades. A mesma coisa ocorre com os plugins, onde primeiramente é pensado para o mundo C/Linux, depois para o mundo Java.

Uma outra coisa, ouvi falar do surgimento do mod_rails e em como ele consome menos memória e é mais fácil de se usar. Existe algum benchmark mod_rails com JRuby?

Não entendi por que Rails ou JRuby. Framework vs implementação de linguagem não faz muito sentido, a menos que consideremos também as APIs e frameworks Java.

Alguém aí por favor me corrija se eu estiver errado…

Alguém lembra do Prevayler?

Pois bem, era uma coisa muito UOW, muito NOSSA, portais sendo feitos com ele, o mundo seria à partir daquele dia PRÉ PREVAYLER e PÓS PREVAYLER, tutoriais, discussões…até que… nunca mais ouvi falar dele… ninguém mais tem dúvida… ué… (se alguém tiver algo a falar sobre tal por favor)

No começo, Ruby pra mim ia ter o mesmo destino(apesar de coisas bem distintas), ia ser muito UOW, muito NOSSA, e depois, puff… mas eu vejo com outros olhos agora, não dá pra dizer que é inútil e que ninguém vai usar e que não presta e bla bla bla, ele tá começando agora, estão dando seus primeiros passos, e pessoas como o Kung fazendo o que está fazendo(apostando nele) mostra que não é assim também tão meia boca né?

Eu não escolheria Ruby agora, baseado no que ouvi na palestra: aquela história de Cache, de “Gambiarra likes” para multi-thread… pra que EU, Raul, perderia tempo nessas reviravoltas que com certeza não me agilizariam em nada? Só pra eu aprender a fazer tudo o que é necessário já se foi a agilidade…

Não estou com tempo infelizmente de investir nisso, até gostaria, mas não dá, e felizmente existem pessoas que com o tempo vão melhorar isso, e daqui um tempo QUEM SABE tudo isto será passado e teremos facilidades e “tudo na mão” como o Java?

Eu não aposto mas, espero que dê certo, espero mesmo… mudar sempre é bom…

Cara cê desenterrou o Prevayler das profundesas, nossa!

RaulCarlin:

Alguém aí por favor me corrija se eu estiver errado…

Alguém lembra do Prevayler?

Pois bem, era uma coisa muito UOW, muito NOSSA, portais sendo feitos com ele, o mundo seria à partir daquele dia PRÉ PREVAYLER e PÓS PREVAYLER, tutoriais, discussões…até que… nunca mais ouvi falar dele… ninguém mais tem dúvida… ué… (se alguém tiver algo a falar sobre tal por favor)

O Prevayler é mto bom, era um projeto de futuro até, mas o criador vira e fala q é pra jogar fora o Banco de dados pra usar tal ferramenta, coisas radicais assim nao viram, pq só agora um monte de empresa ta migrando os sistemas pra Java 1.5 sendo que já tem o 1.6, pq ninguem é radical, pq se der problema ninguem quer se responsabilizar…

É exatamente por isso que não aposto no Ruby AGORA, mas espero que dê certo e que todos que estão apostando nele AGORA tenham sucesso…

É a mesma história do JavaScript, quem diria, que depois de tantos anos, bibliotecas tão poderosas como jQuery e ExtJS pudessem ressucitar algo tão pré-histórico e com tão pouca ambição? Esse é o tchan daquilo que foi falado na primeira palestra, não ter receio de misturar tecnologias, temos tudo pra resolver tudo de n maneiras… basta não ser preconceituoso…

Depois que eu disse pra mim mesmo há anos atrás que seria MCAD de qualquer jeito e logo depois tava cagando e andando pro C# por achar que Java era A minha, nunca mais cuspo pro alto…

Sempre que vejo a galera falar de frameworks Web,MVC me vêm à cabeça arquitetura desacoplada, orientada à Serviços. Poucos designers projetam sua aplicação para utilizar tal conceito, como em Rails - REST e hoje olhando o cenário das aplicações que são criadas nas empresas, essas questões como Modelo Canônico de dados, são muito superiores à qual linguagem implementar.

Não vejo ninguém falando de ESB Patterns de Integração … só um desabafo…

Prevayler realmente seria uma boa se tivesse REALMENTE sido concluído de fato, até onde me lembro, não sei se questões como segurança e transações tinham sido implementadas, e se não, então não haveria a mínima possibilidade de utilizar num sistema de grande porte, que exige coisas além do supracitado.
E aproveitando o tema, alguém sabe dos rumos do Prevayler?

LuksS:

Prevayler realmente seria uma boa se tivesse REALMENTE sido concluído de fato, até onde me lembro, não sei se questões como segurança e transações tinham sido implementadas, e se não, então não haveria a mínima possibilidade de utilizar num sistema de grande porte, que exige coisas além do supracitado.
E aproveitando o tema, alguém sabe dos rumos do Prevayler?

Desculpem a crítica, não é pessoal, mas não estamos fugindo da proposta da thread? Daqui a pouco o Luiz terá que refazer a pergunta…

EDIT> já tiveram o trabalho de falar a mesma coisa.

LuksS:

Prevayler realmente seria uma boa se tivesse REALMENTE sido concluído de fato, até onde me lembro, não sei se questões como segurança e transações tinham sido implementadas, e se não, então não haveria a mínima possibilidade de utilizar num sistema de grande porte, que exige coisas além do supracitado.
E aproveitando o tema, alguém sabe dos rumos do Prevayler?

Nao morreu por ter terminado e sim pq o criador falava q BD nao prestava q deveriam ser excluidos, pessoas mto revolucionarias nao dao mto certo dentro de grandes corporações, o criador do Prevayler hj ta num projeto de BD OO

Agora vamos voltar ao: 100% Rails ou JRuby?

ok

Kenobi:

Sempre que vejo a galera falar de frameworks Web,MVC me vêm à cabeça arquitetura desacoplada, orientada à Serviços. Poucos designers projetam sua aplicação para utilizar tal conceito, como em Rails - REST e hoje olhando o cenário das aplicações que são criadas nas empresas, essas questões como Modelo Canônico de dados, são muito superiores à qual linguagem implementar.

Não vejo ninguém falando de ESB Patterns de Integração … só um desabafo…

Voltando ao Tópico, não a questão de Deploy é bastante preocupante. Existem uma série de recursos quando usamos um bom application server, desde configuração de regras de SLA, à segurança, pools, configurações de Threads e por aí vai.

JRuby é uma boa opção para desenvolvimento ágil. Do contrário, será necessária uma grande expertise em configurações de infra.

Ótima idéia de deixar a pergunta pública Luiz.
Gerou diversas discussões muito interessantes e levantou alguns pontos muito legais!

Acessos concorrentes é uma expressão muito perigosa Luiz. O que significa acesso concorrente? Em um segundo (req/s)? Em um minuto (req/min)? Em um dia (pageviews)?

Só para termos uma base, consideremos uma das aplicações Rails mais populares (e acessadas). O Twitter recebe cerca de 300 req/s, e isso já é monstruoso na internet. Pouquíssimos de nós vamos precisar lidar com aplicações deste porte.

No twitter, estão usando 120 processos de mongrel divididos em algumas máquinas para aguentar tudo isso. Cada processo mongrel toma de 20-60Mb e quando começa a crescer demais o uso de memória, os processos são reiniciados (já que o gerenciamento de memória da MRI não é lá essas coisas). Na internet tem bastante material de como o twitter vem sendo escalado.

Se eu tivesse a escolha, a quantidade de acessos não iria ser fator determinante para escolher entre MRI ou JRuby. Você conseguiria esse resultado com qualquer um dos dois, com vantagens e desvantagens para cada um dos lados.

Poder usar gems nativos e estar sempre usando todas as coisas mais novas é uma grande vantagem ao se optar pelo caminho MRI, como bem disse o Leonardo3001. Apesar que, pelo menos na minha experiência, não é tão comum você não achar alternativas puro-ruby ou feitas em Java.

Nesse seu caso Luiz, o fator que faria eu escolher entre um e outro seria precisar usar algum gem nativo ou jar. Eu tentaria durante o desenvolvimento não fixar nenhuma escolha, fazer com que a aplicação pudesse rodar tanto no MRI quanto no JRuby. Ao mesmo tempo que gerenciamento de memória fraco (que obriga o uso de watchdogs como o Monit e o God) junto com a falta de um JIT, são desvantagens fortes.

Vantagens fortes do JRuby você mesmo citou. Threads nativas, compartilhamento de coisas entre os runtimes (jndi, pool de conexões, caches, …), garbage collector, jit e principalmente a possibilidade de usar código java existente são vantagens. Tempo de startup, falta de suporte a gems nativos e ciclo de desenvolvimento complicado são desvantagens (os stack traces do jruby são ainda menos informativos que os da MRI tb).

Eu postergaria a decisão o máximo possível. Ótimo se se o deploy puder ser feito em qualquer um dos dois, aí você vai poder fazer mais testes da aplicação real e ter mais base para decidir. Pode até fazer como muitas pessoas estão fazendo: desenvolve com MRI e faz deploy no JRuby, já que os stacktraces da MRI são mais informativos e o tempo de startup é menor. Só fixaria em um dos caminhos se alguma hora não tivesse mais saída e eu precisasse mesmo usar um gem nativo ou código java.

Desculpa, mas como sempre não há uma única resposta para a sua pergunta. Como muitos já disseram, vai depender muito também da experiência da equipe ou da infra que você vai ter. Ainda bem que a resposta para ótimas perguntas como essa é sempre o “decepcionante” depende. Se não fosse assim, nós não seríamos mais necessários!

Excelente Fábio!

Bom, vamos deixar esse 1.000 de lado porque me expressei mal mesmo e acabou complicando rs

Minha visão era exatamente na necessidade de muitos processos e consumo alto de memória, acho que vc validou pontos chaves bacanas realmente, como já havia feito na palestra.
O que pensei tambem bate com seu comentário, não da pra prever o que será necessário no desenvolvimento e se não terá “componentes” nativos e terá que recorrer a jars e coisas do “mundo java”.

Quanto ao desenvolvimento, realmente o fato de perder o lado ágil do Rails parece um pouco estranho quando falamos em colocar a aplicação pra rodar com JRuby, essa opção de desenvolver com MRI e depois deployar no JRuby parece uma boa alternativa.

Valeu pela resposta Kung!

Falando nisso, eu estou exatamente com um caso desses

A aplicação é feita basicamente no MRI mas nós rodamos os specs nos dois, mas a implantação é “híbrida”, estamos testando tanto no MRI quanto em JRuby (usando Jetty, com um plugin que eu montei, vai ser publicado daqui a algum tempo), o Jetty tem sido mais confiável que a dobradinha Apache + mongrels e absurdamente mais fácil de configurar, aqui é só rake jetty:start e o troço tá rodando com 4 instâncias no ar sem nenhuma dor de cabeça pra controlar os processos separados. O maior problema do JRuby é o tempo de inicialização das coisas, rodar um spec em JRuby é lento que dói, levantar o servidor demora um bocadinho, então rodar no MRI é mais interessante nesses casos mais pontuais.

E um detalhe MUITO importante que todo mundo esquece, o MRI no Windows é risível, então se você vai fazer deployment de Rails no Windows, não tem nem o que considerar, é JRuby na cabeça

Mesmo se você decidir por usar JRuby no desenvolvimento, não esqueça que agora existe o http://jetty-rails.rubyforge.org, e não perdemos o feedback instantâneo! (= agilidade do rails)

Maurício, seu rake jetty:run parece muito o jetty-rails! Que tal você contribuir lá hein?. Manda MP/email!

Código fonte: http://github.com/fabiokung/jetty-rails/tree/master

Mesmo se você decidir por usar JRuby no desenvolvimento, não esqueça que agora existe o http://jetty-rails.rubyforge.org, e não perdemos o feedback instantâneo! (= agilidade do rails)

Maurício, seu rake jetty:run parece muito o jetty-rails! Que tal você contribuir lá hein?. Manda MP/email!

Código fonte: http://github.com/fabiokung/jetty-rails/tree/master

:lol:

Quando eu vi o jetty-rails já era tarde demais

Mas a minha idéia é ir no caminho do servidor de produção mesmo, não o de desenvolvimento, tanto que eu uso o script de inicialização do Jetty pra subir o servidor (e um arquivo jetty.xml pra configurar tudo), o plugin na verdade são só uns tasks do Rake que sobem o servidor que vem empacotado no plugin, mas eu vou mexer no Jetty-Rails sim e contribuir com o que eu puder, o negócio é só achar um jeito simples de fazer start-stop-restart no servidor pra poder integrar ele melhor com o Capistrano, foi até por isso que eu resolvi usar o script de inicialização do próprio jetty, já que eles já tinham isso pronto.

certo! entendi! Complementa então…

Mas era uma boa funcionalidade a ser incluida no Warbler ou no próprio jetty-rails. Já andou falando com o Nick Sieger?

Vamos lá, primeiro parabéns ao Kung pela palestra. Tentei lhe achar após a mesma para bater um papo mas parece que todos tiveram a mesma idéia.

Segundo, em outubro do ano passado comecei a fuçar no Ruby on Rails para um projeto interno, rápido e sem frescura. Em uma semana tinha um site no ar com CRUD funcionando, mas estava meio perdido no Ruby e algumas coisas era muito out of path do universo Java.

Foi quando ouvi falar do Grails (Groovy on Rails), e posso dizer que minha vida tomou um outro caminho

O Grails é um rails em Java, que utiliza todo o código escrito pelo pessoal do projeto + Hibernate + Spring + Sitemesh. E o Groovy é muito mais “friendly” do que o Ruby, na minha modesta opinião.

Pra quem for entrar de cabeça nesse mundo recomendo dar uma olhada por aí. Grails é bem legal e é minha escolha.

grails é sim uma ótima opção!

Mas pessoalmente (como me disse o louds uma vez), prefiro mirar na zona de desconforto. Aprender uma linguagem totalmente diferente do que você está acostumado (out-of-path?) te faz abrir mais a cabeça e enfrentar novos paradigmas.

Faz você enxergar as coisas de um ponto de vista totalmente diferente, conhecer novas possibilidades e até te torna um melhor programador na plataforma antiga!

Fábio,

Em primeiro lugar, parabéns pela palestra, foi de um nível muito bom e esclarecedora. Gostei da parte que você “assumiu” os problemas do Ruby.

Agora fiquei com uma dúvida em relação ao GUJ3 ser 7 vezes mais rápido que a versão atual. Você disse que no GUJ3 você esta usando cache. Na implementação em Java com a qual o GUJ3 foi comparada tinha cache?

Na home não tem. Quem faz cache é o JForum, mas no guj3 o JForum continuará o mesmo, no mesmo lugar.

É o que o Lezinho já tinha dito. Ficou mais rápido não por que é Rails ou algum framework Java puro (no fundo o guj3 é Java tb, já que vira tudo bytecode), mas sim por causa do cache. Volta àquela mensagem de que mais importante do que a tecnologia que você usa, é saber aproveitá-la bem, conhecê-la bem.

Fabio Kung:

Mas pessoalmente (como me disse o louds uma vez), prefiro mirar na zona de desconforto. Aprender uma linguagem totalmente diferente do que você está acostumado (out-of-path?) te faz abrir mais a cabeça e enfrentar novos paradigmas.

Faz você enxergar as coisas de um ponto de vista totalmente diferente, conhecer novas possibilidades e até te torna um melhor programador na plataforma antiga!

Sim, concordo contigo. O fantástico do Groovy é isso: uma linguagem nova que potencializa o Java, traz novos conceitos e novas opções (como o conceito de clousures) e, o melhor de tudo, por detrás é Java…

Não é esse o grande lance do JRuby, uma nova linguagem, conceitualmente diferente, mas que trás todo o background do Java?

Exato! Essa é sim uma das grandes vantagens.

Eu só fiquei receoso de começar mais um flame groovy vs jruby, que na minha opinião, não leva a nada.

Fabio Kung:

Eu só fiquei receoso de começar mais um flame groovy vs jruby, que na minha opinião, não leva a nada.

Hahahahaha, Flame War é legal. Não leva a nada, mas é legal.

Voltando ao tema, concordamos, isso é bom.

Ola Fabio ,
vc recomendaria algum livro em especial para iniciantes Ruby?

Oi ramilani,

Te recomendaria o Pickaxe:
http://www.pragprog.com/titles/ruby/programming-ruby