Стоит ли Grails (сейчас)?

Я знаю, что это дубликат , однако мир Grails значительно изменился, поскольку этот вопрос был задан более года назад, а также поддержка IDE в Eclipse, поэтому, пожалуйста, не просто слепо закрывайте его.

Я думал, что ответ был да, и приступил к новому проекту с Grails 1.2.0 и флиртовал с помощью Groovy/Биты Grails Интеграция STS Eclipse.

Я думаю, что этот вопрос заслуживает пересмотра после года эволюции Грааля, когда ответ был определенно смешанным.

Итак, как опытный Java-разработчик Java, у меня есть эти вопросы, и я буду благодарен за мои предположения:

Теперь ли Грайль стоит против Ruby или рулон?
Неужели он преодолел свой багги?
Оказывает ли это реальные выгоды для быстрого развития? (Я признаю, что сейчас боюсь, что я прошел обширную базовую конфигурацию, чтобы сделать свое приложение на заказ, которое не является списком и ориентировано на страницы).
Выполняется ли это для приложений реального мира? (Он чувствует себя тяжелым)
Является ли плагин Eclipse лучше, чем он был, и подходит для цели? (Я еще не думаю)

Спасибо

EDIT: Я учусь, когда я ухожу, и у меня есть несколько серьезных проблем, связанных с тем, чтобы жить с каркасом, а не с возможностями каркаса. Я добавляю их, потому что думаю, что они должны быть соображениями и основаны на моем опыте и мнении, и могут помочь кому-то, кто пытается решить, пойти ли граалю. Я также могу показать свой недостаток опыта в этой структуре, поэтому ничто из этого не означает критику. Я опытный разработчик, и вот что я нашел:

Отладка действительно сложна. На самом деле это почти невозможно, особенно в качестве новичка в каркасе, когда вам нужен ваш надежный друг-отладчик. Я потратил больше времени, чем я должен отслеживать проблемы синтаксических ошибок в некоторой части кода, связанные со ссылками на поля домена, которые вызывают молчащие сбои где-то в стеке.

Ведение журнала откровенно ужасно. У вас есть два режима: "ничего полезного" и "чрезмерное количество бесполезных вещей". Мой журнал отладки был 128 МБ после одного запроса страницы и ничего не содержит о моей ошибке. По моему мнению, весь вопрос регистрации требует пересмотра в рамках.

IDE STS Eclipse имеет предельное значение. Помимо синтаксиса hilighting, это не очень полезно. Вы не можете отлаживать код, чтобы он был прославленным редактором. Насколько мне известно, подсказки кода являются неоднородными, и вообще нет поддержки GSP. Это также самый медленный подключаемый модуль Eclipse, который есть у меня на рабочем столе - примерно на 2 минуты для запуска. Это ужасно медленно. Я вернусь к текстовому редактору (который вы также заметите, что все онлайн-видеоролики тоже) и некоторый пользовательский синтаксис hilighting.

У меня есть серьезные проблемы с производительностью. Слишком рано говорить, но я уже пытаюсь настроить базу данных из-за спящего режима. Возможно, этого и следовало ожидать, но мне действительно нужно, чтобы моя модель домена была простой, чтобы соглашения могли выполнять исполняемые запросы.

И последнее, соглашение о том, что ваша логическая модель домена и ваша физическая модель базы данных должны быть идентичными, не являются разумным дефолтом и вряд ли когда-либо будут иметь место в реальном мире. Я знаю, что вы можете отделить эти два, но это создает определенную сложность, о которой, я думаю, можно было бы избежать, если бы соглашения были расширены. Существует неадекватная документация о составе и что вам нужно сделать, чтобы она работала на практике.

Ответ 1

Я использую Grails более 4 месяцев, и я постараюсь дать вам личное представление о Grails и его удобстве использования.

Является ли Grails теперь стоит против Ruby или другого рулона?

