O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…

Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?

Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:

Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.

Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).

Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.

Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.

Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.

Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!

Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.

Outro fator primordial que vejo é “comunidade”.

A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.

E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)

E o fim deste pensamento, qual é?

Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!

Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.

Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.

(Valeu Diego, por me fazer pensar um pouco sobre isto.)

Até a próxima!

Hoje de manhã postei algo rápido sobre Grails. Agora, vontando do almoço, acabei de ver um post do Brian Guan, um dos engenheiros do LinkedIn, sobre a sua experiência com Grails no LinkedIn.

Até a próxima!

O que Grails, afinal?

Grails é a resposta da Plataforma Java ao desenvolvimento web ágil, dinâmico, sem toda aquela parafernália de 7.203 arquivos XML para configurar, 3.412 classes dos frameworks jAbc, J-XPTO e JSeila Oq+ para estender, e mais uns 1.300 arquivos JAR para “bibliotecar”.

Esta maravilha do mundo Java segue a filosofia de frameworks web full stack, tais como Ruby on Rails e Django. E segue fundamentalmente o conceito de Convention over Configuration, que pode ser resumido em uma simples frase: “É ótimo poder configurar, mas é péssimo ser obrigado a fazer isto”. Sendo assim, tudo tem um padrão de nome a seguir e um local bem definido para estar.

O que está por trás?

Grails não foi construido a partir do nada. Muito pelo contrário. Ele está fundamentado sobre frameworks de mercado mais que consagrados:

- Hibernate, sobre o qual esta o GORM (Grails ORM);
- Log4J, controle de log;
- Spring, injeção de dependência e MVC;
- Jetty, web container embutido;
- SiteMesh, templates de página web.

E tudo isto sendo “colado” e “manipudalo” pela linguagem Groovy, que para quem viveu os últimos anos em Marte, é uma linguagem orientada a objetos, fortemente tipada e dinâmica, desenvolvida para a Plataforma Java, como alternativa à própria linguagem Java.

Vale a pena usar Grails?

Para o seus projetos, só você mesmo pode responder. Mas o fato é que já existe muita coisa por ai rodando em cima de Grails. Um exemplo? O site da PepsiCo, por exemplo, que é um caso relatado no site do Grails.

Minha opinião? Se você quer uma alternativa dinâmica ao desenvolvimento web rápido para a Plataforma Java, dê uma olhada em Grails. Você não vai se arrepender.

Agora, se para você, desenvolvimento “confiável” e “bem feito” é sinônimo de centenas de milhares de XMLs, JARs, frameworks, e linguagem estaticamente tipada (porque o compilador te faz errar menos), esqueça Grails. (Mas… Uma dica: Sai dessa, meu chapa!!! rsrsrs)

Valeu!