Комментарии (12)

1. 

   IvanPonomarev

   12.10.2018 01:17

   #19224323

   Очень круто, что ребята позвали Чарльза, для меня это был актуальный и полезный доклад.
   
   Языку 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. 

      excentro

      12.10.2018 10:58

      #19225547

      +1

      Да, жаль, что с Jython все грустно…

   
   

   1. 

      dbelob Автор

      12.10.2018 11:10

      #19225605

      Иван, спасибо за хорошие вопросы на встрече!
      
      Что ещё рассматривали, когда выбрали для Celesta Jython? Насколько трудно (и планируется ли) переехать на что-то другое, например, на JRuby?

      
      

      1. 

         IvanPonomarev

         12.10.2018 14:29

         #19226811

         +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. 

            dbelob Автор

            12.10.2018 15:59

            #19227263

            +1

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

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

            
            

            1. 

               IvanPonomarev

               12.10.2018 20:12

               #19228527

               Благодарю за столь подробный ответ

               
               Не за что, мне это всё равно скоро предстоит писать-объяснять)
               
               В 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. 

      xvilka

      12.10.2018 20:48

      #19228683

      У Python есть PyPy.

      
      

      1. 

         IvanPonomarev

         12.10.2018 20:57

         #19228749

         И есть IronPython для .NET, и вроде бы там всё гораздо лучше обстоит, чем в Jython. Но мы-то про JVM-реализации говорим…

1. 

   fzn7

   12.10.2018 17:55

   #19227941

   +1

   Я думаю стоит упомянуть, что наряду с 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. 

      maxzhurkin

      13.10.2018 13:08

      #19230733

      • Execute C extensions in a managed environment

      Как это?

1. 

   IvanPonomarev

   12.10.2018 19:52

   #19228441

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

   
   

   1. 

      fzn7

      13.10.2018 23:17

      #19232331

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