Vixe que o sistema do forum "comeu" a lista e agora não tenho mais paciência para escrevê-la novamente rssrsrs

Levando como base o constante desenvolvimento do framework pela OCI (e seu crescimento mesmo fora), não creio que possa ser considerado legado Yoshiriro.

No entanto, talvez o modelo de desenvolvimento que adotamos com ele, full, do negócio à visualização, esteja se mostrando inadequado hoje.

Kico, você acha q o modelo de desenvolvimento de apps 'Monolíticas' já morreu?  

Se algo é inadequado hoje, não se cira mais algo novo com isso. logo, é legado, IMO.

*cria

Mas ai o Kico falou em relação , no meu intendimento, a um estilo de desenvolvimento de uma aplicação monolítica.  O Lance, como o Kico também mencionou, é que você consegue desenvolver, e bem, orientado a micro serviços com Grails. Existem os profiles REST, e os integrados com Angular e etc. 

Mas tido que se faz com Grais se faz com Spring Boot com quase a mesma produtividade, mas requisitos de memória e CPU muito menores. E com uma IDE oficial gratuita que não foi descontinuada. E com BEM menos bugs.
Penso que virou legado porque se procurar vagas de emprego com "grails" em qualquer site quase não acha. Já "spring boot" há muita vaga. Sinal que quase ninguém está iniciando projetos novos em Grails.
Eu amava esse framework, mas a lentidão na inicialização/testes os pesados requisitos de memória, IO e CPU e o excesso de bugs minaram a popularização dele, infelizmente.

Oi Yoshiriro,
no que diz respeito a desempenho, eu experimento aqui o mesmo desempenho de Grails com Spring Boot, sendo assim, é algo que depende do projeto.

Sobre o desenvolvimento: Grails tem um nicho muito interessante e que não o tornará "legado" tão cedo. Quando você precisa de renderização do lado servidor e minimizar o custo de desenvolvimento. Neste ponto, Grails ainda é imbatível.
No que diz respeito ao desenvolvimento de micro-serviços, ele me dá tudo o que o Boot me dá (afinal de contas, é uma aplicação Spring Boot no final das contas), só que com maior produtividade (mesmo desempenho, mesmo acesso aos benefícios do Boot).

O argumento da vaga também é muito furado. Por que se for assim, você só vai ter dois frameworks web pra Java: JSF e Spring. Vai ignorar uma pletora de outras soluções que sim, também são muito usadas, como Tapestry, Play, VRaptor (sim, é bastante usado) ou outras soluções igualmente interessantes, como o Ratpack. O que ocorre é o seguinte: o pessoal coloca na descrição das vagas as tecnologias que são mias conhecidas, mas internamente podem usar qualquer outro framework, que é o que normalmente acontece.

Também não creio que poderia ser considerado "legado" (nossa, este termo foi muito infeliz neste tópico, talvez um termo mais apropriado fosse relevante) por que é um framework que ainda está em constante desenvolvimento, basta ver que todo ano tem Gr8 Conf e mensalmente saem pelo menos dois releases.

Outro ponto fundamental: sem o contexto, não há como dizer qualquer coisa. Quando você diz "Se algo é inadequado hoje, não se cira mais algo novo com isso. logo, é legado, IMO." - a questão é: hoje onde? Aí que tá o ponto.

Henrique, 

amigo, de coração, respeito você demais, mas discordo de tudo que você falou e ainda acho que Grails (assim como Tapestry, Play, VRaptor, Struts e afins) é legado. Se há muita gente usando isso é outro assunto. Usei o termo "legado" para me referir a projetos existentes e não novos. E discordo totalmente que a performance é a mesma de uma app feita em Spring (falo da performance em dev, no ciclo "salva -> levanta app" ou "salva -> teste de integração"). 

Inclusive descobri que uma enorme empresa grande aqui no Brasil que todo mundo conhece que usava Grails está abandonando ele. Foi um case celebrado na época. Conheço um gerente de lá e ele mesmo me contou.

