LINUX.ORG.RU

Опыт объединения Java, JavaScript, Python и Ruby с использованием GraalVM

 graalvm, , , ,


0

4

В ноябре этого года вышел более-менее стабильный LTS-релиз GraalVM 20.3.0 от Oracle и я решил с ним поэкспериментировать. Для тех кто не в курсе, GraalVM позволяет использовать в едином окружении различные популярные языки программирования и обеспечивает их разностороннее взаимодействие в рамках некоторой общей среды выполнения. Платформа GraalVM вместе с исполняемой программой на смеси самых разных языков может быть представлена в виде автономного и самодостаточного исполняемого файла, либо работать поверх OpenJDK, Node.js или даже внутри Oracle Database. Наглядная схема из официальной документации:

https://www.graalvm.org/docs/img/graalvm_architecture.png

Поддержка гостевых языков осуществляется с помощью фреймворка Truffle, на основе этой библиотеки можно даже реализовать собственный язык программирования, который получит все плюшки платформы, вроде JIT-компиляции, многостороннего взаимодействия и прочего полезного. Из коробки в дистрибутиве GraalVM сразу присутствует возможность использования:

  • Java, Kotlin, Scala и других языков JVM-платформы.
  • JavaScript вкупе с Node.js и сопутствующим инструментарием.
  • C, C++, Rust и других языков, которые могут быть скомпилированы в LLVM bitcode.

Экспериментальная поддержка заявлена для Python, Ruby, R и WebAssembly.

Собственно, хватит лирики, вот простенький прототип, использующий из экосистем JavaScript, Python и Ruby батарейки, реализующие server-side подсветку синтаксиса фрагментов исходного кода. Подобные библиотеки с богатым охватом языков программирования, которые они могут подсвечивать, отсутствуют на JVM-платформе:

// Highlighter.java, no comments, no checks.
// $ javac Highlighter.java
// $ jar -cvfe highlighter.jar Highlighter *.class
// $ cat hello.py | java -jar highlighter.jar rouge python
import org.graalvm.polyglot.Context;

import java.io.File;
import java.io.FileNotFoundException;

import java.util.Scanner;

public class Highlighter {
  private abstract class Highlight {
    protected final Context polyglot =
      Context.newBuilder("js", "python", "ruby").allowAllAccess(true).allowIO(true)
        .build();

    protected abstract String language();
    protected abstract String renderHtml(String language, String rawCode);

    protected String execute(String sourceCode) {
      try {
        return polyglot.eval(language(), sourceCode).asString();
      } catch (RuntimeException re) { re.printStackTrace(); }
      return sourceCode;
    }

    protected void importValue(String name, String value) {
      try {
        polyglot.getBindings(language()).putMember(name, value);
      } catch (RuntimeException re) { re.printStackTrace(); }
    }
  }

  private class Hjs extends Highlight {
    @Override
    protected String language() { return "js"; }

    @Override
    public String renderHtml(String language, String rawCode) {
      importValue("source", rawCode);

      String hjs = "";
      try {
        hjs = new Scanner(new File("highlight.min.js")).useDelimiter("\\A").next();
      } catch (FileNotFoundException fnfe) { fnfe.printStackTrace(); }

      final String renderLanguageSnippet =
        hjs + "\n" +
        "hljs.highlight('" + language + "', String(source)).value";
      return execute(renderLanguageSnippet);
    }
  }

  private class Rouge extends Highlight {
    @Override
    protected String language() { return "ruby"; }

    @Override
    public String renderHtml(String language, String rawCode) {
      importValue("$source", rawCode);
      final String renderLanguageSnippet =
        "require 'rouge'" + "\n" +

        "formatter = Rouge::Formatters::HTML.new" + "\n" +
        "lexer = Rouge::Lexer::find('" + language + "')" + "\n" +
        "formatter.format(lexer.lex($source.to_str))";
      return execute(renderLanguageSnippet);
    }
  }

  private class Pygments extends Highlight {
    @Override
    protected String language() { return "python"; }

    @Override
    public String renderHtml(String language, String rawCode) {
      importValue("source", rawCode);
      final String renderLanguageSnippet =
        "import site" + "\n" +
        "from pygments import highlight" + "\n" +
        "from pygments.lexers import get_lexer_by_name" + "\n" +
        "from pygments.formatters import HtmlFormatter" + "\n" +

        "formatter = HtmlFormatter(nowrap=True)" + "\n" +
        "lexer = get_lexer_by_name('" + language + "')" + "\n" +
        "highlight(source, lexer, formatter)";
      return execute(renderLanguageSnippet);
    }
  }

