Подтвердить что ты не робот

Насколько стабилен язык Groovy?

Мы пишем большую производственную систему на Java, и я рассматриваю вопрос о том, можем ли мы написать некоторые компоненты на одном из динамических языков на основе JVM. Groovy представляется лучшим выбором с точки зрения совместимости Java. Но реализация Groovy достаточно надежна для использования в производстве (я бы так предположила), а сама спецификация языка Groovy сама по себе достаточно стабильна, так что нам не придется пересматривать наш производственный код в течение года или два? Каковы ваши впечатления?

Резюме (5/30/09): Хорошие комментарии, смысл в том, что вы должны быть осторожны в принятии Groovy для критически важного производства, это хорошо для вспомогательных применений, например, для объединения тестовых примеров, и там средний участок, где он, вероятно, хорошо, но сначала делайте домашнее задание. Производительность - это проблема, которая должна быть сбалансирована с увеличением производительности разработчиков. Билл и Ихор имеют одинаково полезные ответы, основанные на использовании Groovy, поэтому это была броска монеты.

Обновление (12/3/09): Совсем недавно я серьезно рассмотрел Scala, еще один язык JVM. Он был разработан и реализован Мартином Одерским, оригинальным автором текущего компилятора javac и соавтором Java Generics. Scala является строго типизированным, но использует тип inferencing, чтобы вырезать много шаблонов. Это приятное сочетание объектно-ориентированного и функционального программирования. Джеймс Гослинг ему нравится. Джеймс Страчан, автор Groovy, тоже любит. И Odersky опыт записи javac означает Scala raw производительность не далеко от Java, что впечатляет.

Обновление (4/26/11): посмотрите Groovy ++, статически типизированное расширение Groovy, который performance эквивалентен Java. Выглядит очень интересно.

4b9b3361

Ответ 1

Изменить: здесь почти четыре года спустя и Groovy стали намного более прочными.

Я могу полностью рекомендовать его для проектов производственного класса.


Я использовал Groovy для поддержки производственных приложений некоторое время, и для этого он достаточно стабилен. Что касается фактического наличия Groovy в коде добросовестного производства; Я не думаю, что я это сделаю. Groovy делает слишком много удивительных вещей. В прошлом году он стал намного лучше в этом отношении, но каждый раз через некоторое время я столкнулся с ошибкой, которую трудно отследить из-за сгенерированного кода (мои проблемы, похоже, вращаются вокруг области охвата).

Я ушел от Groovy (хотя материал, который мы используем, прост и прочен, все еще существует) и использовал Python (реализация jython), который был гораздо более предсказуемым, на мой взгляд. Кроме того, python trumps Groovy читается.

Вы можете написать очень интересный код в Groovy с закрытием и перегрузкой оператора и еще много чего.

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

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

Ответ 2

У нас есть несколько производственных приложений, работающих на Grails (используя Groovy в качестве языка). До сих пор никаких проблем не возникало. Что касается совместимости с JVM, посмотрите, как мало изменился байт-код JVM за последние 5 лет... например, была добавлена ​​1 команда, и ни одна из них не была завершена.

Появятся ли в следующем году новые версии Groovy? Да. Вам потребуется изменить их? Нет. Хотя вы, возможно, захотите, 1.6 - это огромное улучшение скорости.

Это приводит нас к основному недостатку Groovy, скорости. Очевидно, что Groovy медленнее прямой Java. Текущее количество до 10 TIMES медленнее, для определенных действий. Тем не менее, ваш процессор является узким местом в вашем приложении? Для нас это в основном доступ к БД и латентность. Если это то же самое для вас, какой бы вопрос, если процессор тратит 200 мс на обработку запроса страницы вместо 35 мс?

Это единственная проблема с Groovy? Неа. Динамические языки испытывают трудности с рефакторингом, поскольку в коде не обязательно полная спецификация класса. Однако это частично уравновешивается меньшим размером кода, что упрощает поиск мест для изменения кода.

Во всяком случае, Groovy - прекрасный язык для производственных целей. Смешайте его с Java для вашего "критического" кода, если вы боитесь надежности. Что ЛУЧШАЯ часть Groovy... как легко смешивается с Java-классами.

Ответ 3

В настоящее время я изучаю использование Groovy только для написания модульных тестов. Это имеет эффект

  • Предоставление потенциально утомительной части письменных тестов в синтаксисе, который немного проще, чем Java.
  • Сохраняет код Groovy в сборе.
  • Позволяет писать большую часть базы кода на языке, отличном от Java.

Конечно, мы еще не начали, но это, по крайней мере, мой способ попытаться ввести альтернативные языки JVM в наши новые проекты (и, возможно, существующие). У меня есть те же проблемы, что и вы, и тем более вокруг производительности, чем стабильность.

Ответ 4

Языки сценариев развиваются "слишком быстро" в аспекте синтаксических особенностей.

Если вы хотите, чтобы язык JVM оставался совместимым для много лет,
Java - ваш единственный выбор;)

Кстати, я не думаю, что читаемость кода автоматически обеспечивается языком сценариев.

Ответ 5

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

Но лично это обычно не о Groovy vs Java для меня в большинстве случаев - это о Groovy/Java + доступных библиотеках по сравнению с другими языками, такими как Python/Jython/JavaScript/Ruby + доступные библиотеки. И есть много других соображений, таких как сила сообщества, зрелость соответствующих технологий для вашего конкретного приложения и т.д. В частности, для веб-разработки Grails был порядочным, но сообщество, похоже, отсутствовало. Мое общее мнение заключается в том, что я буду использовать python или Node.js в будущем. Если бы мне нужен JVM, я бы использовал среду для разработки python, совместимую с jython.

Ответ 6

Я играю с Groovy в течение месяца или около того. Простота потрясающая, а динамические языковые функции тоже классные. Однако скорость определенно является проблемой. Кроме того, консоль Groovy действительно отстой. Вы не можете делать то, что можете сделать, например. в python. Время от времени я должен перезапустить консоль, reimport, вещи и т.д. Он также забывает значения, которые я помещаю в переменные, находясь в консольном режиме; как-то мистически они выходят за рамки. (Является ли это из-за JVM? Я не знаю.) Я не могу придумать пример из верхней части головы, но поведение, которое я получаю в консоли Groovy, отличается от поведения, которое я получаю в Grails консоль, и отличается от того, что я получаю, просто написав код в script.

Несколько предупреждений. Обратите внимание, что Groovy почти, но не на 100% совместим с Java. Например, это не скомпилируется:

public class HelloWorld {

    public static void main(String args[]) {
        System.out.println( "Hello, world!\n");
    }
}

Также посмотрите Как получить classpath в Groovy?