Чарльз Наттер о динамических языках в JVM на jug.msk.ru

    На очередной встрече московского сообщества Java-разработчиков jug.msk.ru, прошедшей 4 октября 2018 года, Чарльз Наттер рассказал о технологиях, используемых JRuby и другими динамическими языками для JVM.



    О докладчике


    Чарльз является одним из двух ключевых разработчиков проекта JRuby. Активнейший участник конференций в качестве докладчика, в том числе неоднократно принимал участие в конференциях JUG.ru Group.

    Некоторые из его докладов в хронологическом порядке:

    Ещё ссылки: твиттер, технический блог, GitHub, YouTube-канал.

    О докладе


    Текущее посещение Чарльзом Москвы было связано с участием его в конференции RubyRussia (см. интервью с ним на Хабре). Усилия, которые приложил Андрей Когунь, позволили участникам jug.msk.ru встретиться с Чарльзом.

    Андрей открывает встречу. Рукопожатие с докладчиком, ставшее уже традиционным.



    В первой половине встречи Чарльз рассказал о сегодняшнем состоянии динамических языков в JVM: сравнении статических и динамических языков, месте JRuby среди различных языков программирования, характеристике свойств JRuby, результатах тестов, будущем динамических языков.



    Во второй половине была практическая демонстрация примеров, иллюстрирующих ранее показанную презентацию.



    Весьма интересные вопросы от слушателей задавались и по ходу выступления, и в перерыве, и после встречи: о востребованности продукта и количестве разработчиков JRuby, сравнении по производительности реализаций языка Ruby, разумности и особенностях перехода на JRuby с Jython (от IvanPonomarev) и прочее, прочее. Вопросы понравились как аудитории, так и Чарльзу.



    С презентацией доклада можна ознакомиться здесь (на SpeakerDeck создана учётная запись jugmsk, на которой появится архив предыдущих встреч и будут выкладываться презентации будущих).

    Фотографии скоро появятся здесь. Видео будет доступно на YouTube (с анонсом в VK и Google+). Имеется возможность подписаться на рассылку с анонсами следующих встреч jug.msk.ru.

    JUG.ru Group

    1 363,16

    Конференции для взрослых. Java, .NET, JS и др. 18+

    Поделиться публикацией
    Комментарии 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», и потому там легко наколбасить «эзотерический» код )
        +1
        Да, жаль, что с Jython все грустно…
          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
            У Python есть PyPy.
              +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
                +1
                • Execute C extensions in a managed environment
                Как это?
                +2
                Есть и такое, Чарльз как раз упоминал:

                image

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

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

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

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

                Самое читаемое