Конечно, ответ не "Да" или "Нет", а зависит от. Это зависит от ваших требований (вам нужно быть в Java World?), И о ваших предпочтениях (предпочитаете ли вы, ориентированное на домен, развитие, вы предпочитаете Groovy...)? Тем не менее, я могу ответить, что Grails - серьезная альтернатива Rails. Я считаю, что независимо от вашего приложения Rails, вы можете это сделать и с Grails. Но в зависимости от характера вашего проекта это может занять более или менее время. Опять же, если вы знакомы с Rails, но не с Grails, Rails является более безопасным вариантом.

Сможет ли он преодолеть свой багги?

Да. Если вы посмотрите мои первоначальные сообщения (на этом веб-сайте или другие), я много жаловался на ошибки Grails. Но вам просто нужно помнить, что Grails немного грубо на краю (например, не слишком много использует наследование домена), и как только вы знакомы с каркасом, вы не испытываете слишком много неприятных сюрпризов. Я не говорю, что Grails не глючит. Это, безусловно, больше, чем Rails. Но также он более полезен, чем багги. Совет для этого: используйте как можно больше плагинов. Потому что многие из них ошибочны, а некоторые несовместимы между собой. Итак, не включайте плагин Grails, если вы не уверены, что плагин Grails является современным, неинтрузивным и проверенным (самостоятельно).

Действительно ли это приносит быстрые выгоды для развития?

Да. Вам почти не нужно иметь дело с дизайном БД. Конфигурация почти завершена для вас с самого начала благодаря Конвенции по конфигурации. Ваше приложение легко поддается поддержке. Единственный недостаток, который я вижу, - это front-end-разработка, которая не так богата, как другие технологии (например, Rails или ASP).

Выполняется ли это для приложений для реального мира?

Я не могу сказать, потому что я все еще не ездил на своем веб-сайте, но я уверен, что, поскольку sky.com использует Grails, а сайты привлекают значительный трафик - 7 миллионов просмотров страниц в день. Снова производительность сильно зависит от архитектуры приложения и дизайнерских решений.

Является ли плагин Eclipse лучше, чем он был и подходит для цели?

Не знаю. Я использую IntelliJ, но я думаю, что это не намного лучше, чем год назад, согласно жалобным сообщениям, которые я вижу в области Грааля.

Надеюсь, это поможет.

Ответ 2

Недавно начал проект Rails, делал некоторые вещи с Grails.

Мое главное с Rails заключается в том, что есть много вещей, которые полностью непрозрачны для dev (которые я ненавижу), и это имеет тенденцию к увеличению, когда вы начинаете добавлять больше плагинов/генераторов/libs/etc, потому что для их комбинирования вам нужно будет что-то исправить. Вы чувствуете, что rails + plugins - это просто гигантский взлом DSL, который начинает ломаться, если вы используете неправильную комбинацию плагинов + версий.

С Grails, хотя экосистема намного меньше, все имеет тенденцию быть относительно последовательным. Подход DSL не очень используется и с помощью обычного, но скучного дизайна (я имею в виду использование классов, интерфейсов и т.д. Вместо DSL) гораздо легче понять, как работает сантехника.

Выполнение сравнения 1 к 1, вот как это сделать:

Языковая реализация. Я предпочитаю Ruby over Groovy, хотя я не очень хорошо знаю Ruby. Groovy похож на язык с хорошим намерением - плохой реализации, где некоторые функции свариваются поверх синтаксиса. Я имею в виду некоторые специальные классы, которые, кажется, существуют только для того, чтобы разрешить некоторые хаки.
Возможности платформы. Rails намного опережает это. Вы можете настроить большинство аспектов Rails (например: макеты, шаблоны, css/js упаковщики, валидация, рамки тестирования и т.д.) Несколькими способами. Grails отстает от этого, хотя и достаточно гибкий для большинства случаев использования.
Плагины. У Rails есть тонна плагинов, которые можно рассматривать как благословение или кошмар. Некоторые плагины не поддерживаются, другие не играют хорошо с некоторыми функциями или плагинами, и там много вилок. Я учусь придерживаться основных и наиболее используемых плагинов (authlogic, haml и т.д.), Grails имеет отличные плагины для основ (авторизация/аутентификация, ORM и т.д.) И некоторые другие плагины для небольших файлов.
Тестирование. У Rails есть множество способов тестирования, но это не обязательно хорошо. Некоторые системы тестирования не очень хорошо работают с некоторыми плагинами и т.д. У Grails меньше тестовых плагинов, но снова они лучше интегрируются с некоторыми из основных плагинов (поскольку для интеграции не так много плагинов)
База данных: Grails выигрывает далеко.
- Я предпочитаю моделировать свои классы домена вместо взлома моего db.
- Hibernate (который используется под капотом) находится в нескольких шагах от его коллеги Rails. Хотя есть datamapper для Rails (который более похож по своей природе на Hibernate, чем ActiveRecord), я чувствую, что он недостаточно зрелый. Грайлы также имеют миграцию через плагин.
- У вас большие возможности кэширования для Hibernate (кеш JBoss, EhCache и т.д.), которые могут повысить вашу производительность с помощью крыши.
Библиотеки. Я чувствую, что у Ruby есть много библиотек для новых вещей, таких как NoSQL или облачные сервисы, в то время как у Java есть gazillion библиотек для более старых вещей, таких как обработка Excel. Не забывайте, что библиотеки Java обычно намного быстрее, чем Ruby
Режущая кромка. Rails - это больше шумихи, а это означает, что у него больше ресурсов. Это означает, что если вы пытаетесь интегрировать MongoDB или Riak с Rails, есть хорошие изменения, которые кто-то уже сделал. Grails отстает, главным образом потому, что он не так популярен, поэтому сообщество стремится сосредоточиться на решении повседневных проблем, вместо того, чтобы использовать все элементы кровоточащего края, такие как NoSQL, и т.д.

Вот пример:

Большинство плагинов grails генерируют код в виде моделей и/или сервисов. Остальное обычно обрабатывается библиотекой. Вы можете проверить код модели/службы, посмотреть, что он делает и изменить.
Большинство плагинов Rails обычно соединяются с Rails API, а это значит, что вы вызываете какую-то функцию или включаете какой-то модуль, а затем используете собственный DSL-модуль. Это работает отлично , когда оно работает, но когда оно ломается, это ужасно, и вам приходится исправлять некоторые вещи или устанавливать другую версию плагина или плагина. Я предполагаю, что более опытный Rails-разработчик более комфортен с этим, но я не уверен.

Вывод:

Если вам нужен край кровотечения, не обращайте внимания на некоторые случайные исправления, предпочитайте большое сообщество и/или не против использования DB в стиле ActiveRecord, идите с Rails. Кроме того, Ruby как язык очень элегантный
Если вы предпочитаете дизайн класса-интерфейса вместо DSL, предпочитайте моделировать свое приложение через модели, не нуждайтесь в изысканных функциях и знакомы с экосистемой Java, идите с Grails

Ответ 3

Это очень стоит!

Мы используем Grails в нескольких проектах, все они с большим успехом по следующим причинам:

Easy - это одна из самых простых фреймворков, которые мы когда-либо использовали
Повторное использование устаревшего кода. Все, что нам нужно сделать, это получить наш устаревший код и бросить его в папку lib или src, и это было сделано. Просто отлично для нас.
Структура устаревшей базы данных - это потрясающий инструмент, если вы хотите генерировать визуализацию данных в устаревших базах данных.

Теперь о жизнеспособности:

Ошибки: мы не сталкивались с слишком большим количеством ошибок, так как версия 1.1 (версия 1.0 была слишком сложной для нас)
Инструменты: Netbeans действительно улучшается на этом фронте, но даже не закрывает другие инструменты, такие как Intellij IDEA (отличная поддержка!). То же самое можно сказать об Eclipse.
Портативность: мы никогда не сталкивались с одной проблемой в наших проектах.