  public String highlight(String library, String language, String code) {
    switch (library) {
      default:
      case "hjs": return new Hjs().renderHtml(language, code);
      case "rouge": return new Rouge().renderHtml(language, code);
      case "pygments": return new Pygments().renderHtml(language, code);
    }
  }

  public static void main(String[] args) {
    Scanner scanner = new Scanner(System.in).useDelimiter("\\A");
    if (scanner.hasNext()) {
      String code = scanner.next();
      if (!code.isEmpty()) {
        System.out.println(new Highlighter().highlight(args[0], args[1], code));
      }
    }
  }
}

Как видно, тут смешаны сразу четыре разных языка программирования. Утилита принимает на вход stdin в виде текста исходного файла, передаваемые аргументы определяют используемую библиотеку для подсветки и язык фрагмента, затем подсвечивается код и выводится готовый HTML на stdout терминала.

Подсветка фрагментов кода на стороне сервера лишь простейший пример использования библиотек, которые недоступны для определённой платформы, но доступны на нескольких других. С тем же успехом можно рассматривать какую-нибудь гораздо более полезную научную батарейку, написанную на Python или R, что-нибудь из ML и т. д. Получается, что JVM-платформу со своей кучей библиотек мы можем обогатить батарейками из экосистем других языков программирования и использовать их эксклюзивные библиотеки, альтернативы которых просто недоступны на нашей платформе.

Рецепт установки GraalVM, поддержки языков и библиотек, компиляция и запуск прототипа:

curl -LOJ https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-20.3.0/graalvm-ce-java8-linux-amd64-20.3.0.tar.gz
# curl -LOJ https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-20.3.0/graalvm-ce-java11-linux-amd64-20.3.0.tar.gz
cd /opt/
sudo mkdir graalvm
sudo chown `whoami`:`whoami` graalvm
cd /opt/graalvm/
tar -xvzf ~/graalvm-ce-java8-linux-amd64-20.3.0.tar.gz
rm ~/graalvm-ce-java8-linux-amd64-20.3.0.tar.gz

export GRAALVM_HOME=/opt/graalvm/graalvm-ce-java8-20.3.0
export JAVA_HOME=$GRAALVM_HOME
export PATH=$GRAALVM_HOME/bin:$PATH

gu install python
gu install ruby
# /opt/graalvm/graalvm-ce-java8-20.3.0/jre/languages/ruby/lib/truffle/post_install_hook.sh

graalpython -m ginstall install setuptools
curl -LOJ https://github.com/pygments/pygments/archive/2.7.3.tar.gz
tar -xvzf pygments-2.7.3.tar.gz
cd pygments-2.7.3/
graalpython setup.py install --user
cd ..
rm -Rf pygments-2.7.3/ pygments-2.7.3.tar.gz

gem install rouge

curl -LOJ https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.4.1/highlight.min.js

javac Highlighter.java
jar -cvfe highlighter.jar Highlighter *.class

cat hello.py
#!/usr/bin/env python
print("Hello, World!")

cat hello.py | java -jar highlighter.jar hjs python
<span class="hljs-comment">#!/usr/bin/env python</span>
print(<span class="hljs-string">"Hello, World!"</span>)

cat hello.py | java -jar highlighter.jar rouge python
<span class="c1">#!/usr/bin/env python
</span><span class="k">print</span><span class="p">(</span><span class="s">"Hello, World!"</span><span class="p">)</span>

cat hello.py | java -jar highlighter.jar pygments python
<span class="ch">#!/usr/bin/env python</span>
<span class="nb">print</span><span class="p">(</span><span class="s2">"Hello, World!"</span><span class="p">)</span>

Благодаря поддержке AOT-компиляции в GraalVM можно даже собрать автономный нативный исполняемый файл из JAR-пакета:

sudo yum install gcc glibc-devel zlib-devel libstdc++-static

gu install native-image
# gu rebuild-images polyglot libpolyglot

native-image --language:js -jar highlighter.jar

cat Highlighter.java | ./highlighter hjs java

Вместо Java VM там будет использована легковесная и низкоуровневая Substrate VM, но с преимуществами JIT-компилятора в случае AOT придётся попрощаться. Зато запуск просто молниеносный, как у всех нативных программ. Стоит отметить, что пока у меня удалось сформировать подобный исполняемый файл лишь для связки JavaScript + Java. Создание подобных нативных образов довольно продолжительная и ресурсоёмкая операция, особенно по памяти. Для сборки примера потребовалось где-то 6 GB RAM, а в более сложных случаях требуется и целых 20 GB RAM.

Прототип постепенно оброс разной функциональностью и благодаря фреймворку Spring, который вполне себе работает на платформе GraalVM, превратился в простенький pastebin-сайт на котором можно обмениваться фрагментами исходного кода.

