Есть ли преимущество для запуска JRuby, если вы не знаете Java?

Ответ 1

Я думаю, вы довольно много прибили его.

JRuby - это еще один механизм выполнения Ruby, как и MRI, YARV, IronRuby, Rubinius, MacRuby, MagLev, SmallRuby, Ruby.NET, XRuby, RubyGoLightly, tinyrb, HotRuby, BlueRuby, Red Sun и все остальные.

Основные отличия:

• переносимость: например, YARV официально поддерживается только на x86 32-разрядной Linux. Он не поддерживается в OSX или Windows или 64 Bit Linux. Rubinius работает только на Unix, а не на Windows. JRuby OTOH работает везде: настольные компьютеры, серверы, телефоны, App Engine, вы называете это. Он работает на Oracle JDK, OpenJDK, IBM J9, Apple SoyLatte, RedHat IcedTea и JRockit JVM (и, возможно, на пару других, о которых я забыл), а также на Dalvik VM. Он работает под управлением Windows, Linux, OSX, Solaris, нескольких BSD, других проприетарных и открытых Unices, OpenVMS и нескольких мейнфреймов, Android и Google App Engine. Фактически, в Windows JRuby проходит больше тестов RubySpec, чем сам "Ruby" (что означает MRI или YARV)!

• расширяемость: Ruby-программы, запущенные на JRuby, могут использовать любую произвольную библиотеку Java. Через JRuby-FFI они могут также использовать любую произвольную библиотеку C. И с новой поддержкой расширения C в JRuby 1.6 они могут даже использовать большой подмножество расширений MRI и YARV C, например, Mongrel. (И обратите внимание, что библиотека "Java" или "C" на самом деле не означает, что написана на этих языках, это означает только с помощью Java или C API. Они могут быть записаны в Scala или Clojure или С++ или Haskell.)

• : когда кто-то пишет новый инструмент для YARV или MRI (например, memprof), оказывается, что у JRuby уже 5 лет назад был инструмент, который делает то же самое, только лучше. В экосистеме Java есть одни из лучших инструментов для "понимания поведения во время выполнения" (это термин, который я только что составил, под которым я подразумеваю гораздо больше, чем просто профилирование). Я имею в виду инструменты для глубокого понимания того, что именно делает ваша программа во время выполнения, каковы его эксплуатационные характеристики, где узкие места, где происходит память, и, самое главное, почему все это происходит) и визуализация, доступная на рынке, и почти все из них работают с JRuby, по крайней мере в некоторой степени.

• развертывание: предполагается, что ваша целевая система уже установлена ​​JVM, развертывание приложения JRuby (и я не просто говорю о Rails, я также имею в виду настольные, мобильные и другие серверы) буквально просто копирует один JAR (или WAR) и двойной щелчок.

• производительность: JRuby имеет гораздо более высокие накладные расходы на запуск. В свою очередь, вы получаете гораздо большую пропускную способность. На практике это означает, что развертывание приложения Rails для JRuby является хорошей идеей, так как выполняется тестирование интеграции, но для тестов и скриптов для разработчиков, MRI, YARV или Rubinius - лучший выбор. Обратите внимание, что многие разработчики Rails просто разрабатывают и unit test на MRI и тестируют интеграцию и развертывают на JRuby. Нет необходимости выбирать один механизм выполнения для всего.

• concurrency: JRuby запускает потоки Ruby одновременно. Это означает две вещи: если ваша блокировка правильная, ваша программа будет работать быстрее, и если ваша блокировка будет неправильной, ваша программа сломается. (К сожалению, ни MRI, ни YARV, ни Rubinius не запускают потоки одновременно, так что там все еще есть сломанный многопоточный Ruby-код, который не знает, что он сломан, потому что, очевидно, ошибки concurrency могут отображаться только в том случае, если существует фактический concurrency.)

• (это несколько связано с переносимостью): есть некоторые удивительные платформы Java, например. Azul JCA с 768 гигабайтами оперативной памяти и 864 ядрами процессоров, специально разработанными для безопасного хранения, ориентированного на указатели, сборщика мусора, объектно-ориентированных языков. Android. Google App Engine. Все из них запускают JRuby.

Ответ 2

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

Вы должны попробовать параметр Rails.threadsafe! с помощью одной среды выполнения JRuby (например, драгоценный камень Trinidad с опцией --threadsafe). Мы слышали несколько историй, где он дает вам отличную производительность и низкое использование памяти, одновременно используя несколько ядер процессора с одним процессом.

Ответ 3

JRuby - одна из немногих реализаций, которая использует собственные потоки. Поэтому, если вы хотите сделать многопоточность, пойдите для этого.

Что касается хостинга, вы должны разместить свое приложение в каком-то контейнере java, который мне лично кажется гораздо менее простым, чем использование чего-то вроде пассажира (для приложений Rack).

Я использую JRuby для приложения, когда мы обмениваемся JMS, и он отлично работает, но если бы я не использовал какую-либо Java, я бы определенно придерживался CRuby. Моя самая большая говядина - это то, что при тестировании тесты на выполнение навсегда остаются с JRuby, поскольку вы должны разворачивать виртуальную машину каждый раз, когда вы их запускаете. Это делает его намного сложнее для TDD, поскольку это значительный удар по времени тестирования.

Ответ 4

У Jruby есть преимущества, если вы работаете в Windows. Он поддерживает 64 бита, и вы можете использовать множество запатентованных баз данных со стандартными драйверами JDBC.

Ответ 5

Последние выпуски значительно быстрее, чем Ruby, но также используют значительно большую память. Если это единственная причина для использования JRuby, я бы не стал беспокоиться, если у вас есть определенная потребность в производительности, которую она решает, просто потому, что, хотя она довольно популярна, она менее стандартная для хостинга и меньше людей используют ее по сравнению со стандартными Рубин. Тем не менее, есть много других причин для использования JRuby, таких как необходимость взаимодействия с существующим Java-кодом и необходимость развертывания в средах, где Java был "благословлен" операционным отделом, а Ruby не имеет.