Ответ 4

В настоящее время у нас есть полдюжины приложений Grails, и, хотя Grails отличается от java-фреймворков и требует некоторого времени обучения, он окупился, потому что мы использовали Agile-методы. Подробности:

Мы используем IntelliJ. Это не очень дорого и выплачено за несколько недель для нас.
Автоматическое тестирование, непрерывная интеграция и рефакторинг являются обязательными для всех динамических языковых кодов. Если вы уже практикуете TDD или, по крайней мере, имеете достойный охват тестового кода, то он не добавляет никакой дополнительной работы.
Hibernate по умолчанию поставляется с Grails, но вы можете использовать другие механизмы сохранения. Есть еще 5 плагинов настойчивости, доступных сегодня.
Ведение журнала явно не вызывало беспокойства у Грэма Рошера, но оно неуклонно улучшалось. Я не сталкивался с проблемой, когда ошибка не была зарегистрирована, хотя (вы должны убедиться, что вы правильно используете исключения в своем коде)
Отладка была явно не на радаре (но это не улучшилось). В любом случае мы не полагаемся на отладку.

Это, как и все новые технологии, я рекомендую создавать прототипы, обзоры кода, парное программирование и, возможно, использовать некоторые консультации.

Ответ 5

Это очень того стоит. Я использую его уже более года и люблю его. Раньше я уклонялся от этих видов инструментов rad, но он изменил то, как я работаю. С выпуском 1.2 он стал еще лучше с лучшей информацией о трассировке стека (особенно для GSP).

Единственная проблема, с которой я столкнулся при масштабировании, - это спящий режим и кеш, который действительно не является проблемой Grails. Даже тем, кто мне не нравится спящий режим в целом, то, как грайль обертывает его с помощью GORM, является произведением искусства для меня. Атрибут закрытия критериев замечателен для работы.

Ответ 6

Мне еще предстоит найти кого-то, кто является экспертом как в Grails, так и в Rails и предпочитает Grails.

Если вы знаете оба хорошо, то вы почти наверняка предпочитаете Rails.

Grails обычно обращается к разработчикам Java, которые опасаются изменения платформы.

В этом случае я думаю, что JRuby, вероятно, лучший способ принять гибкий подход к устаревшему jvm.

Ответ 7

Недавно использовав Grails для проекта, я хочу поделиться своим опытом по сравнению со стандартной разработкой приложений J2EE.

Действительно ли это приносит быстрые выгоды для развития?

Определенно, это так. Даже если путь для лесов поднимается на ранних этапах, а условности переоцениваются в соответствии с собственными потребностями, период запуска очень короткий, так как нам не нужно заботиться о многих разных технологиях. Такой легкий вес заставляет нас работать не только быстрее, но и более точно и чисто.

Написание тегов никогда не было проще - в то время как с JSF мы сначала обсуждаем, стоит ли это делать, с Grails мы просто делаем это. Для работы testdriven и для достижения высокой степени охвата также делается довольно легко, хотя различные тестовые примеры и насмешливые стратегии иногда противоречивы и ошибочны.

Переключение с Java на Groovy - большое удовольствие, нам очень понравилось иметь списки и картографические литералы, закрытие, сборщики, чтобы отбросить реализацию "картографической карты" котла на Java и написать компактный, содержательный и целенаправленный код.

То, что замедляет скорость разработки, - это не такая идеальная поддержка IDE, что также справедливо для плагина IntelliJ, который мы используем. Плохая, часто старая и даже неправильная документация, разбросанная по разным местам (нарушение обещания "поиск закончен" ) также становится на пути быстрого развития. Поэтому нам часто приходилось возвращаться к чтению исходного кода, что впоследствии испугалось базовыми иерархиями классов Spring.