Все исходники и рецепты я выложил на GitHub: https://github.com/EXL/CodePolyglot
На Хабре имеется скучная и длинная статья про мои изыскания, может кому-нибудь будет интересно её почитать: https://habr.com/ru/post/534044/
Потыкать палочкой прототип в виде сайтика на GraalVM и Spring Boot можно тут: https://code.exlmoto.ru/
Примечание: не факт, что я долго буду держать сайт в онлайне, так что не рассчитывайте сохранять там что-то ценное.

Мне интересно ближайшее будущее GraalVM, похоже Oracle настроен очень серьёзно. Пока проект позиционируется им как альтернативная и идеальная платформа для микросервисов, но уже сейчас его разработка имеет влияние и на классический OpenJDK, например, в релизе JDK 15 была дропнута поддержка JavaScript-движка Nashorn, а в качестве его замены Oracle предлагает попробовать именно GraalVM. Кто знает, вдруг GraalVM в будущем будет предлагаться в качестве рекомендуемой JVM-платформы по умолчанию вместо OpenJDK? Время нам покажет.

Предлагаю обсудить эту грандиозную затею Oracle, пригодится ли кому-нибудь использовать все эти фичи GraalVM на практике? На официальном сайте платформы есть интересное заявление о том, что наша отечественная социальная сеть «Одноклассники» уже использует GraalVM в продакшене для server-side рендеринга React.js, что позволяет добиться хорошей отзывчивости на медленных интернет соединениях.

P.S. Поздравляю с наступающим Новым Годом анонимных и зарегестрированных пользователей ЛОРа. Счастья и крепкого сибирского здоровья вам, ребята!

★★★★★

Последнее исправление: EXL (всего исправлений: 4)

даже внутри Oracle Database

Звучит забавно, учитывая, что хранимки на C и Java что в Oracle, что в DB2 можно писать лет эдак 20 как минимум.

Legioner ★★★★★
()
final String renderLanguageSnippet =
        hjs + "\n" +
        "hljs.highlight('" + language + "', String(source)).value";

Вставили язык в язык, что характерно, появились новые просторы для инъекций.

Как оно там с изоляцией разных программ? Можно параллельно исполнять две программы с собственными циклами обработки событий? Как меняться данными?

похоже Oracle настроен очень серьёзно.

Олицензирует и запатентирует по самые комментарии? Как у сабжа с лицензией и сообществом?

anonymous
()
Ответ на: комментарий от Legioner

Не работал плотно с этими базами данных, ничего сказать не могу. Официальный сайт GraalVM по этой теме отсылает сюда, на некий проект Walnut:

https://labs.oracle.com/pls/apex/f?p=LABS:project_details:0:15

EXL ★★★★★
() автор топика
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от anonymous

Как у сабжа с лицензией

Всё в лучших традициях опенсорса. GraalVM Community Edition под GPL 2. Oracle GraalVM Enterprise Edition is licensed under either the GraalVM OTN License Agreement, which is free for testing, evaluation, or for developing non-production applications, or under the terms of the Oracle Master License Agreement for customers.

GraalVM Enterprise subscription includes improved performance and security over GraalVM Community.

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

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от anonymous

Вставили язык в язык, что характерно, появились новые просторы для инъекций.

Да, тоже были такие мысли. Как и насчёт новых уязвимостей. Вот прямо касательно моего примера. Если какая-нибудь батарейка подсветки синтаксиса будет как-то уязвима, то с её помощью можно будет встроить что-нибудь вроде javascript:alert(0) и т. д. Но это тогда и на оригинальной платформе будет воспроизводимо.

Ну и мои кривые руки без должного опыта Web-разработки, тут тоже играют некоторую роль. Там где я допущу возможность какой-то инъекции, более продвинутый разработчик с большим опытом создания Web-сайтов и Web-приложений сделает всё правильно и на GraalVM и на классическом OpenJDK.

Как оно там с изоляцией разных программ?

Не смотрел в эту сторону пока, ничего определённого сказать не могу.

Можно параллельно исполнять две программы с собственными циклами обработки событий?

Думаю да, на стороне Java запускать процессы Polyglot’а в двух потоках кажется никто не мешает, но не проверял. Если так рассудить, то ведь Spring в купе с Tomcat в своих внутренностях создают пул разных потоков для обработки запросов, которые в конечном итоге упираются в Polyglot-программы, значит это работает.

Как меняться данными?

Можно с помощью клея в виде Java или любого другого JVM-языка. На этой страничке показаны разные примеры interoperability в обе стороны:

https://www.graalvm.org/reference-manual/embed-languages/

Как у сабжа с лицензией и сообществом?

Вот прямо сейчас уже предлагается две редакции: бесплатная GraalVM Community под православной GPLv2 и платная GraalVM Enterprise под проприетарной лицензией, отличия между которыми описаны тут: https://www.graalvm.org/downloads/current-release/

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

Я так понял Oracle нанял весьма именитых и известных разработчиков, которые пилят реализации Ruby, Python, JavaScript/Node.js и R на основе этого Truffle-фреймворка.

EXL ★★★★★
() автор топика
Последнее исправление: EXL (всего исправлений: 4)

а может проще писать на C# и не надо будет ничего сопрягать

anonymous
()
Ответ на: комментарий от gag

Ничего про него не слышно.

А вот разработчики Perl 6, он же Raku, что-то там пилят: https://github.com/Raku/nqp/tree/truffle

Я, если честно, толком это не смотрел лишь нагуглил.

В своё время хотел увлечься изучением Perl 6, но всякие странные протуберации его разработчиков и Perl-сообщества вроде неожиданной смены названия ЯП на Raku и разработка Perl 7, похожего на старый Perl 5, меня что-то оттолкнули и весь энтузиазм иссяк. Тем более на литературе, которую я хотел использовать для изучения, гордо красовалось Perl 6, а сам язык уже назывался по-другому.

EXL ★★★★★
() автор топика
Ответ на: комментарий от X512

Из последнего, где я с ним сталкивался – скриты установки гостевых VMware Tools в монтируемом внутрь виртуалки ISO-образе. Возможно до сих пор используется там.

Ну и да, Git. Некоторые инструменты там завязаны на него немного.

EXL ★★★★★
() автор топика
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Ещё в системе сборки WebKit используется. Но это всё давно написанный код который поддерживают, новых проектов на Perl особо не видно, его везде Python заменил.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

Интересно как так получилось, что Perl растерял всю свою популярность. Ведь ещё на рубеже начала нулевых, как помню, в том же Web он держал сильные позиции. Помню раньше даже форумы были на движке UBB: https://ru.wikipedia.org/wiki/UBB, которые вместо базы данных ФС с текстовыми файлами использовали.

Из того, что ещё вспомнил на Perl и чем я пользуюсь – утилита cloc для получения sloc-статистики проектов:

