Блог компании JUG.ru Group
Java
Ruby
Комментарии 13
+1
Очень круто, что ребята позвали Чарльза, для меня это был актуальный и полезный доклад.

Языку Ruby, конечно, здорово повезло, что в него зашёл такой человек, как Чарльз — и теперь есть JRuby. Который, оказывается, не просто «ещё одна» имплементация языка, а по многим параметрам лучшая имплементация языка, важный игрок в экосистеме Ruby, подпитывающий экосистему со своей стороны.

К сожалению, такого не произошло с Python. Когда несколько лет назад мы начинали использовать Jython, это был ещё живой проект, сейчас же его развитие слишком медленное, а проблемы накапливаются как снежный ком. При том что у стратегически у проекта Jython были все шансы оказаться успешнее, чем JRuby — в силу популярности и востребованности языка Python в наше время. Ставка, в своё время сделанная нами на Jython, надо это признать, проиграла. Выбери мы Groovy или JRuby — результат был бы лучше.

C JRuby я вижу только одну проблему. Ruby мне не очень нравится как язык — он наследник Perl с его «there's more than one way to do it», и потому там легко наколбасить «эзотерический» код )
0
Иван, спасибо за хорошие вопросы на встрече!

Что ещё рассматривали, когда выбрали для Celesta Jython? Насколько трудно (и планируется ли) переехать на что-то другое, например, на JRuby?
+2
Я смотрел и на Groovy, и на JRuby. Но тогда Jython казался лучшим выбором: перспективный язык Python, живой (тогда) проект, легко встроить в Java-приложение. В итоге через несколько лет мы получили: 1) отставание от спецификации языка 2) с большинством библиотек из pip либо несовместимость, либо просадка по производительности 3) баги в самой имплементации языка. Жить, однако, можно. По утверждениям Чарльза, всех этих проблем в JRuby нет. Как оно обстоит на самом деле — это надо слушать независимые свидетельства :-)

Касательно же Celesta — новости близко!!! :-) На одном из наших проектов мы используем ветку версии 7.x. Сейчас мы доведём до ума эту ветку, доработаем тесты, обновим документацию и тогда я где-нибудь напишу пост. Если вкратце, произошло вот что:

1) вовсе убрали из Celesta зависимость от Jython,

2) кодогенерируем классы курсоров на чистой Java, а не на Python,

3) сделали spring-boot-starter и в целом теперь основной сценарий использования Celesta 7.x — это бэкенд на спрингбуте, всё это должно стать гораздо интереснее Java-разработчикам,

4) инвертировали контроль — теперь не Celesta вызывает процедуры, а из процедур используется Celesta как сервис. Т.е. это значит, что Celesta становится возможно использовать из любого JVM языка. На практике — мы уже сейчас пишем на Celesta в чистой Java. Я, возможно, для статьи сделаю демо-пример на Groovy.

Увы и ах, всё это — дорогой ценой того, что вся написанная на Jython-е кодовая база перестала быть совместимой. Но надо двигаться дальше с новыми проектами. Jython-ориентированную ветку 6.x и все Jython-проекты мы будем поддерживать ещё долго.
+1
1) вовсе убрали из Celesta зависимость от Jython,

4) инвертировали контроль — теперь не Celesta вызывает процедуры, а из процедур используется Celesta как сервис. Т.е. это значит, что Celesta становится возможно использовать из любого JVM языка. На практике — мы уже сейчас пишем на Celesta в чистой Java.

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

Использование JRuby в подобном качестве уже неактуально по причине архитектурных изменений?
+1
Благодарю за столь подробный ответ

Не за что, мне это всё равно скоро предстоит писать-объяснять)

В Celesta 6.x в папке score лежат CelestaSQL-скрипты + Python-код + кодогенерированные на Python классы доступа. Python-код запускается через celesta.runPython("proc.name"...). Необходим внешний сервис, который выполняет метод runPython (чаще всего Flute).

В Celesta 7.x в папке score челесту интересуют исключительно SQL-ники. Классы доступа кодогенерируются на Java (например, с помощью celesta-maven-plugin). Точка входа на уровне сервисных классов выглядит так:

@Service
public class HelloService {
    @CelestaTransaction
    public String hello(CallContext cc) {
        ....
    }
}


В этом случае HelloService может запускаться из контроллера, например

@Autowired
HelloService srv;

@GetMapping(value = "/{name}")
public String hello(@PathVariable String name) {
    CallContext cc = new CallContext(name);
    return srv.hello(cc);
}

И тут уже не важно, на чём написан контроллер и сервис. Может на Java, может на Groovy. Может, на Kotlin. А может — почему нет? — на JRuby или всё том же Jython. В последних двух случаях надо с интеграцией повозюкаться, но в целом не вижу проблемы. Интересное свойство JRuby паковаться в .jar/.war тут может помочь.
+1
И есть IronPython для .NET, и вроде бы там всё гораздо лучше обстоит, чем в Jython. Но мы-то про JVM-реализации говорим…
+2
jRuby в проде врагу не пожелаю. Оно тормозное и кривое. Трэды полностью поломаны и неюзабельны; евал строчек, приходящих из явы, из всего многообразия способов делать евал руби — без косяков не пашет ни один. Циферки тормозят дичайше.
Неужели Jython еще хуже?
+3
Я думаю стоит упомянуть, что наряду с JRuby существует проект TruffleRuby под GraalVM github.com/oracle/truffleruby

TruffleRuby aims to:
  • Run idiomatic Ruby code faster
  • Run Ruby code in parallel
  • Boot Ruby applications in less time
  • Execute C extensions in a managed environment
  • Add fast and low-overhead interoperability with languages like Java, JavaScript, Python and R
  • Provide new tooling such as debuggers and monitoring
  • All while maintaining very high compatibility with the standard implementation of Ruby
+2
Есть и такое, Чарльз как раз упоминал:

image

Касательно C-extensions — у JRuby, естественно, нет прямой совместимости с ними. Но, со слов Чарльза, это не большая беда, т. к. всего несколько процентов Ruby-библиотек их используют, а для самых важных Ruby-библиотек, зависящих от C (например, парсер XML) написаны «Java-заменители».

Всё это — со слов самого Чарльза, конечно. Но говорил он убедительно
+1

Увы, но Java 8 уже сильно устарела, поэтому трюфель в перспективе заменит jruby. На пришествие этого момента работает уже в первую очередь Ruby комьюнити, возлагающее большие надежды на базовую платформу от Оракл, против самодурства ребят из mri

Только полноправные пользователи могут оставлять комментарии. , пожалуйста.