Ответ 8

Отладка действительно сложная. Я никогда не считал, что это большая проблема. Вы можете либо подключить отладчик и пройтись, либо вставить в него код println/logs, чтобы решить, что происходит.

Ведение журнала откровенно ужасно. Я согласен, что трассировки стека обычно предоставляют 4 страницы бесполезной информации, причем случайная строка является информативной. Однако его небольшая цена за такую потрясающую инфраструктуру.

IDE STS Eclipse имеет предельное значение. У "Затмения" плохо развита поддержка Grails. Используйте IntelliJ, если это возможно. Я напряжен, но если бы моя компания разрешила мне, я бы с радостью заплатил наличные деньги для IntelliJ.

Ответ 9

Я использую Grails с самых ранних 1.0-бета-дней, и я могу только рекомендовать, чтобы вы начали серьезно относиться к Groovy/Grails, если вы пришли из магазина Java.

Если вы являетесь магазином Java и рассматриваете Ruby Rails, остановите Grails. Если Grails не работает для вас, вы всегда можете запустить Rails.

Ответ 10

Я расскажу о своем трехлетнем опыте с использованием Grails почти в десяти приложениях. Я не могу сравнивать с Ruby on Rails, поэтому я отвечу на другие вопросы.

Сможет ли он преодолеть свой багги?

Да, это так. Я испытал несколько ошибок Grails на Grails 2.0.4/2.2.4.

Действительно ли это дает преимущества быстрого развития?

Довольно легко учиться, легко развиваться, никогда не видел, чтобы кто-либо с хорошим знанием мира Java принимал больше, чем рабочую неделю, чтобы знать основы. Также легко поддерживать. И вам не нужно много беспокоиться о своей БД - просто убедитесь, что ваш мак

Является ли плагин Eclipse лучше, чем он был и подходит для цели?

Выбирайте свою IDE очень осторожно. Eclipse мне очень помог, но он падает и вызывает больше проблем, чем нужно. Я пошел на IntelliJ, и в испытательный месяц это был лучший выбор. В последнее время я использую Sublime Text, несколько плагинов и старую командную строку. Я только иду в IDE в особых ситуациях - например, использовать его отладчик.

Выполняется ли это для приложений для реального мира?

Это тяжело. Много анализируйте свои варианты дизайна перед написанием своих моделей. Сделайте много исследований о хорошем дизайне Grails. Большинство вещей, которые я делал два года назад, я могу понять, как сделать это лучше сейчас, так как я более опытен. Он отлично работает с приложениями для реального мира, но в зависимости от ошибок, которые вы делаете, Hibernate действительно может быть головной болью.

Ответ 11

Плагин Grails Eclipse - это дерьмо. Он вообще не срабатывает и не поддерживает гибкость Groovy. По слухам, NetBeans и IntelliJ намного лучше, но я еще не пробовал их.

Выполняется ли это? Конечно. Даже Ruby on Rails выполняет, пока вы бросаете на сервер достаточное количество серверов. Я не знаю, как Grails сравнивается с различными фреймворками Java.

Действительно ли это дает преимущества быстрого развития? Ну, я все еще не хватает большого материала Ruby/Rails. Он не распознает параметры запроса даты и Enum автоматически (опять же, Rails также имеет некоторые проблемы с датами), TimeCategory должна быть частью стандартной конфигурации, но это не так. Но там также много материала, требующего очень небольшой конфигурации.

Это не совсем так, где Rails (я особенно с нетерпением жду Rails 3), но гораздо приятнее работать с чем-то большим количеством Java-фреймворков. Тем не менее, магия под поверхностью идет глубже, чем в Rails. Например, система Constraints действительно мощна, но построена на огромном слое непроницаемого материала Spring и действительно негибкая, если вы хотите использовать ту же самую мощность несколько иначе. Рельсы легче подорвать, IME.