cloc src/main/java/ src/main/resources/*.properties src/main/resources/static/ src/main/resources/templates/
      42 text files.
      42 unique files.
       4 files ignored.

github.com/AlDanial/cloc v 1.82  T=0.09 s (425.0 files/s, 41552.9 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Java                            29            375            771           1513
CSS                              6             17             21            792
HTML                             2              0              4            159
JavaScript                       1              4              1             58
-------------------------------------------------------------------------------
SUM:                            38            396            797           2522
-------------------------------------------------------------------------------

EXL ★★★★★
() автор топика

Б-р-р. Какая гадость. Впрочем, для Oracle типично изобретать нестандартные технологии, чтобы привязать к себе тех, кто ими будет полтзоваться. Для взаимодействия компонентов , разработанных на разных языках, и так есть микросервисы .

Partisan ★★★★★
()

наша отечественная социальная сеть «Одноклассники» уже использует GraalVM в продакшене для server-side рендеринга React.js, что позволяет добиться хорошей отзывчивости на медленных интернет соединениях

Меня выбешивает, что кто-то ориентируется на Одноклассников. У одноклассников порядка 70 млн пользователей — это не соц сеть, это детский сад. Вы представляете, что они запоют на 200 млн? На 500 млн? Они уже на 70 млн заявляют про 300 миллиардов связей между пользователями. То есть, где-то 5000 на каждого пользователя. Как можно было так криво спроектировать систему?

Далее, у дропбокса 10 млн пользователей, он работает на питоне. У инстаграма миллиард, он работает на питоне. У ютьюба 2 млрд, он работает на питоне. Фейсбук, ололо, почти 3 млрд на PHP. В это время:

«Через год у Одноклассников было свыше одного миллиона пользователей. В 2007 году это были невероятные цифры, и сайт, не выдержав нагрузки, начал падать. Разработчики решили проблему с помощью проекта One.lv, созданного латвийской компанией Forticom, у которой основные компетенции были в Java-разработке. Поэтому Одноклассники решено было переписать с .NET на Java»

Это рукожопы, и я удивляюсь тому, что они до сих пор выжили. Видать, что-то они все-таки могут выдать рабочее, по крайней мере попросить кодеров из one.lv написать серверный софт и приспособить его под свои нужды. И потом какой-нибудь Макс Дорофеев (человек, которого выгнали со всех его предудущих, пусть и престижных, мест работы, потому он перешел в тренинги и написание книжек), говорит: «к одноклассникам много кто относится несерьезно, но на самом деле это матёрый хайлоад и там сидят большие спецы».

То, что я вижу в одноклассниках — это классические эффективные менеджеры, в число который входит и Дорофеев, которые создают проблему из ничего, месяц решают ее, а потом мужественно рапортуют о решении этой проблемы, также доложив, что параллельно за этот месяц удалось мужественно разработать архитектурное решение о том, в каком порядке выводить фамилию-имя-отчество на странице польователя, и не просто «выводить», а «гармонично вписать это решение в существующую архитектуру системы».

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

Звучит вроде «приспособим технику торможения ногами, взятую из велосипедов, к новой Tesla, оборудовав онный автомобиль дырой в полу под сиденьем водителя». Многие «батарейки» питона — это тупо толстенная прокладка между языком и библиотекой на C/C++. Потому что взаимодействие с другими языками в питоне как было страшным 30 лет назад, так оно таким и осталось — передалось от поколения к поколению, так сказать. Да, есть SWIG, который позволяет генерировать прокладки, транслирующие родные типы C/C++ в родные типы питона — получается весьма странный зверь, который больше похож на запись сишной программы в синтаксисе питона, чем на питонью программу. Со всей естественной низкоуровневостью конструкций и небезопасностью такой работы.

То, что я писал за последний год много раз здесь и на хабре: питон, как язык — говно, а продолжают пользоваться им только из-за сишных батареек, которые не подлежат AOT и JIT оптимизации, потому что они изначально написаны как черные ящики, гвоздями прибитые к контейнерам питона. Делать поддержку AOT/JIT в них — значит переписывать библиотеки, пусть не с нуля, но все равно переписывать. Примерно это делают в рамках PyPy, у которого спустя все эти годы совместимость по прежнему не фонтан.

уже сейчас его разработка имеет влияние и на классический OpenJDK, например, в релизе JDK 15 была дропнута поддержка JavaScript-движка Nashorn, а в качестве его замены Oracle предлагает попробовать именно GraalVM

Но ты забыл упомянуть такое влияние на JDK, как то экспериментальная AOT-компиляция в Java 9, а также escapse analysis и прочие JIT-оптимизации в жаве оракла. Выхлоп трюфеля можно запускать и на oracle JVM, так что отказ от Nashorn не является каким-то большим событием. Реально разница между жавой оракла и граалем не такая большая, и главный образом она вызвана тем, что грааль изначально строился вокруг AOT компиляции, а JDK — вокруг JIT. Собственно, изначально это была Maxine VM, которая представляла собой модифицированный код из Hotspot.

Я бы задал другой вопрос: чего они так долго тянули? Здесь всех устраивал адово долгий запуск жавовых программ? К тому же, JNI не позволял JIT-оптимизировать вызовы, что представляло собой большую проблему для использования бинарных библиотек в жаве — это тоже всех устраивало? Можно было как минимум сделать вариант некий unsafe unmanaged bytecode, в который можно было бы компилировать бинарники для последующего выполнения с производительностью машинных кодов и при этом сохранять возможность JIT-оптимизации. Но здесь больше вопрос к архитекторам первой JVM, которые построили онную на базе классов и объектов, а не сделали машину тьюринга с динамическим выделением памяти страницами, на базе которой уже работают классы и объекты в виде расширения. Собственно, примерно такую архитиктуру и имеет Грааль VM:

https://www.researchgate.net/figure/System-structure-of-the-Graal-compiler-in...

PS: хотите настоящее высокоуровневое решение для серваков на JVM? Используйте Clojure. Там же рядышком лежит и ClojureScript.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Интересно как так получилось, что Perl растерял всю свою популярность

Регулярки и форматирование строк — это костыли, они могут быть хороши чтобы по-быстренькому что-то набросать, но после этого нужно переписывать решение правильно. А что остается от перла, когда ты, например, распарсил JSON и работаешь над объектной моделью? Как регулярки помогут работать над древовидной структурой данных? Внезапно, Perl становится самым заурядным языком, что-то уровня, PHP, только на перле нельзя написать Hello World так же просто, как на PHP/Рельсах.

форумы были на движке UBB: https://ru.wikipedia.org/wiki/UBB, которые вместо базы данных ФС с текстовыми файлами использовали

Во-во, текстовые базы данных. Когда выяснилось, что веб разросся и текстовая база не прокатывает — тогда-то перл и умер.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Меня выбешивает, что кто-то ориентируется на Одноклассников.

Я просто удивился, увидев отечественный проект у них на странице.

У ютьюба 2 млрд, он работает на питоне.

Они разве чистый Python используют? Не обмазываются транспиляторами вроде Cython или каким-нибудь Psyco?

Фейсбук, ололо, почти 3 млрд на PHP.

Они же его обмазывают всякими HPHPc и HHVM. Ванилька значит не вывозит?

Я бы задал другой вопрос: чего они так долго тянули?

Ну это же Java. Я вообще удивлён, что они начали двигаться и развиваться, когда мир так плотно застрял на Java 8.

А у постгреса серверную часть можно скриптовать на питоне, перле, и тикле. Шок, да?

GraalVM внутри Oracle DB выглядит довольно дико.

EXL ★★★★★
() автор топика
Ответ на: комментарий от byko3y

Регулярки и форматирование строк — это костыли, они могут быть хороши чтобы по-быстренькому что-то набросать, но после этого нужно переписывать решение правильно.

Но а как же лозунги по типу «ЛУЧШИЙ ЯЗЫК ДЛЯ ОБРАБОТКИ ТЕКСТА!11», почему даже в этом он проиграл?

EXL ★★★★★
() автор топика

AOT-компиляция есть в Java 11, которую взяли из GraalVM, но она работала несколько иначе, классы компилируются в нативный код, который подключается при старте JVM. В Java 16, кстати, хотят убрать AOT-компиляцию (я так понял, что, мол, хотите AOT - используйте GraalVM).

Помню, что у Spring Boot-а были проблемы с GraalVM, т. к. в Spring-е многое что завязано на рефлексию, которую GraalVM не умеет в AOT-компиляцию. Т. е. включаешь Spring AOP, и всё, наивная компиляция не работает. Надо глянуть, может уже починили.

Также можно отметить два новых перспективных framework-а https://helidon.io (от Oracle) и https://quarkus.io (от Red Hat), в которых изначально заявлена поддержка GraalVM и которые построены вокруг microprofile - изначально профиль в Java EE, переросший а самостоятельный стандарт, ориентированный на микросервисы. После них spring кажется жирным, медленным и не поворотливым, прямо как было во время spring 2 vs javaee 1.4, только они теперь поменялись ролями, ирония…

P.S.: ещё одна ирония, после кидалова Oracle с JavaEE, Oracle сертифицировала WebLogic под JakartaEE 8.0

ma1uta ★★★
()
Ответ на: комментарий от EXL

ЛУЧШИЙ ЯЗЫК ДЛЯ ОБРАБОТКИ ТЕКСТА!11

Регулярными выражениями текст обрабатывают только говнокодеры. Для правильной обработки текста надо читать синтаксическую структуру (JSON, HTML, XML, CSV).

X512 ★★★★★
()

Почуяли, что джава умирает, начали крутиться и изобретать новое нинужно.

WitcherGeralt ★★
()
Ответ на: комментарий от ma1uta

Надо глянуть, может уже починили.

Недавно вон релизнули такое:

https://spring.io/blog/2020/11/23/spring-native-for-graalvm-0-8-3-available-now

https://github.com/spring-projects-experimental/spring-graalvm-native

Я потыкал – всё ещё довольно сыро и слишком уж экспериментально. Но перечень примеров потихоньку обновляется:

https://github.com/spring-projects-experimental/spring-graalvm-native/tree/master/spring-graalvm-native-samples

У меня со SpEL затык был, видно там тоже дофига рефлексии.

P.S. Спасибо за полезную информацию.

EXL ★★★★★
() автор топика
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Они разве чистый Python используют? Не обмазываются транспиляторами вроде Cython или каким-нибудь Psyco?

Конечно же питон с расширениями на Си. Как бы весь питон на это и расчитывался. К сожалению, Cython — это мусор. Psycho стал PyPy, но JIT-компиляция в питоне работает только при условии, что весь код написан на питоне, без вызовов сишных расширений.

Они же его обмазывают всякими HPHPc и HHVM. Ванилька значит не вывозит?

Да. Но, я извиняюсь, речь идет про лярды пользователей, а не какие-то там ссаные 70 млн.

GraalVM внутри Oracle DB выглядит довольно дико

А тикль внутри постгреса — самое оно.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Но а как же лозунги по типу «ЛУЧШИЙ ЯЗЫК ДЛЯ ОБРАБОТКИ ТЕКСТА!11», почему даже в этом он проиграл?

Где в 2020 году тебе нужно обрабатывать текст? Язык регулярных выражений принципиально нерасширяем, потому по мере роста абстракций становится всё большей и большей абузой.

byko3y ★★★★
()

Как эксперимент интересно.

Но все же почему бы не делать подсветку на стороне клиента?

Midael ★★★★★
()

Какое-то эталонное «ненужно». Для связывания кода на разных языках уже давно всё что можно было придумать - придумали. А городить эти помои сверху для этой же цели какая-то - бредятина, но в «энтерпрайзе» конечно приживется, скорее всего, просто потому, что оракл предлагает, оракл дает поддержку, удобно наворачивать говно под общим соусом из блевотной вытяжки, ну и новое железо тоже надо как-то продавать.

anonymous
()
Ответ на: комментарий от byko3y

Где в 2020 году тебе нужно обрабатывать текст?

Да вот в том же Pandoc. Почему эта сверхполезная утилита написана на каком-то там Haskell’е, где наверняка многие решения и велосипеды были переизобретены заново..А «лучший язык для обработки текста» с кучей отлаженных батареек из какого-нибудь CPAN – остался в стороне.

EXL ★★★★★
() автор топика
Ответ на: комментарий от Midael

Но все же почему бы не делать подсветку на стороне клиента?

Вот LOR, например, подсвечивает на клиенте с помощью Highligh.js, а GitHub, GitLab и Bitbucket – подсвечивают на сервере. И там у них больше фич, вроде номеров строк со ссылками, выделения фрагментов, гораздо больший охват языков и т. д. Тут вопрос больше стоит в применимости, кому что удобнее – то и используют.

Со своей колокольни могу сказать, что в каких-нибудь технических статьях, где огромная куча фрагментов кода, клиентская подсветка работает не очень. По-крайней мере вот эта штука https://github.com/aramk/crayon-syntax-highlighter на WordPress’е меня раздражает. Мало того что подсвечивает некорректно многое, так ещё и тормозит. А Highligh.js простенький и в нём нет, например, номеров строк вообще. Нельзя переносы включить/отключить и т. д.

EXL ★★★★★
() автор топика

TruffleRuby уже год как вполне себе почти production ready.

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

Не знаю откуда такая любовь джавистов растёт, может из-за объектной модели.

OSBuster
()

Как видно, тут смешаны сразу четыре разных языка программирования.

просто ради интереса, можно хоть один реальный пример, где необходимо смешивать разные языки внутри VM еще и в одном файле?
я понимаю смешивание на уровне ОС, когда что-то удобно выносить из VM ради нативного доступа, но зачем смешивать внутри VM, если в итоге она выполнит разный код плюс-минус одинаково? сколько человечество не билось над попыткой продемонстрировать реальные профиты от, например F# над C# в скорости выполнения, ВМ всегда нивелировала результаты в реальных условиях

rukez ★★★★
()
Ответ на: комментарий от rukez

просто ради интереса, можно хоть один реальный пример, где необходимо смешивать разные языки внутри VM еще и в одном файле?

Зачем запускать много разных ВМ и пытаться их связать если можно запустить одну?

MOPKOBKA ★★★★★
()
Ответ на: комментарий от EXL

Да вот в том же Pandoc. Почему эта сверхполезная утилита написана на каком-то там Haskell’е, где наверняка многие решения и велосипеды были переизобретены заново..А «лучший язык для обработки текста» с кучей отлаженных батареек из какого-нибудь CPAN – остался в стороне

Haskell — это язык для написания трансляторов. Самый большой проект, созданный на хаскеле — это сам транслятор хаскеля, GHC. А Pandoc — второй. То есть, превращение одной неизменяемой структуры в другую. Я здесь подчеркиваю, что не просто текста, а некой осмысленной структуры, и чем сложнее эта структура, чем сложнее превращения — тем больше хаскель оправдывает вложенные в его разработку силы. Хотя, на самом деле есть лисп и ML, которые с этйо функции справляются не хуже, при этом не вынося мозг писаке.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Со своей колокольни могу сказать, что в каких-нибудь технических статьях, где огромная куча фрагментов кода, клиентская подсветка работает не очень. По-крайней мере вот эта штука https://github.com/aramk/crayon-syntax-highlighter на WordPress’е меня раздражает. Мало того что подсвечивает некорректно многое, так ещё и тормозит. А Highligh.js простенький и в нём нет, например, номеров строк вообще. Нельзя переносы включить/отключить и т. д

Нет ни одной причины, почему подсветка синтаксиса на стороне клиента должна так криво работать. Так происходит только потому, что highlight.js — кривая школьная поделка. Можно на JS написать штуку, которая будет подхватывать неподсвеченный текст и разукрашивать его. Таким образом пользователь увидит неподсвеченный текст при отключенном JS и просто при загрузке страницы, а уже после этого синтаксические элементы будут отмечены. Так делает тот же Atom. Можно подсветку обрабатывать вообще в worker-е, и тогда основной поток не будет тормозить. Но никто забесплатно, судя по всему, такой либы писать не будет.

byko3y ★★★★
()
Ответ на: комментарий от MOPKOBKA

А когда он сможет плюсы распарсить?

Парсеры есть, например: https://github.com/examachine/drakon

Другое дело, что C++ — это абсолютный рекордсмен по сложности парсинга, потому реализовать парсер, который бы полностью поддерживал язык, очень сложно. А вот частично — всегда пожалста.

byko3y ★★★★
()
Ответ на: комментарий от MOPKOBKA

Зачем запускать много разных ВМ и пытаться их связать если можно запустить одну?

тебе не надо запускать разные ВМ даже в обычной JDK - она принимает любые .class написанные на любом поддерживаемом языке внутри одного инстанса

просто логика грааля не понятна - интероп явы со скалой и котлином есть в ждк, интероп с жс был в nashorn но он оказался настолько ненужным (что логично - жс по логике должна выполняться в другом месте и один фиг эти два места надо связывать по сети) что им никто не пользуется.
или все эти телодвижения ради того что бы запихать в JVM питон и руби? и вправду, без них же никак не живётся (нет) :-)

rukez ★★★★
()
Ответ на: комментарий от rukez

Зачем запускать много разных ВМ и пытаться их связать если можно запустить одну?

тебе не надо запускать разные ВМ даже в обычной JDK - она принимает любые .class написанные на любом поддерживаемом языке внутри одного инстанса

Так трюфель это и делает. Другое дело, что это ВМ в ВМ.

byko3y ★★★★
()
Ответ на: комментарий от rukez

интероп с жс был в nashorn но он оказался настолько ненужным (что логично - жс по логике должна выполняться в другом месте и один фиг эти два места надо связывать по сети) что им никто не пользуется.

нееет. nashorn он для server-side scripting, те стандартно скриптануть кусок бинарной софтины.

невзлетел тк:

It provides a 100% support of ECMAScript 5.1.

никому не нужно это говно в 2020+.

нет ли бенчей насколько js в graal тормознее ноды?

drsm ★★
()
Ответ на: комментарий от drsm

нееет. nashorn он для server-side scripting, те стандартно скриптануть кусок бинарной софтины.

nashorn это просто замена rhino, он не имеет никакого отношения к бинарным софтинам

невзлетел тк:

не нужен
ровно как и любой другой включатель жс в яву
ибо нет ровно ни одиного повода использовать калечный жс, если доступна полная жвм

rukez ★★★★
()
Ответ на: комментарий от rukez

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

ну да, если в приложении нужен scripting (логика задаваемая пользоваелем в виде кода), будем тащить какой-то свой нестандатный интерпретатор говна.

drsm ★★
()
Ответ на: комментарий от drsm

ну да, если в приложении нужен scripting (логика задаваемая пользоваелем в виде кода), будем тащить какой-то свой нестандатный интерпретатор говна

Implying «JS является стандартным интерпретатором говна».

byko3y ★★★★
()
Ответ на: комментарий от drsm

ну да, если в приложении нужен scripting (логика задаваемая пользоваелем в виде кода), будем тащить какой-то свой нестандатный интерпретатор говна.

В старых jvm ты мог скомпилировать код на лету, начиная с 9ки это делается прямо в процессе jvm ;-)

rukez ★★★★
()
Ответ на: комментарий от rukez

В старых jvm ты мог скомпилировать код на лету, начиная с 9ки это делается прямо в процессе jvm ;-)

cglib ?

так то байткод, не java код, или в jvm уже жабий компилятор встроили? :)

drsm ★★
()
Ответ на: комментарий от drsm

так то байткод, не java код, или в jvm уже жабий компилятор встроили? :)

А ты не знал? :-)
Ещё в 6ке был Java Compiler API по jsr 199 и ты мог при исполнении программы скомпилировать что угодно
В 9ке есть полный jshell

rukez ★★★★
()
Ответ на: комментарий от rukez

На самом деле Nashorn нужен и широко используется в узких областях для добавления скриптовых возможностей в программу на Java. В частности (чтоя сам применял):

  • веб-скрипты в платформе Alfresco (важная в своей области фиговина). Могут быть на JavaScript, Java или на том и другом. Еслм на JavaScript , то не надо перезагружать приложение при их изменении. Фактически в Alfresco заимствованы из Spring.

  • функции в генераторах отчётов.

  • шаги выполнения процессов в process engine-ах (например Activiti) и ETL (например, Pentaho).

Всё это хорошие и важные программные средства и JavaScript в них полезен.

Partisan ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.