Почему так многие настаивают на том, чтобы перетаскивать JVM в новые приложения?

Огромным преимуществом написания кода (на любом языке) для JVM является то, что он обычно очень при необходимости легко задействовать огромное количество зрелых библиотек Java.

И я не знаю, откуда у вас идея «громоздкой» JVM с огромными накладными расходами на ресурсы. JIT имеет тенденцию создавать довольно быстрый код, а основная JVM совсем не огромна по сегодняшним стандартам. Он, как правило, требует огромного объема памяти при работе, но это потому, что современные машины имеют много оперативной памяти, а GC работает лучше всего, когда у него много оперативной памяти, с которой можно поиграть. При желании GC можно настроить до чертиков и обратно , чтобы он был более консервативным.

Как выразился кто-то другой: «Лучшее в Groovy - это то, что мне не нужно использовать Java. Вторая лучшая черта Groovy - это то, что я могу использовать Java. ".

зачем приводить вас к огромной JVM вместе с вами?

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

Тем не менее, хорошие компиляторы, нацеленные на JVM, создают хорошо работающие программы. Я не знаю о JRuby; но цель Jython - быть быстрее, чем обычный C Python, и они приближаются (это уже быстрее в нескольких важных случаях использования).

Помните, что хороший JIT (например, для JVM) может применять некоторые оптимизации недоступно на статических компиляторах Си, получение от них более быстрого кода - несбыточная мечта. Конечно, виртуальная машина, оптимизированная для вашего языка , должна быть быстрее, чем «не совсем универсальная» виртуальная машина типа JVM; но есть проблема зрелости: JVM проделали много работы, в то время как JIT для Ruby и Python не находятся рядом.

К сожалению, нет лучшего универсального байт-кода VM. CLI от Microsoft страдает от тех же ограничений, что и JVM (ironPython намного медленнее и тяжелее, чем JPython). Лучший кандидат, кажется, LLVM. Кто-нибудь знает, почему в LLVM нет более динамичных языков? Я видел пару компиляторов Scheme, но, похоже, есть несколько проблем.

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

grails war

Создает файл войны, который легко развертывается на Glassfish, Jboss и т. Д.

Groovy - это не интерпретируемый язык, это динамический язык. Groovy-компилятор создает байт-код JVM, который работает внутри JVM, как и любой другой класс Java. В этом смысле groovy похож на java, просто добавляет синтаксис к языку java, который имеет смысл только для разработчиков, а не для JVM.

Производительность, простота и гибкость синтаксиса для разработчиков делают groovy привлекательным для экосистемы java - ruby ​​или python были бы столь же привлекательны, если бы приводили к байт-коду java (см. Jython).

Java-разработчики на самом деле не боятся ruby; на самом деле, многие быстро начинают использовать groovy или jython, близкие к ruby ​​и python. То, о чем они не заботятся, оставляет такую ​​удивительную платформу (java) для менее производительного, менее масштабируемого и даже менее используемого языка, такого как ruby ​​(при всех его достоинствах).

The reason is Hotspot.

It is an engineering tour de force.

Ruby и Python могут быть оба интерпретируется практически на любой ОС, поэтому я не вижу "пиши один раз беги везде "преимущество ... зачем приносить продвигаете JVM вместе с вами?

Главным образом потому, что вы хотите воспользоваться преимуществами ОГРОМНОЙ существующей экосистемы библиотек Java, API-интерфейсов и продуктов, которая превосходит все, что доступно для Ruby или Python, особенно в корпоративной области.

Кроме того, продолжайте помните, что JRuby и Jython быстрее во многих тестах, чем обычные (реализации C) языков, особенно Ruby (даже Ruby 1.9).

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

То же самое происходит в .NET пространство, с несколькими языками , ориентированными на CLR.Проект VM Parrot (Spareware) также нацелен на то же самое, и это также заявленная цель проекта LLVM .

Предположение, которое, кажется, встроено в вопрос, состоит в том, что новые проекты - это проекты с нуля . За последние десять лет многие организации вложили огромные средства в Java и требуют, чтобы любой новый проект работал в рамках существующей (внутренней) экосистемы кода. Как уже отмечалось, существует огромный бонус во всех общедоступных библиотеках Java (будь то бесплатные / OSS или коммерческие), но необходимость работать с существующим кодом и даже в качестве компонента в существующей системе, по крайней мере, так же важна (если не больше). так) для крупных организаций.

Многое также сводится к зрелости и возможностям платформы, то есть JVM и всего, что с ней поставляется (вся экосистема Java). Несколько примеров из головы:

• Вы можете подключить удаленный отладчик к работающей JVM и получать всевозможную информацию о работающем приложении, что просто невозможно с Python, Ruby и т. Д. Если пойти еще дальше, есть JMX , стандарт способ написания кода, чтобы объекты можно было отслеживать и даже настраивать в реальном приложении. Взгляните на JConsole и посмотрите, не пускаете ли вы немного слюни (несмотря на уродство интерфейса).

• Если пойти еще дальше в этом направлении, есть OSGi , стандарт для написания высокомодульного кода, который можно развертывать, запускать, останавливать и даже обновлять в реальном приложении. С OSGi вы разбиваете большое приложение на множество небольших «пакетов», которые затем можно поддерживать (развертывать, запускать / останавливать, обновлять) отдельно. Это действительно большая проблема в больших приложениях или любых приложениях, которые должны постоянно работать.

• Платформа имеет очень хорошую хорошую поддержку для асинхронного и надежного обмена сообщениями. Вы получаете JMS в качестве базового уровня и много превосходных и мощных библиотек, построенных на нем для выполнения сложных задач с очень небольшим кодом (ср. Apache Camel , ServiceMix , Мул и многие другие). Это еще одна особенность, которая чрезвычайно полезна в более крупных приложениях или приложениях, которые должны работать в более обширной области кода.

• JVM имеет реальную (на уровне ОС) многопоточность, в то время как Python et al. очень ограничены в этом отношении (как известно, так). (Это, как говорится, параллелизм общего состояния - многопоточность - это неправильный подход; ср. Эрланг , Алиса , Моцарт / Оз и т. Д.)

• Существует множество вариантов JVM, выходящих за рамки стандартных реализаций Sun, например, JRockit , IBM JVM и т. Д. это развивающаяся область с другими языками - в Python есть Jython, Iron Python, даже PyPy и Stackless; У Руби есть JRuby, Rubinius и другие - но, как бы они ни были, они не могут соответствовать зрелости, найденной в различных предложениях JVM.

Несмотря на это, мне действительно не нравится Java язык и избегайте его в максимально возможной степени. В эти дни со всеми отличными альтернативными языками для JVM мне не нужно. Groovy получил мой голос за доступность и тесную интеграцию с платформой (и даже с языком), а также из-за Grails, которые я иногда люблю называть «Rails для взрослых». Мне больше нравятся другие языки JVM, в частности Clojure и Scala , но они не так доступны для среднего программиста. Тем не менее, в последнее время Scala часто появляется, особенно благодаря его высокопрофильному использованию в Twitter , поэтому есть надежда на интересные и по-настоящему превосходные языки, делающие его в больших средах. Но это уже другая тема.

другая причина, о которой мало кто упоминал, - это существующая инфраструктура, связанная с jvm - если у вас уже есть сервер, на котором работает java, почему бы не использовать его вместо того, чтобы вводить еще одну платформу (например, rails)?