Стоит ли это того? Да. Это лучший выбор, чем что-то еще? Это зависит.

Ответ 12

Я предлагаю вам попробовать себя. Мне нравится гибкость Grails и скорость разработки. Однако, как вы видите, другие люди отличаются друг от друга. Я хочу иметь возможность разрабатывать быстрые приложения для своих клиентов с использованием платформы Java, и я нашел, что Grails очень хорошо работает для нас.

Я также нашел интерфейс очень гибким для разработки. Я также думаю, что вам нужно использовать здравый смысл и тщательно выбирать плагин. Я придерживаюсь плагинов, поддерживаемых springsource.

Ответ 13

По моему опыту, Grails привносят на стол несколько очень привлекательных функций, которые, безусловно, заслуживают изучения и использования.

Ловкость - вещи, которые мы использовали, чтобы занять несколько недель для реализации в обычных проектах J2EE, - это, как правило, дневная работа с системой плагинов Grails. Такие вещи, как ajax, jquery ui, acegi, спокойная реализация, система планировщика и многие из них.
Работает на JVM, которая облегчает необходимость изучения другой системы времени выполнения и ее особенностей.
Java как синтаксис и groovy синтаксический сахар. как лучшее из обоих миров. Вы можете сразу начать с Java вместо изучения синтаксиса нового языка, такого как Ruby, а затем медленно перейти к синтаксису groovy, который является надежным, простым и интуитивно понятным

Для менеджеров проектов, если по какой-либо причине не существует убедительной причины "не использовать" grails (сопротивление от выше, принятие новой технологии или что-то еще), я не вижу причин, по которым grails не может быть использовали или, по крайней мере, попробовали.

Чтобы ответить на беспокойство об отладке, это не так сложно. Отладка легко, если вы используете NetBeans IDE. Это подводит меня к еще одному вопросу. После нескольких экспериментов со всеми IDE мы обнаружили, что Netbeans наиболее подходит для выполнения этой работы. Он имеет лучшую поддержку для завершения кода, подсветки синтаксиса и отладки и т.д. На мой взгляд, STS недостаточно хороша для этого.

Ответ 14

Является ли плагин Eclipse лучше, чем он был и подходит для цели?

За последний год он значительно улучшился. В декабре я присутствовал на конференции Groovy & Grails в Лондоне. Был большой разговор о интеграции Groovy & Grails в записи Eclipse/SpringSource STS, см. видео.

С моей точки зрения, Eclipse получила массу преимуществ. В настоящее время IntelliJ, похоже, немного впереди, но это может измениться в течение следующих нескольких месяцев.

Ответ 15

Что касается плагина eclipse, он по-прежнему подходит, но вы можете использовать версию eclipse из Spring Source (SpringSource Tool Suite)

http://www.springsource.com/products/sts

Он довольно приличный по сравнению с предыдущими версиями плагина, и поскольку Spring Source приобрел компанию, ответственную за grails и groovy, вы можете ожидать, что STS станет быстрее быстрее

Ответ 16

Лично я изучил RoR и использовал его для нескольких домашних проектов, но затем переключился на Grails, главным образом потому, что он работает на JVM, и поэтому я надеюсь использовать множество программ производительности/профилирования Java, которые должны помогите определить любые узкие места в коде, прежде чем они станут проблемой.

В целом я не нашел слишком большой разницы в качестве IDE, используемого RoR vs Grails. Хотя, если быть честным, я программирую на Linux и не пробовал разработку TextMate для RoR. Когда я использовал RoR, я использовал Netbeans.

Сейчас я программирую с использованием STS, и мне приятно использовать его с Grails, хотя я все же считаю, что обнаружение/завершение метода может быть сделано для работы намного лучше.

Ответ 17

