Oi Kico,
Acho que você se confundiu quando falou "Grails tem uma coisa que o Ruby".Grails é um framework, ruby é uma linguagm.

HSQLDB embutido é uma grande vantagem?

Maurício Linhares wrote:O maior problema de Groovy é que ela é próxima demais do Java, então muita coisa não tem como ser feita em Groovy, como mixins, definir novos métodos em tempo de execução (na verdade, até pode se você fizer umas gambis no despacho de métodos, mas é bem mas complicado do que seria em Ruby com um class_eval, module_eval ou ainda um define_method).

Não vi callbacks pra quando uma classe extende a outra (e isso é muito importante pra metaprogramação e seria ainda mais se Groovy tivesse suporte a módulos). Groovy também não tem open classes/modules, deixando você alterar o comportamento de classes já definidas no ambiente (como colocar novos métodos em String). Open classes são uma mão na roda quando voc está mexendo com código alheio que está versionado e você não pode fazer "patches" diretos.

Enfim, o grande problema de Groovy hoje ainda é o suporte fraquinho a metaprogramação e é isso que faz de Ruby uma linguagem bem mais flexível.

Maurício Linhares wrote:Veja que eu disse:

(na verdade, até pode se você fizer umas gambis no despacho de métodos)

Mas é muito mais complicado do que simplesmente fazer um define_method (ou module_eval e class_eval) em Ruby, você tem sempre que fazer override de "invokeMethod()" (a não ser que tenha mudado desde a última vez que eu mexi com isso em Groovy), o que termina sendo quase igual a ter sempre que fazer override de method_missig em Ruby, o que não é interessante, principalmente porque não tem um alias_method em Groovy.

Maurício Linhares wrote:Ah, então melhorou demais mesmo

Onde é que eu acho mais informações sobre isso?

Maurício Linhares wrote:O meu "Groovy In Action" não fala nada dessas mágicas.

Paulo Silveira wrote:muito boa mesmo! Obrigado Marcos pelas novidades e esclarecimentos.

kicolobo wrote:Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008

David wrote:

kicolobo wrote:Grails tem uma coisa que o Ruby não tem: ele roda em uma JVM.

Não sei como anda o Rails para o JRuby, esta seria uma vantagem, porém convém lembrar que é importante sabermos aonde nossa aplicação está sendo executada, e a plataforma Java, convenhamos, é fantástica!

O simples fato de você poder reaproveitar TODO o seu código legado em uma aplicação feita em Grails já o coloca, na minha opinião, anos luz à frente do Ruby on Rails. O que me prendia um pouco com relação ao RoR era exatamente o fato de que seria mais difícil aproveitar trabalhos passados que eu havia desenvolvido em Java.

Andei dando uma fuçada no Grails e fiquei realmente impressionado com o que vi. Em um aspecto, inclusive, o GRails passa o RoR: você não precisa configurar nada, tal como ocorre no RoR. Isto porque o GRails já vem com o HSQLDB embutido. Claro, esta não é lá uma grande vantagem, mas é um passo à frente.

Com certeza o GRails está na lista de minhas apostas para 2008

O Rails para o JRuby é o mesmo Rails pra Ruby. Eu tenho um sistema que fiz usando Ruby on Rails em Mongrel e está em produção atualmente no Tomcat.