Enfim: já forneci dados outra fez, no tópico sobre o Grails não ter emplacado. Você contestou a relevância deles, como fez agora aqui. Pra mim eles refletem, sim, o que  mercado está adotando em projetos novos. Eu leio esses números mais com a razão, você, parece-me, mais com o coração. 
E, mais um dado, esse sim menos "científico": Leciono em faculdades relevantes de tecnologia aqui em São Paulo (FIAP e Bandtec), tendo contato com muitos professores atuantes no mercado e alunos que já trabalham na área. Trabalhei em 2 consultorias (uma delas com clientes até na Europa). Estou na 5ª empresa diferente aqui em São Paulo. O que tinha em comum em todos esses lugares? Ou ninguém tinha ouvido falar do Grails ou só tinham ouvido falar mas nada que realmente empolgasse. As pessoas pareciam mais conhecer como um framework "bugado e lento pra iniciar em dev", por incrivel que pareca :(
Entendo que você ame o Grails. Acredite, também amo. Mas os números são muito fortes: Raríssimos empregos, poucas e pouco movimentadas comunidades, sem "trilhas" em eventos de TI... Isso tudo pra mim só pode ter 2 interpretações: Ou o Grails não emplacou mesmo ou os usuários são todos maçons, dada a incrível discrição sobre seu uso.

Recomendo a leitura: https://www.linkedin.com/pulse/how-spring-boot-killed-grails-owen-rubel

Errata: "o que  mercado está adotando em projetos novos" -> " que o mercado NÃO está adotando em projetos novos"

Oi Yoshiriro,

em primeiro lugar é importante tirar de lado sujetividades: dado que nunca nos encontramos pessoalmente e nosso contato se restringe a este fórum, você não é capacitado a dizer se digo algo do coração ou não. 

O que digo, como pode ser visto no post anterior, está todo atrelado a fatos. Li o post que você mencionou e, sinceramente, foi exatamente o que você escreveu aqui sem tirar. Ainda pior, você está levando em consideração dados gringos e não nacionais, mas como disse antes, sempre qualquer framework que não seja mainstream (como o Grails, cairá nesta situação).

Sobre ser "legado". De novo, é questão de se atualizar. O que está caindo em desuso, tal como disse anteriormente, diz respeito ao modelo de desenvolvimento no qual você tem um framework que supre tudo, do backend ao front-end, tal como é o caso do Grails vanila. Entretanto, se você for levar em consideração que existem hoje profiles no Grails (e estes sim, estão em uso muito maior que o Grails padrão, vide o profile REST (que já experimentei e não me trouxe os problemas de lentidão que você menciona).

E no que diz respeito a produtividade para o desenvolvedor, o uso dos profiles que mencionei anteriormente ainda bate o Spring Boot. Especialmente quando você leva em consideração o GORM. E isto, novamente, com todas as vantagens daquele, o que não tira a relevância do Grails.

Sendo assim, dizer que uma tecnologia é "legada" por que não é a mais usada, é um exagero. "Legada" talvez (talvez) a gente possa falar de coisas como um Power Builder, Visual Basic 6, coisas assim. Mas tal como já disse, para algo que se encontra em constante desenvolvimento (vide o que também mencionei acima), é bobagem.

"você não é capacitado a dizer se digo algo do coração ou não"
Por isso usei o termo "parece-me", deixando claro que era um chute ;)

Quanto a números, se da outra vez usei números do Brasil e você usou o argumento, que eu discordo, de que não usam o termo "grails" na descrição da vaga, mesmo que usem. Até questionei na época que as outras tecnologias colocam. Simples assim. Mas nenhum número, nenhum fato o convence. Seja do Brasil ou "gringo".

Henrique.

Acho interessante seu conceito de legado. Então é quase impossível achar tecnologias legadas segundo ele.

Bem, falemos de forma prática: Por que um estudante brasileiro aprenderia Grails HOJE?
Vamos falar de Brasil, já que criticou o fato do outro estudo lá ter usado dados "gringos".

Vejamos o que o maior agregador de vagas de emprego diz sobre o Brasil: https://www.indeed.com.br/empregos?q=grails&l=Brasil (19 vagas quando pesquisei).
Se pesquise por "kotlin" que é algo bem mais novo e só este ano ganhou realmente força devido ao anúncio na Google IO: https://www.indeed.com.br/empregos?q=kotlin&l=Brasil (80 vagas quando pesquisei).
Pesquisando por "java": https://www.indeed.com.br/empregos?q=java&l=Brasil (2510 vaga na minha pesquisa).

Ou seja: usando o indeed como parâmetro temos que aproximadamente 0,75% dos locais que trabalham com Java usam Grails. Claro, considerando que o seu argumento de que "não colocam Grails na vaga, mas usam" está equivocado.

Fazendo as mesmas pesquisas no ApInfo (http://www.apinfo.com/apinfo/inc/list4.cfm) , que não permite URL amigáveis.
Grails: 6 vagas.
Kotlin: 1 vaga.
Java: 1220 vagas.
Porcentagem Grails/Java: 0,49%

Fazendo as mesmas pesquisas no Linkdein, pedindo para filtrar somente vagas no Brasil.
Grails (https://www.linkedin.com/jobs/search/?keywords=grails&location=Brazil): 17 vagas. 
Kotlin (https://www.linkedin.com/jobs/search/?keywords=kotlin&location=Brazil): 47 vagas.
Java (https://www.linkedin.com/jobs/search/?keywords=java&location=Brazil): 3848 vagas.
Porcentagem Grails/Java: 0,44%

Eventos Grails no Brasil? Talvez "meetups" com uma dúvida de pessoas.
Cursos presenciais de Grailsno Brasil? Not found. Aliás, a Novatec tentou abrir um para eu ministrar aqui em São Paulo, com 0 (zero) inscritos. Houve divulgação até aqui no GrailsBrasil.
Trilhas Grails em eventos no Brasil? Not found.
Último "case de sucesso" publicado aqui no Grails Brasil:  nov/2016. 

Ok, segundo seu conceito, não é legado, como aliás, quase nenhuma tecnologia é, segundo ele.

Mas, o que os números do Brasil te dizem? Nada?

Oi Yoshiriro,  existe a mentira, a mentira deslavada e a estatística.  Relaxa, bro, que não to te chamando de mentiroso, e sim dizendo que a estatística pode ser apertada pra dizer o que a gente quer.  Nesse caso, como você disse,  "Considerando o seu argumento como errado",  eu posso utilizar: "considerando seu argumento como certo, e imaginando que todas as empresas usam Grails e não mencionam na descrição"  a estatística ficaria  assim,certo?    Porcentagem Grails/Java: 100% pelo Indeed, Google, ou Linkedin. 

Qual está errada? Sei lá, eu n sei quantas fazem isso.  

Também foi maldade comparar com Kotlin no auge do Hype da linguagem, né? O motivo da quantidade de vagas pode ser por causa do anúncio do Google. Ora, as empresas que desenvolvem em android vão querer sair na frente  na contratação de Devs aumentando a demanda e a oferta, como você disse, por ser uma linguagem nova(e bem hipster), ainda não subiu. 

PS: Eu já ministrei cursos de Grails em Niterói no ano passado, utilizando até o livro do Kico(to te devendo uma cerva, não esqueci) com turma cheia. Já fiz palestra no CEDERJ - Niteroi Sobre grails com 100 pessoas na platatéia. 
Eu, nesse caso continuo com o Kico, acho que o Hype agora está em NodeJS e Front.  A minha percepção, inclusive, é uma sensação que o Hype em cima do ROR  também  caiu. Mas posso estar enganado.
Abraços;

Oi Yoshiriro:
pergunta: "Bem, falemos de forma prática: Por que um estudante brasileiro aprenderia Grails HOJE? "
Respondo: por que ainda hoje há pouquíssimas plataformas que oferecem o mesmo ganho de produtividade e qualidade, isto sem mencionar a baixíssima curva de aprendizado. E quando falamos de startups, por exemplo, é algo que caí como uma luva.
E respondo outra razão: por que se continuarmos pensando em aprender apenas o que aparece mais nas vagas de emprego, nos limitamos tecnicamente. Se formos seguir sua linha de raciocínio, não haveria por que aprender outras linguagens que não aparecem tanto no radar, tais como Scala, Clojure, Go... 

Números relacionados a empregos: novamente aquela mesma história que já falei posts atrás. Aliás, levando-se em consideração esta estatística que você levantou, se houvesse 0.5% de vagas para qualquer outra tecnologia que não se encaixe no mainstream, já é um número fantástico justamente por causa dos fatores que já mencionei acima. O que você fala sobre Grails se aplica não só a Grails, mas a todos os demais frameworks que não sejam o Spring ou JSF pra web no que diz respeito ao ecossistema Java.

Cursos presenciais de Grails no Brasil? http://formacao.itexto.com.br (para turmas abertas), http://www.itexto.com.br (para empresas) - por que não estamos realizando mais treinamentos ultimamente? Falta de gente interessada? Não. Apenas por que a quantidade de projetos que estamos desenvolvendo neste momento (muitos com Grails) não está nos permitindo por enquanto, entretanto já iremos reabrir agora no segundo semestre e, de todos os treinamentos que abrimos, nunca houve um caso no qual não houvesse alunos. Se o da Novatec não deu certo, talvez as razões sejam outras.

Sobre "meu conceito de legado", sugiro que você visite meu blog, pois fui uma das primeiras pessoas a escrever a respeito aqui e, ao que tudo indica, uma das poucas que vive disto - http://devkico.itexto.com.br 

Leonardo, eu realmente não acho que tive maldade no meu texto. Quando se diz "considerando que... " não está se dizendo que aquilo que é o correto e sim está se deixando claro um ponto de vista ou uma premissa pessoal. Só acho estranho as vagas de emprego enumerarem dezenas de tecnologias e omitirem justamente só o grails. Quanto a usar o kotlin, ora, se intenção fosse ser desonesto, foi mais uma curiosidade pessoal que acabei incluindo aqui. Tanto que nem fiz porcentagem dela com relação ao Java.

Henrique, não me leve a mal, ratifico que te respeito demais. Quando eu disse "teu conceito de legado", não foi pejorativo e sim para deixar claro que é o seu conceito. Não foi pra dizer algo como "teu errado conceito de legado".

Ratifico que gosto muito do framework Grails e da linguagem Groovy. Apenas levantei, baseado em números e fatos, que a adoção no Brasil e no mundo é muito tímida. E, pessoalmente (sei que é uma amostragem irrelevante), conheço bem mais casos de abandono do Grails (2 startups e uma empresa mega grande aqui do Brasil) do que de adoção. Lembro novamente que o último caso de adoção aqui já fará 8 meses.

Outro número:
Pesquisas sobre PHP (que não é hype, certo?) no GUJ: http://www.guj.com.br/search?q=php
Pesquisas sobre Grails no GUJ: http://www.guj.com.br/search?q=grails
Sei que o PHP é bem mais antigo que o Grails, mas essa pesquisa considera posts de 1 ou 2 anos, se não me engano.
E GUJ, teoricamente, deveria conter dúvidas de Java, não? Ou seja, nesse site, o Grails perde para um "estranho no ninho" :(

Pessoal, desconsiderem meus números do site do GUJ. Agora que vi que toda pesquisa lá trás os mesmos números rsrsrs

Um dia desses, conversando com um colega de profissão, estava justamente falando do Grails. Por que não emplaco? Ao contrário, parece que se fala cada vez mesmos.
A única hipótese de ter emplacado é o argumento de que os recrutadores coloquem pilhas de tecnologias nas descrições das vagas, menos "grails", por algum motivo que ainda não entendi.

Dai, fazendo uma análise bem fria, concluímos que Groovy é muito fácil e simples. O framwork é muito fácil em tudo. Mas PHP, Python e Javascript e seus frameworks também são. Só que suas APP não possuem altíssimos requisitos de memória, IO e CPU e não levam tanto tempo para inicializar. Fora o Java 8, que se aproximou um pouco da Groovy em vários pontos. Só que uma app Spring Boot com um "lego" do mesmo tamanho de uma "Grails", sempre vai exigir menos recursos de hardware e sempre vai iniciar mais rápido.
Dai as pessoas pensam: então por que usar Grails? Produtividade em termos de linguagem de programação e framework tenho igual em outras plataformas, mas não vou precisar de um VM de 2GB na nuvem para hospedar minha aplicação e nem vou precisar esperar 1 minuto para ela iniciar localmente. Então vou de outra mesmo.

Bem, mas isso tudo foi opinião minha e de meu amigo. O que acham?

"Por que não emplaco? " => "Por que não emplacou?"

Eu tenho algumas teorias de por que não virou algo mainstream. Não tenho dados, então vou falar apenas as minhas impressões.

A primeira delas diz respeito ao público do Grails. Enquanto no Ruby on Rails e no Node.js vi muita gente vindo de agências de publicidade, o pessoal do Grails era o pessoal de TI mesmo, que queria ter aquela produtividade do RoR, mas com os benefícios do Java EE. Como o pessoal de comunicação, como o próprio nome já diz, se expressa bem melhor, criou-se um hype muito maior, o que gerou uma boa quantidade de empregos.

Inclusive, é curioso, por que em 2009, 2010, muitas agências começaram a usar Grails, mas como você acabava tendo de lidar um pouco com as complexidades do Java EE, muitas acabaram saindo pois houve o crescimento do Wordpress mais ou menos no mesmo período, quando ele deixou de ser visto como uma ferramenta de blogs e passou a ser considerado como um CMS de uso geral.

Gente de TI, focada em solução de problemas (e isto é um dado empírico resultante das consultorias que faço (e são muitas)) não costumam sair por aí alardeando o que usam. Pegue o PostgreSQL por exemplo. É extremamente popular, no entanto, quando você vai olhar vagas e artigos a respeito, verá muito  mais gente falando sobre o MySQL (por causa do LAMP e, em última análise o próprio Wordpress). Idem com algumas outras tecnologias: Delphi, por exemplo, que hoje pouca gente fala a respeito, também é muitíssimo usado. Isto sem mencionar o VBA que, acredito, talvez seja A linguagem mais usada (em escritórios, bancos, há uma quantidade imensa de pessoas que usam isto, gente que não faz palestra, gente que apenas faz a coisa funcionar e vai pra casa. Os chamo de programadores invisíveis - http://www.itexto.net/devkico/?p=1799) 

O segundo fator é o setor de RH. E este eu posso até comprovar com base nas experiências que tenho. Como Grails é fácil de aprender, muitas vezes você coloca na vaga coisas como JSF ou Spring seguindo o argumento de que se o candidato sabe isto, irá aprender fácilmente Grials na sequência. E isto camufla bastante a coisa. Diga-se de passagem, quando ajudamos nossos clientes a encontrar mão de obra, os instruímos a fazer justamente isto. Gente que já sabe Java ou Spring aprende Grails em uma semana ou menos, razão pela qual você pode até colocar Grails como "desejável", mas não como foco.

O terceiro fator são os próprios eventos. Se você analisar friamente o que vê, verá que quem palestra não raro é quem vende o curso do momento (avaliem com atenção quem patrocina o evento antes de comparecer). E nisto você verá sempre aquilo que é considerado mais novo ser mais falado, e aquilo que já existe a mais tempo, e que não irá mais trazer tanto hype de novidade, ser menos mencionado.

Sobre eventos... bem, o TDC SP deste ano e em vários anteriores, por exemplo:
- Possui Trilhas de Go mas não tem a Google como patrocinadora.
- Possui Trilha PHP, que também é antiga.
- Possui Trilha Python, que também é antiga.

A Virada Tecnológica deste ano e de anos, que é um evento "probrizinho", dada a ausência de patrocinadores, possui palestras/cursos de Python, HTML e JS.

O mesmo vale para FISL.

Em ambos, nada sobre Grails há anos.

Ainda sobre eventos Yoshiriro, repare que você está comparando bananas com laranjas.

Você tá falando de trilhas sobre linguagens, não sobre frameworks. Sobre linguagens, naturalmente que haverá trilhas, mesmo por que haverá muito mais assunto a ser tratado. 
E sobre os patrocinadores, nem sempre o patrocinador é o mantenedor da coisa, basta observar que em diversos eventos os patrocinadores ganham, dentre outras coisas, uma ou mais palestras no evento o que leva, necessariamente, à proeminencia de assuntos que batem com o que estão vendendo.

O que sempre me assustou, isto sim, é a ausência do Groovy nestes eventos, pois esta sim é a segunda linguagem mais usada dentro da JVM.

No TDC há trilhas, nos demais que citei, não.  Sequer há divisão por "assuntos", só palestras e workshops mesmo. Qual a explicação para os demais?

A resposta é meio óbvia, mas vamos lá. Pela mesma razão pela qual há pouquíssimas palestras sobre JSF ou Play: porque não è mais novidade.
Nem por isto está aí poderiam ser chamados de legado. 
Porque o hype diminui com o tempo, aqueles que apenas fanfarronam (é que normalmente são quem faz a publicidade e o alarde) saem e ficam os que realmente usam e conhecem.

Infelizmente cheguei um pouco atrasado a esse tópico. No entanto, pretendo mostrar minha opinião em relação aos vários assuntos que foram levantados nele. Para isso, vou fracionar meus pensamentos em algumas respostas, para facilitar a exposição e a compreensão das minhas opinões. Procurarei ser o mais objetivo (e o menos passional possível) na análise de cada ponto levantado.

O primeiro que vou abordar é sobre a definição de legado. Segundo o autor do tópico:

Se algo é inadequado hoje, não se cria mais algo novo com isso. logo, é legado, IMO.

Eu não concordo com essa definição de legado, mas, segundo essa definição, é muito complicado definir o Grails como legado, uma vez que existem diversos sistemas em Grails recebendo atualizações, e existem diversos novos projetos que estão sendo iniciados em Grails. Além disso, o próprio Grails está sendo desenvolvido, apresentando novas funcionalidades e correções de bugs. Cabe ressaltar também, conforme o Kico já fez, o trabalho e investimento da OCI em divulgar o Grails por meio de novos guias lançados semanalmente (guides.grails.org), quickcasts (https://objectcomputing.com/products/grails/quickcasts/), mensagens no Twitter (https://twitter.com/grailsframework e https://twitter.com/search?q=grailsfw&src=typd), grupo no Likedin (https://www.linkedin.com/groups/39757), eventos (https://grails.org/events.html), blog (http://grailsblog.objectcomputing.com/), canal no Slack (https://grails.signup.team/) e contratações de novos membros para desenvolvimento do framework (https://objectcomputing.com/products/grails/oci-grails-team/).

Outro indício que mostra que o Grails não é legado, é o lançamento de dois livros referentes ao Grails 3 durante esse ano Grails 3 - Step by step (https://grailsthreebook.com) e Pratical Grails 3 - A hands on guide to Grails (https://www.grails3book.com/). Se pessoas estão escrevendo e comprando livros de Grails 3 (nova versão do Grails), espera-se que exista algum interesse em sua utilização.

Num esforço para ser bem racional, temos que entender que o Grails, apesar de ser um projeto open source, é encarado pela OCI como um produto (https://objectcomputing.com/products/grails/), uma vez que além dos serviços que relatei, eles também promovem suporte, treinamentos e consultorias (https://objectcomputing.com/products/grails/consulting-support/). Tomando essa visão como base, é coerente pensar que uma empresa só mantém uma equipe trabalhando em um projeto caso o faturamento com esse produto ao menos seja suficiente para vocelaê cobrir as despesas que tem com o produto (break-even). Ou que no mínimo, a empresa espera que no futuro, possa recuperar seu investimento atual, ainda que esse retorno nao seja necessariamente em dinheiro (corrijam-me os donos de empresa se eu estiver errado).

Portanto, sobre essa visão, podemos esperar que a OCI tenha uma dessas duas realidades com o Grails. É óbvio, que pode chegar uma hora que o Grails (ou qualquer outro "framework produto") deixe de ser interessante, o que leve a empresa a desistir do desenvolvimento. Não é o que temos no momento.

Dado o conhecimento limitado que temos do mercado, da OCI e do futuro, considero bem precipitado qualquer um de nós afirmar que o Grails é legado.

@Kico antes de ler esse post eu estava sinceramente desanimado, já conheço Grails a mais de 6 anos e procuro regularmente ver como anda a adoção e popularização da tecnologia. Nas buscas que fiz pela NET ele no máximo é lembrado como uma grande ideia que não colou, com aquele ar saudosista.
Legal saber que existem experiências que mostram o contrário. Toda vez que introduzo o framework para alguém que trabalha com Java para Web o pessoal fica encantado, mas não conseguem achar a mesma adesão no mercado.

Vitor, a situação do Grails é como um "beco sem saída", a minha opinião. Explico: Você adota porque vê que é muito produtivo. Depois sofre para achar mão de obra. Dai gerentes e lideres têm medo de adotá-lo por não achar profissionais depois. Dai novatos não têm estímulo para estudá-lo porque não acham vagas em nenhum site de emprego (ou acham meia dúzia de vagas). 
Ora, sua produtividade, em termos de "faça mais escrevendo menos" é semelhante a de tecnologias como Node.Js, Pyhton e Go, por exemplo. A diferença é que, se for pra ser "disruptivo" (sair do Java "tradicional") melhor usar uma tecnologia que não seja super comedora de memória nem vilã de IO levando a pagar instâncias mais caras em AWS e Azure da vida. Por isso acredito que o Grails não saiu do "limbo".
Em tempo: ratifico que fora levar 1 minuto para executar um teste automatizado simples e ser um super comedor de memória e IO, acho uma tecnologia excelente e agradável e também lamento que tenha ficado no "limbo", sendo até descartada pela SpringSource (afinal quando você se desfaz de um produto)?

Sobre ser "super comedora de memória e I/O" discordo absurdamente com base na experiência que temos aqui (aliás, inclusive de redução de custos em serviços como AWS, Azure, etc): é questão de saber programar mesmo.

Mas segundo esta mentalidade Yoshiriro, poderiamos dizer então que se estamos em Java, ficamos presos ou ao JSF e apenas o Spring? Afinal de contas, todas as outras alternativas vão cair no mesmo problema, não?

Kiko, quando falo em monstro de uso de memória e IO falo em PROD e DEV também.

Quando a ser isso em DEV: Será que é só questão de "saber programar"? 
Como funciona o Grails? Se eu não estiver enganado:
1. Os .groovy são compilados para .class
2. Para .class gerados em Groovy funcionaram na JVM e necessário um JAR do Groovy *
3. O projeto é transformado "por baixo" em um projeto Spring *

* - Itens que acredito que são vilões de memória e IO.

Quando a ser isso em PERG: Será que é só questão de "saber programar"? 
Aqui 2 simples testes resolvem essa questão:
1. Inicie um "Hello World" em Grails e outro em Spring Boot. Verifique a memória, CPU e IO de ambos.
2. Faça um CRUD, BEM PROGRAMADO, em Grails e outro em Spring Boot (bem programado aqui também, insisto). Verifique a memória, CPU e IO de ambos.

Ora, então uma aplicação bem programada em Node.Js, Python e Go também não reduz mais ainda os recursos, kiko? 
A questão é o "minimal hardware requirements", de cada uma. A de Grails, não tenho dúvida que é muito maior, numa aplicação bem programada em todos os casos, que das demais tecnologias.

"inclusive de redução de custos em serviços como AWS, Azure, etc"
Comparado a quê? Reduziu quando comparado a qual stack anterior? Pode nos contar? Talvez a JSF, que é um grande vilão de memória também.
Ah, e se usasse Node.JS., Python ou Go, BEM PROGRAMADOS também, seus custos diminuiriam mais ainda, não acha? ;)

"Mas segundo esta mentalidade Yoshiriro, poderiamos dizer então que se estamos em Java, ficamos presos ou ao JSF e apenas o Spring? "
Hummm... leu lá que falei de Node.js, Go e Phyton?
Quanto a Spring, tenho certeza que uma mesma aplicação, BEM PROGRAMADA, escrita em Spring Boot consome bem menos recursos que uma escrita em Grails. Basta estudar como o Grails funciona que fica muito fácil de concluir isso.
 

Kiko, não estamos "presos", mas fica complicado convencer a usar uma tecnologia comedora de memória/cpu/io sendo que o Spring Boot com Java 8 não fica muito atrás em termos de "escreva pouco e produza muito" mas tem comunidade muito maior e consome bem menos recursos tanto em dev quanto em prod, claro, se *bem programada*.
Ratifico que lamento o fato de Grails estar no "limbo". Eu realmente acho uma tecnologia muito agradável de trabalhar. Eu mesmo sempre sugiro ele a cada novo emprego que vou, mas sempre há resistência. Basicamente o argumento principal é que a produtividade que se ganha na programação/configuração se perde no tempo de inicialização da app, da execução dos testes e da geração do .war.

Por que adotar uma tecnologia de pouco uso e em queda na adoção? Vejam: https://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016-trends/
Segundo essa pesquisa, a adoção do Grails, que já era bem baixa, caiu quase a metade de 2014 para 2016. 

Oi Yoshiriro, sobre o funcionamento do Grails, você está errado. Veja.

"1. Os .groovy são compilados para .class
2. Para .class gerados em Groovy funcionaram na JVM e necessário um JAR do Groovy *
3. O projeto é transformado "por baixo" em um projeto Spring *"

Este JAR do Groovy é o mesmo que outra biblioteca qualquer: são basicamente as bibliotecas base da linguagem, tal como ocorre com qualquer outra biblioteca.
O projeto não é também transformado em um projeto Spring, ele nasce como tal. Se formos levar este tipo de argumento em consideração, não usaríamos biblioteca alguma. E outro ponto importante: este .class que o Groovy gera é o mesmo que o do Java: se você analisar internamente vai observar que o que ocorre são a inclusão de algumas interfaces pelo compilador, coisas assim.

A comparação com o Spring Boot neste caso também é bastante complicada por que, apesar de hoje serem primos (Grails 3 é uma aplicação Spring Boot na realidade, não uma aplicação "transformada") seguem caminhos diferentes: o Grails "vanilla" é a solução "tudo em um", fullstack, que já vai vir com tudo pré-configurado e pronto para que você implemente aplicações nas quais a renderização é aquela padrão, já do lado servidor, enquanto que no caso do Spring Boot, o uso primário é na escrita de micro-serviços, que é inclusive uma das principais razões que justificou sua criação na época.

(entenda: não disse aqui que você programa errado, mas sim que os problemas que vejo relacionados a estes problemas de memória normalmente tem esta razão)

Sobre consumo de memória, o que quero dizer é que temos diversos casos aqui de aplicações em Grails executando em servidores bem modestos e com um número significativo de usuários dia, razão pela qual, do ponto de vista de consumo de memória, não é lá um grande problema. Bom: neste caso temos um case bacana aqui: uma aplicação que era feita em PHP (Laravel se não me engano) que consumia US$ 2000,00 mês na AWS e hoje, US$ 300,00 em um servidor que era metade (e temos diversos casos nesta direção aqui na Itexto). Mas aí vai além do que usamos para programar, entra muito a questão da arquitetura.

Sobre consumo de memória do lado desenvolvedor, concordo com você e, sinceramente, vou até um pouco além: é algo da JVM em si, e você raríssimas vezes consegue melhorar isto. Especialmente depois de ter feito a comparação com Node.js (eu mesmo tenho usado bastante Node e, neste ponto, acho que ele acaba com a JVM).

(quer uma exceção à regra? Apache Tapestry, mas este sim é um projeto que não tem sequer um roadmap garantido no futuro, ao contrário do Grails, mas consome pouquissima memória, é extremamente rápido no carregamento e a experiência de desenvolvimento parece um sonho perto do resto da JVM)

E pra finalizar, a mesma pergunta que te fiz antes, repito e respondo aqui: "o que você disse sobre o Grails, o fato de ser menos popular se comparado com as demais alternativas, não englobaria no mesmo conjunto todas as demais alternativas além do Spring e JEE que são o mainstream?"

Aqui vejo uma questão mais relacionada à formação que a tecnologia em si, e aqui vou ser genérico. Vejo duas linhas de formação hoje no Brasil: a da ciência de computação no seu estado puro, em que aprendemos os princípios da ciência propriamente dita, e que me permite uma visão mais global, me permite avaliar quais ferramentas adotar e com isto uma carreira até mesmo mais longeva. Vai ser mais difícil conseguir um emprego de forma imediata, saindo da faculdade, neste caminho? Sim: mas no médio e longo prazo se paga.

Na outra direção está a formação "voltada ao mercado de trabalho", na qual você vai focar nas tecnologias do momento. Você vai aprender então o Spring na faculdade quando for lidar com o backend e algo como Angular no Frontend (vejo muito isto nas faculdades aqui em BH, por exemplo). Este sujeito vai estar diante de uma comunidade maior, popular e com mais artigos escritos no momento? Sim. Consegue emprego mais rápido também? Com certeza. Sai da faculdade empregado. Mas aí entra a seguinte pergunta: e no médio prazo, na média, quem ganha? O primeiro, o da computação.

No caso da JVM hoje (e amanhã) o que será mainstream é o JEE e talvez o Spring (se o JEE não o engolir). Como alguém que lida com legados na JVM e outras plataformas (mas vou falar da JVM) sei bem como é lidar com um framework "legado". Apache Tapestry, por exemplo: ali sim temos um zumbi (sequer há um plano de desenvolvimento futuro). Entretanto, apesar de zumbi, deveria eu, me pondo no papel de jovem em início de carreira, ignorá-lo? Do ponto de vista imediatista, sim. Do ponto de vista de crescimento intelectual (que é o mais importante e que leva tempo), seria merda. Seguindo no mesmo exemplo (Tapestry), embarcamos recentemente na evolução de um legado feito nesta tecnologia (sem reescrevê-lo) e o crescimento intelectual que estamos tendo foi astronômico. Vimos soluções que não imaginávamos, topamos com um framework extremamente rápido (põe Grails no chinelo, idem o Spring Boot) para se desenvolver.

Sendo assim, pra resumir: "por que adotar uma tecnologia em queda de adoção?" - novamente a resposta deveria ser óbvia, mas vamos lá: por que você escolhe as suas ferramentas de acordo com o problema que tem pra resolver, não pra ser o mais popular ou estar entre os mais populares. Sim: eu sou um cara da computação, e cada dia mais velho, e já passei por várias escolhas baseadas em popularidade que no médio prazo se tornaram o que você chama de "legado".

Ok, já que não é pra escolher tecnologias que estão sendo adotadas de forma crescente, devemos escolher as que, segundo nossos estudos são boas com o risco de serem descontinuadas? Escolher um legado atual mas que é ótima tecnologia ou um possível, talvez, quem sabe, futuro legado? É uma boa questão a se refletir. 

Bem, no final o debate foi respeitoso e eu coloquei números e argumentos e outros colocaram argumentos. Cabe a cada leitor desse debate chegar a sua conclusão e adotar ou não o Grails.

Nem oito nem oitenta: é mais uma questão de maturidade mesmo.
Sobre ter o risco de ser descontinuado, bom: no caso do código aberto a descontinuidade não é tão comum assim como no caso das tecnologias proprietárias. É simplesmente saber interpretar o roadmap e a comunidade por trás, ir além do que a mídia corrente publica (que é fortemente influenciado por quem patrocina, mais que pela razão).

E digo isto de modo geral: bem além do Grails.

(Eu acho está discussão fantástica)