Я разработчик Java на полный рабочий день, но использую рельсы для моих хобби проектов. Мы год назад оценивали грабли для проекта на работе. Мой опыт с Грайлом оставил меня немного разочарованным, и именно по этой причине я начал исследовать рельсы. Использование обоих моих впечатлений заключается в том, что даже если groovy отстает от рубина как языка, рельсы обеспечивают значительно улучшенный опыт над граалями. Проще говоря, рельсы, по-видимому, решают гораздо более реальные проблемы в мире, особенно когда вы учитываете количество хороших драгоценных камней, которые доступны. Я думаю о таких вещах, как поиск, управление версиями, rss, non crud apps, интеграция с облачными сервисами и т.д. У меня создается впечатление, что Грайль вокруг уровня рельсов 1.x. К концу этого месяца рельсы 3 должны были быть выпущены. На самом деле мы решили перейти к использованию рельсов на работе. В конце концов, grails легче подбирать для разработчиков Java, но в конечном итоге не нуждается в уточнении, чтобы охватить более широкий диапазон требований к проекту.

Ответ 18

Я бы сказал, нет. Он слишком раздутый, imho, для большинства применений, особенно если вы просто хотите прототипировать что-то. Нам не нужен весь этот код, все эти зависимости, связанные с grails, чтобы создать веб-приложение. Вам не нужно spring каждый раз, когда вы хотите выпустить веб-приложение. Посмотрите, чего вы пытаетесь выполнить, прежде чем добавить весь мир, полный зависимостей, к вашему стеку. Я думаю, важно знать, к чему относится ваше приложение.

Я рекомендую посмотреть на что-то вроде ratpack, которое намного легче, почти как синатра для рубина.

Ответ 19

Я хочу указать на еще два вопроса: использование памяти и рынок труда. Приложение Grails занимает много памяти, особенно в режиме разработки, например. 600 Мб для приложения среднего размера. При развертывании в режиме производства, например, файл войны в Tomcat, использование может быть около 500 Мб. Это частично унаследовано от использования Java.

Что касается рынка труда, и, насколько я читал, спрос на программистов Grails практически отсутствует в объявлениях о вакансиях по сравнению с, например, Django и Ruby on Rails.

Ответ 20

Из моего опыта на конец 2013 года.

Доводы

когда вы используете очень мало плагинов и ограничиваете набор Grails no-s и никогда, это довольно плавное развитие.

против

Обновление (F5) всегда является проблемой. И это самое раздражающее. По какой-то причине мне пришлось перезапустить сервер на каждом третьем-четвертом обновлении. Существует известная ошибка перезапуска: question1, question2, хотя это случается редко.
Ошибки на уровне языка. Когда я использовал статические внутренние классы, мне всегда нужно было перезапустить сервер при изменении. Несмотря на отсутствие проблем со строительством, использование языка ограничено для меня.
время запуска, время сборки, размер приложения (70 мегабайт для небольшого приложения), использование памяти
удаленная отладка только, отладка IDE очень нестабильна.

Ответ 21

Сможет ли он преодолеть свой багги?

Это все еще ужасно. Я не знаю их начала, но переход от Grails 2 к Grails 3 по-прежнему является кошмаром, и они ломаются больше, чем они решают.

Действительно ли это приносит быстрые выгоды для развития?

Я потратил один час на то, чтобы тесты Grails выдавали что-то в консоли (это не работает из коробки), даже в Java вы не будете тратить такое количество времени на вывод чего-либо из тестов.

Выполняется ли это для приложений для реального мира?

Я до сих пор не знаю ни одной известной компании, которая строит что-то с Grails.

Является ли плагин Eclipse лучше, чем он был и подходит для цели?

Я не знаю, почему кто-то все еще использует Eclipse, но поддержка IntelliJ для Grails 3 просто непригодна.

Итак, отвечая на главный вопрос:

Значит ли это Грааль (сейчас)?

Если вы не можете позволить себе лицензию Microsoft Access, возможно. Для реальных проектов я бы держался подальше от Grails. На самом деле это всего лишь мертворожденный ребенок.