Грааль и Трюфель (Graal & Truffle)

https://blog.plan99.net/graal-truffle-134d8f28fb69
  • Перевод
Малоизвестный исследовательский проект, который может значительно ускорить инновации в проектировании языков программирования

От переводчика


Хочу сразу предупредить, что статья местами напоминает презентацию крупной компании из-за эпитетов в духе «изменит индустрию», «лучший на рынке», «прорывные технологии» и др. Если закрыть глаза на такой эмоциональный стиль повествования, то получится интересная вводная статья про новинки технологий компиляторов и виртуальных машин.


Введение


Со времён расцвета компьютерной индустрии многие были увлечены квестом в поисках идеального языка программирования. Квест очень сложный: создание нового языка — задача не из лёгких. И очень часто в процессе происходит дробление сложившейся экосистемы программирования и возникает необходимость заново строить базовые инструменты для нового языка: компилятор, отладчик, HTTP стек, IDE, библиотеки и бесконечное число базовых блоков пишутся с нуля для каждого нового языка. Совершенство в дизайне языков программирования недостижимо, и новые идеи возникают постоянно. Мы похожи на Сизифа: приговоренного богами на вечное толкание камня в гору, чтобы в итоге увидеть, как тот скатывается вниз снова и снова … целую вечность.


Как можно разорвать этот порочный цикл? Давайте помечтаем, чего бы нам хотелось.


Нам нужно нечто, специальный инструмент, который позволит сделать следующее:


  1. Способ создать новый язык всего за неделю
  2. И чтобы он автоматически работал так же быстро, как другие языки
  3. Чтобы у него была поддержка качественного отладчика, автоматически (в идеале без замедления работы программы)
  4. Поддержка профилирования, автоматически
  5. Наличие качественного сборщика мусора, автоматически … но только, если он нам понадобится
  6. Чтобы язык мог использовать весь существующий код, независимо от того, на чём он был написан
  7. Чтобы язык поддерживал любой стиль программирования от низкоуровневого C или FORTRAN до Java, Haskell и полностью динамических скриптовых языков, таких как Python и Ruby.
    Чтобы поддерживал just-in-time и ahead-of-time компиляцию
  8. И наконец, чтобы поддерживалась горячая замена кода (hotswap) в уже работающей программе.

А ещё, мы, конечно, хотим иметь открытый исходный код этого волшебного инструмента. И пусть там будут пони. Вроде бы всё.


Умный читатель конечно же догадался, что я не стал бы начинать эту статью, если бы у меня не было такого инструмента. Зовут его немного странно — Graal & Truffle. И пусть название скорее подходит к претенциозному хипстерскому ресторану, по сути это значительный исследовательский проект, в котором участвуют более 40 учёных из IT индустрии и университетов. Вместе они строят новые технологии компиляторов и виртуальных машин, которые реализуют все пункты из нашего списка.


Они изобрели новый способ быстрого создания языков программирования без проблем с библиотеками, оптимизирующими компиляторами, отладчиками, профилировщиками, привязки к C библиотекам и остальными атрибутами, которые необходимы современному языку программирования. Этот инструмент обещает вызвать волну новых инноваций в языках программирования и — я надеюсь — переформатирует всю IT индустрию.


Вот об этом и поговорим.


Что такое Graal и Truffle?


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


При создании нового языка программирования первый делом определяется грамматика. Грамматика — это описание синтаксических правил вашего языка. Используя грамматику и инструмент наподобие ANTLR вы получите парсер. На выходе парсера вы будете иметь дерево парсинга



На картинке изображено дерево, которое получено после работы ANTLR для следующей строчки кода:



Abishek AND (country = India OR City = BLR) LOGIN 404 | show name

Дерево парсинга и производная из неё конструкция под названием абстрактное синтаксическое дерево (AST) — это естественный способ выражения программ. После построения такого дерева останется один простой шаг до работающей программы. Вам нужно будет добавить метод «execute» в класс узла дерева. Каждый узел при выполнении «execute» может вызывать дочерние узлы и комбинировать полученные результаты для получения значения выражения или выполнения инструкции. И, в принципе, это всё!


Возьмём для примера динамические языки программирования, такие как Python, JavaScript, PHP и Ruby. Для этих языков их динамизм стал результатом движения по пути наименьшего сопротивления. Если вы создаёте язык с нуля, то усложнение языка статической системой типов или оптимизирующим компилятором может сильно замедлить разработку языка. Последствия такого выбора выливаются в низкой производительности. Но что ещё хуже, возникает соблазн быстро добавлять фичи в простой/медленный интерпретатор AST. Ведь оптимизировать производительность этих фич впоследствии будет очень сложно.


Truffle — это фремворк для написания интерпретаторов с использованием аннотаций и небольшого количество дополнительного кода. Truffle в паре с Graal позволит конвертировать такие интерпретаторы в JIT компилирующие виртуальные машины (VM) … автоматически. Полученная среда исполнения в моменты пиковой производительности может соревноваться с лучшими существующими компиляторами (настроенными вручную и заточенными под конкретный язык). Например полученная таким образом реализация языка JavaScript под названием TruffleJS может тягаться с V8 в тестах производительности.


Движок RubyTruffle быстрее чем все остальные реализации Ruby. Движок TruffleC примерно соревнуется с GCC. Уже существуют реализации некоторых языков (разной степени готовности) с использованием Truffle:


  • JavaScript
  • Python 3
  • Ruby
  • LLVM bitcode — позволяет запускать программы на C/C++/Objective-C/Swift
  • Ещё движок для интерпретирования исходного кода на C без компиляции его в LLVM (о преимуществах такого подхода читайте ниже)
  • R
  • Smalltalk
  • Lua
  • Множество маленьких экспериментальных языков

Чтобы вам стало понятно, насколько просто создавать эти движки, исходные код TruffleJS занимает всего около 80 000 строк, по сравнению с 1.7 миллионами строк кода в V8.


К чёрту подробности, как мне поиграться со всем этим?


Graal и Truffle — результат работы Oracle Labs, части Java команды, работающей над исследованиями в области виртуальных машин. GraalVM лежит здесь. Это расширенный Java Development Kit, который содержит в себе некоторые языки из указанного выше списка, а также заменители консольных утилит NodeJS, Ruby и R. В поставку также входит учебный язык программирования «SimpleLanguage», с которого можно начать знакомство с Graal и Truffle.


Для чего нужен Graal?


Если Truffle — это фреймворк для создания AST интерпретаторов, то Graal — это штука для ускорения таких интерпретаторов. Graal — это произведение искусства в области оптимизирующих компиляторов. Он поддерживает следующие фичи:


  • Может запускаться в режимах just-in-time и ahead-of-time
  • Очень продвинутые оптимизации, включающие partial escape analysis. Escape analysis позволяет избежать аллокации объектов в куче, если это по сути не нужно. Популярность EA обязана развитию JVM, но эта оптимизация очень сложная, и поддерживается малым количество виртуальных машин. JavaScript компилятор «Turbofan», используемый в браузере Chrome, начал получать escape analysis оптимизации только в конце 2015 года. В то время, как у Graal есть продвинутые оптимизации для более широкого спектра случаев.
  • Работает в связке с языками на основе Truffle и позволяет конвертировать Truffle AST в оптимизированный нативный код благодаря частичному вычислению. Частичное вычисление специализированного интерпретатора называется «первая проекция Футамуры» («first Futamura projection»). [Насколько Я понял из Википедии, первая проекция Футамуры позволяет подгонять интерпретатор под исходный код. То есть, если в коде не используются некоторые фичи языка, то эти фичи “выпиливаются” из интерпретатора. А затем интерпретатор «превращается» в компилятор, генерирующий нативный код. Поправьте, если Я напутал.]
  • Содержит расширенные инструменты визуализации, позволяющие изучать промежуточное представление компилятора на каждом этапе оптимизаций.
  • Написан на Java. А значит его гораздо проще изучать и экспериментировать, чем традиционные компиляторы, написанные на C или C++.
  • Начиная с Java 9, Graal можно использовать как JVM плагин.


Визуализация IGV

С самого начала Graal проектировался как мультиязыковой компилятор. Но его оптимизации особенно хорошо подходят для языков высокого уровня абстракции и динамизма. Java программы работают в этой виртуальной машине так же, как в существующих JVM компиляторах. В то время, как Scala программы работают приблизительно на 20% быстрее. Ruby программы получают прирост 400% по сравнению с лучшей на сегодняшний день реализацией (и это не MRI).


Polyglot


Ещё не устали? А ведь это только начало.


Truffle содержит специальный фреймворк для межъязыкового взаимодействия под названием «Polyglot». Он позволяет Truffle-языкам вызывать друг к друга. А ещё есть Truffle Object Storage Model, которая стандартизирует и оптимизирует большую часть поведения объектов в динамически типизированных языках. А заодно позволяет делиться такими объектами. Не забывайте, что Graal и Truffle построены на технологии Java и могут общаться с JVM языками, такими как Java, Scala и даже Kotlin. Причем это общение двустороннее: Graal-Truffle код может вызывать Java библиотеки, а Java код — вызывать Graal-Truffle библиотеки.


Polyglot работает очень необычным способом. Как вы помните, Truffle представляет из себя фреймворк для описания узлов абстрактного синтаксического дерева (AST). В результате обращение к другим языкам происходит не через дополнительный слой абстракций и обёрток, а путём слияния двух AST деревьев в одно. В результате полученное синтаксическое дерево компилируется (и оптимизируется) внутри Graal как единое целое. А значит любые сложности, которые могут появится на стыке двух языков программирования, могут быть проанализированы и упрощены.


По этой причине исследователи решили реализовать интерпретатор C через Truffle. Обычно мы воспринимает C как компилируемый язык. Но реальных причин для этого нет. История знает случаи, когда интерпретатор C использовался в реальных программах. Например видеоредактор Shake special effect давал пользователям возможность писать скрипты на C.


Из-за известных проблем с производительность скриптовых языков, критические участки программ часто переписывают на C с использованием внутренних API интерпретатора. В итоге, такой подход заметно усложняет задачу ускорения языка, ведь помимо самого интерпретатора необходимо запускать расширения на C. Задача глобальной оптимизации усложняется из-за того, что эти расширения опираются на допущения о внутренней реализации языка.


Когда авторы RubyTruffle столкнулись с этой проблемой, они пришли к изящному решению: давайте напишем специальный интерпретатор C, который будет не только понимать простой C, но также макросы и другие конструкции, специфичные для Ruby расширений. Тогда после слияния интерпретаторов Ruby и C через Truffle получится единый код, а издержки межъязыкового общения будут нивелированы оптимизатором. В результате получился TriffleC.


Можете почитать прекрасное объяснение как всё это работает в статье одного из исследователей этого проекта Криса Ситона (Chris Seaton). Или можете изучить научную статью с подробным описанием.


Давайте сделаем безопасное управление памятью в C


Программы на C работают быстро. Но есть обратная сторона медали — их очень любят хакеры, потому что слишком просто выстрелить себе в ногу во время работы с памятью.


Язык ManagedC появился как продолжение TruffleC и заменяет стандартное управление памятью на контролируемые аллокации со сборщиком мусора. ManagedC поддерживает арифметику указателей и другие низкоуровневые конструкции, при этом избегая кучи ошибок. Цена надёжности — 15% проседание производительности по сравнению с GCC, а также активное использование «неопределённого поведения», которое так любят многие компиляторы C. Это значит, что если ваша программа работает с GCC, это не гарантирует, что она запустится под ManagedC. При этом сам ManagedC полностью реализует стандарт C99.


Вы можете почерпнуть больше сведений из статьи «Memory safe execution of C on a Java VM».


Отладка и профилирование на халяву


Все разработчики языков программирования сталкиваются с проблемой нехватки качественных инструментов. Возьмём для примера GoLang. Экосистема GoLang уже много лет страдает от плохих, примитивных и плохо портируемых отладчика и профилировщика.


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


И тут приходит на помощь Truffle, который предлагает простой API, позволяющий встроить продвинутый отладчик в интерпретатор … без замедления программы. Компилятор всё также применяет оптимизации, а состояние программы при отладке остаётся таким, как того ожидает программист. Всё благодаря метаданным, которые генерируют Graal и Truffle в процессе компиляции в нативный код. Полученные метаданные затем используются для деоптимизации участков запущенной программы, чтобы получить исходное состояние интерпретатора. При использовании точки остановки (breakpoint), точки наблюдения (watchpoint), точки профилирования (profiling point) или другого отладочного механизма виртуальная машина откатывает программу к её медленной форме, добавляет в AST ноды для реализации нужного функционала и перекомпилирует всё обратно в нативный код, который подменяется на лету.


Конечно отладчик это не только фича среды исполнения. Нужен ещё UI для пользователей. Поэтому есть плагин для NetBeans IDE с поддержкой любого Truffle языка.


За подробностями отправляю вас к статье «Building debuggers and other tools: we can have it all».


Поддержка LLVM


Truffle в основном используется для создания интерпретаторов исходного кода. Но ничто не мешает использовать этот фреймворк для других целей. Проект Sulong — это Truffle интерпретатор для байткода LLVM.


Проект Sulong пока находится на ранней стадии разработки и содержит ряд ограничений. Но теоретически запуск байткода с помощью Graal и Truffle позволит работать не только с C, но также C++, Objective-C, FORTRAN, Swift и возможно даже Rust.


Sulong также содержит простой C API для взаимодействия с другими Truffle языками через Polyglot. Опять же, благодаря независимости от языка программирования и полностью динамичной природе данного API, полученный код будет агрессивно оптимизирован, а накладные расходы будут сведены к минимуму.


Горячая замена (HotSwap)


Горячая замена — это возможность подменить программный код в процессе его работы без перезапуска. Это одно из главных преимуществ динамических языков программирования, позволяющее добиться высокой производительности программистов. Есть научная статья посвящённая реализации горячей замены в фреймвороке Truffle (не уверен, что поддержка уже добавлена в сам Truffle). Как и с отладчиком, профилировщиком и оптимизаторами, разработчикам языков на Truffle нужно будут просто использовать новые API для поддержки горячей замены. Этот API гораздо удобнее чем собственные велосипеды.


Где подвох?


Как известно, в жизни нет ничего идеального. Graal и Truffle предлагают решение для почти всех наших хотелок из первоначального списка. Разработчики языков программирования должны быть просто счастливы. Но есть цена такому удобству:


  • Время прогрева
  • Потребление памяти

Процесс конвертации интерпретатора в оптимизированный нативный код требует изучения того, как программа работает в реальных условиях. Это, конечно, не новость. Термин «прогрев» (т.е. ускорение по мере работы) известен всем, кто использует современные виртуальные машины, такие как HotSpot или V8. Но Graal и здесь двигает прогресс, выводя оптимизации на основе профилирование на более высокий уровень. В итоге GraalVM очень сильно зависит от профилировочной информации.


Именно по этой причине исследователи замеряют только пиковую производительность, то есть дают программе поработать некоторое время. При этом не учитывается время, необходимое на такой прогрев. Для серверных приложений это не представляет большой проблемы, так как в этой области важна лишь пиковая производительность. Но в других приложениях долгий прогрев может поставить крест на использовании Graal. На практике такую картину можно увидеть при работе с тестом производительности Octane (вы можете найти его в техническом превью JDK): итоговый балл немного меньше чем у Chrome, даже с учётом довольно долгого прогрева Graal (15-60 секунд), который не учитывается в итоговой оценке.


Вторая проблема: потребление памяти. Если программа сильно зависит от спекулятивных оптимизаций, ей необходимо хранить таблицы с метаинформацией компилятора для деоптимизации — обратного преобразования из состояния машины к абстрактному интерпретатору. И занимает эта метаинформация столько же места, сколько итоговый код, даже с учетом всех уплотнений и сжатий. Не забывайте, что нужно хранить исходное AST или байткод на случай нарушения эвристических предположений в нативном коде. Всё это нещадно загромождает RAM.


Добавьте к этому тот факт, что Graal, Truffle и языки на основе Truffle сами написаны на Java. А значит компилятору тоже нужно время на свой прогрев, чтобы работать в полную силу. И конечно же потребление памяти для базовых структур данных будет расти, и эти базовые структуры компилятора попадают под сборку мусора.


Люди, стоящие за Graal и Truffle, конечно в курсе этих проблем и уже обдумывают пути решения. Одно из них называется SubstrateVM. Это виртуальная машина целиком написанная на Java и скомпилированная заранее (ahead-of-time) используя соответствующий компилятор Graal и Truffle. Функционально SubstrateVM не такая продвинутая как HotSpot: она не может динамически подгружать код из интернета, и сборщик мусора у неё довольно простой. Но проделав компиляцию этой виртуальной машины один раз можно сильно сэкономить на времени прогрева в будущем.


И ещё одна тонкость, о которой нельзя умолчать. В нашем первоначальном списке хотелок есть пункт об открытости исходного кода. Graal и Trulle — это крупные и очень дорогие проекты, написанные опытными людьми. Поэтому их разработка не может быть дешёвой. На сегодняшний день только некоторые части из описанного распространяются с открытыми исходниками.


Весь код можно найти на GitHub или других зеркалах:


  • Graal & Truffle.
  • Расширяемая версия HotSpot (основа проекта).
  • RubyTruffle
  • Sulong (поддержка LLVM bitcode)
  • Реализации R, Python 3 и Lua (некоторые из них созданы как хобби/исследовательские проекты).

А следующие части не относятся к OpenSource


  • TruffleC/ManagedC
  • TruffleJS/NodeJS API
  • SubstrateVM
  • Поддержка AOT

TruffleJS можно бесплатно скачать в составе GraalVM preview release. Я не знаю, как можно поиграться с TruffleC или ManagedC. Проект Sulong покрывается часть этой функциональности.


Что почитать


Каноничный, полномасштабный, всё-в-одном туториал по всему Graal и Truffle в этом докладе: «One VM to rule them all, one VM to bind them». Он идёт три часа, я вас предупредил. Только для настоящих энтузиастов.


Есть ещё туториалы по использованию Truffle:



Что дальше?


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


Если вы попробуете новые идеи, предлагаемые в Graal и Truffle, то откроете для себя возможность реально работать с собственным языком с первых дней его существования. Как результат, возникнет растущее сообщество участников, которые смогут развернуть ваш язык в своих проектах. Это породит магический цикл: сообщество оставляет свои отзывы и идеи, вы внедряете улучшения. В целом это ускорит путь от экспериментов до конечного внедрения. Это как раз то, что я ожидаю.

Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 31
  • +4

    Просто JVM дзен высших порядков какой-то. Огромное спасибо за статью.


    А насколько это вот всё годится для продакшена? Или строго только для экспериментов?

    • +2
      Судя по тому, что Oracle не спешит всё это рекламировать и презентовать на Java конференциях, значит ещё не готово.
      • +7

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


        Но, блин, ощущение нереальной фантастичности такое, что сложно просто взять и поверить. Хочется попробовать. Но ведь потом опять на работу, где этого всего нет и приходится выкручиваться. И получится как будто посмотрел очень хороший сон, и снова проснулся в серой реальности.


        Иногда сложно браться за слишком хорошие вещи из боязни, что либо разочаруешься, либо расстанешься. Увы...

        • +2
          Я в сентябре общался с Томасом Вертингером, который командует Граалем. Он сказал, что начиная с 2017ого они займутся продвижением проекта более активно. В частности, Томас обещает приехать в октябре в Питер с докладами на Joker.
      • +4
        FastR является стандартным интерпретатором для R в spark

        >> Начиная с Java 9, Graal можно использовать как JVM плагин.

        первичная идея была предоставить интерфейс JIT для поддержки сторонних реализаций
        http://openjdk.java.net/jeps/243

        Но есть сборки jvmci и для java 8, так что при желании можно гонять уже сейчас

        >> А следующие части не относятся к OpenSource
        >> Поддержка AOT

        но тут пошли поезда от Марка Райнхольда и случился http://openjdk.java.net/jeps/295
        в итоге core часть от graal уже войдет и в кодовую базу java 9
        • 0

          А тут доклад на эту тему: https://www.youtube.com/watch?v=hRepfVJZvhY


          Про AOT, в смысле.

          • 0
            видел =) за самим граалем уже давно посматриваю, хотя сейчас они планы чуть урезали, чтобы выйти сразу хоть с чем-то в прод, а уже потом добивать фичами

            последнее время в этой части движение активное началось, помимо грааля зашевелились ibm
            http://www.eclipse.org/omr/

            по осени дополнительно и свою версию jit открыли, в перспективе рассчитывают целиком свою версию jvm выложить и дальше двигаться по принципу Oracle «есть открытая версия, а есть наша сертифицированная с поддержкой, разница минимальная». http://openj9.mybluemix.net/

            в
        • 0

          А исходников нет?

          • +1
            Немножко есть, но не все части сделаны OpenSource:
            • Graal — https://github.com/graalvm/graal-core
            • Truffle — https://github.com/graalvm/truffle
            • RubyTruffle — https://github.com/graalvm/rubytruffle
            • Sulong — https://github.com/graalvm/sulong
            • FastR — https://github.com/graalvm/fastr
          • 0

            Скорость развития IT по прежнему велика и не исключено, что предлагаемый инструментарий спустя всего десятилетие, после своей доработки до промнадёжности, займёт прочные позиции неписанного стандарта в работе с многоязыковыми унаследованными проектами (что то вроде инструментария для работы с покрытым мхом кодом Кобола) — прямо сейчас выкладываются инструменты для принципиально нового, квантового программирования, для вхождения в которое придётся многое оставить в прошлом.

            • +4
              От оракла хорошего ждать не приходится, исходники они может и остальные откроют, но патенты оставят и потом будут давить конкурентов, как это с джавой происходит.
              • 0
                А что с java не так? Чем Oracle давит конкурентов java | jvm?

                Или Вы про Dalvik VM, которая позиционируется как jvm и собирает сливки популярности java, но при этом не является полноценной jvm? Так это путь, по которому когда-то M$ со своей java реализацией шли, java, которая работала бы только в экосистеме windows, а тут java, которая работает только в экосистеме Android.

                По-моему, это довольно правильный ход, мешать развиваться продуктам, которые ради маркетинга называют себя jvm. Программы написанные под jvm должны иметь возможность запускаться на любой реализации. И если Oracle будет позволять всем подряд называть себя jvm, то от этой платформы очень быстро ничего не останется. Одни выпустят jvm только под виндовс, другие — только под андроид, и в итоге получим какой-то .NET в плане кросплатформенности.
                • 0
                  На мой взгляд никакого давления тоже не существует, более того, на днях прочитал, что IBM собирается открыть исходники своей J9. То-то я смотрю, их совсем задавили, конкурентов. Если посчитать честные реализации JVM — то наверное вполне живых штук 10 наберется.

                  Что до Далвик, то это действительно не совсем нормальная JVM, но по-моему, претензии Оракла к Гуглю были все же не совсем поэтому.
                  • –2
                    Джава это несвободная технология, достаточно вспомнить суд оракла с гуглом или вот это.
                    • +1
                      Java — свободная технология, более того, исходники (OpenJDK) доступны для скачивания.

                      А вот Oracle JDK — это микс из свободной java и проприетарных разработок Oracle, таких как Mission Control и прочих, для включения которых необходимо прописать флаг: -XX:+UnlockCommercialFeatures, который как бы намекает, что будет использоваться проприетарные фичи, за которые нужно платить.

                      К тому же Oracle JDK выставляет счет за embedded устройства с java на борту (по большей части — это мобильные и смартфоны, но есть и GPS и многие другие), вот из-за этого то и судились Оракл с Гуглом, в теории, за каждый девайс с Android можно было бы получить минимум по 200$, согласитесь — неплохая такая сумма была бы.

                      Вброс, что Oracle закручивает гайки я видел, но это на 99% вброс с испорченным телефоном. Какой-то крупной компании выставили счет за то, что она нарушила лицензионное соглашение, а эта компания прикинулась дураком, мол скачалось бесплатно — значит оно бесплатно! А дальше подхватили малообразованные люди или просто хейтеры и начали распространять, будто Oracle будет выставлять счета вообще всем. Бред :)
                      Вот половина СНГ использует ворованную лицензию Windows уже лет 20 как и ворованные лицензии фотошопов. Но к ним не приходят потому, что с них взять нечего, а если бы это была большая компания с именем и большим оборотом денег — к ним бы пришли за тем, чтобы вернуть украденное.
                      • 0
                        > Java — свободная технология, более того, исходники (OpenJDK) доступны для скачивания.

                        похоже вы не различаете открытость исходников и свободу
                        • 0
                          Похоже, для начала стоит определить термин «свободная технология», чтобы дальше можно было хоть что-то говорить. А то GNU/Linux тоже можно назвать не свободной технологией.

                          OpenJDK — распространяется под лицензией GPLv2 (есть нюансы, но большая часть под этой лицензией). С одной стороны это свободная лицензия, с другой — нет.
                          • 0
                            Видимо в этих нюансах и дело, раз оракл может подавать в суд на гугл
                            • 0
                              ещё раз:
                              1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все в индустрии, так как процесс был знаковый)
                              2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах и лицензии)

                              по второму подробней:
                              взять код под GPL лицензией и сказать, что теперь это apache лицензия и дальше вы если хотите, то сорцы закрывайте (а апач это позволяет) нельзя по условиям gpl, так как это нарушение, именно за это по второму пункту и были претензии.

                              Причем gpl => apache не относится конкретно к java, за это можно на любой gpl продукт попасть в суд, но никто же не говорит что gpl несвободная лицензия. Вернее говорят apache и bsd, что gpl недостаточно свободная, но каждый понимает свободу по своему.
                              • 0
                                Не понимаю что вы хотите сказать, что толку от открытости кода есть есть интеллектуальная собственность на какие-то его элементы без которых его не применишь?
                                • 0
                                  Вот поэтому за судом и следила вся индустрия, так как если бы судья сказал что «api действительно является ИС», то тогда бы попали все, нельзя было бы сделать ни одну стороннюю реализацию любого api, даже моки уже попадали бы под нарушение. Но судья попался грамотным и сказал обратное, поэтому все спят спокойно. Можно и реализовывать и применять.

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

                                  Назовите пример открытых технологий, а то куда не посмотришь, то везде оказываются ограничения:
                                  — ms за патенты в linux судиться,
                                  — MPEG-LA за кодеки с гуглом (хотя тот считает что vp8-vp9 свободные кодеки),
                                  — Yahoo! показывал что у него есть патенты на идею адблоков,
                                  — про .net не говорю даже, там вообще все на «мы код открыли и обещаем за патенты не судить, честное слово» (почему тогда не открыли под нормальной лицензией, а то верить на слово ещё то удовольствие)

                                  Поэтому и хотелось бы получить:
                                  1) пример ОТКРЫТОЙ технологии
                                  2) критерии открытости (свободно копировать, использовать, продавать изменения не показывая их)
                                  • 0
                                    1. Мы говорим о языках программирования, естественно доказать не могу, но ни разу не слышал о каких-либо патентах препятствующих использованию какого-либо ЯП кроме джавы и дотнета. Соответственно в качестве примеров могу привести Python, Haskell, Erlang/Elixir.
                                    2. Критерии свободы меня устроят классические и вроде под эти критерии целые дистрибутивы подпадают, не то что отдельные технологии.
                                    • 0
                                      1. мы говорим о следующих пунктах:
                                      а) интеллектуальная собственность (я тут полностью согласен с решением суда, вопрос по API возник бы рано или поздно, зато сейчас прецедент есть)
                                      б) авторские права на код (не на сам язык, сам язык для разработки чего-либо никто не запрещал, копировать со сменой лицензии и вырезанием авторских прав есть запрет). Это если бы вы попытались использовать рантайм для Python/Lua от http://www.activestate.com/ и перетянули в свой «my-super-python-lua» дистрибутив стандартные библиотеки от них, а потом жаловались что вас за Python/Lua судят.

                                      2. сам код openjdk под GPLv2, как и ядро linux, разрабатывай-открывай, либо не открывай, но тогда используй внутри не распространяя никому (хватает закрытых кастомных сборок jdk со специфическими патчами и никто никого не судит). GPL не означает «что хочу, то и делаю».
                      • 0
                        то есть если есть сторонний продукт, который занимается раскидыванием jdk по машинкам в домене, но он платный хоть и можно скачать бесплатно, то это делает сразу же java несвободное технологией?

                        так под эту тему любое можно подвести:
                        1) .net несвободная технология, так как для нормальной работы если я скачаю нелицензионный windows мне ms счета выставит
                        2) js несвободная технология, так как за использование пиратского IE с windows для запуска ms опять счета выставит
                        3) sql несвободная технология, так как за его использование на oracle/db2/mssql некоторые компании счета выставляют
                        4) etc. можно продолжать аналогии до бесконечности

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

                        основные вопросы к Google были по 2 пунктам:
                        1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все индустрии)
                        2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах)
                        • 0
                          вы очень упрощаете.
                    • +1
                      А функциональные и логические языки на этой платформе есть?
                      Как с поддержкой статической типизации?
                      Сложно ли организовать взаимодействие кода на разных языках?
                      • 0
                        А каким образом платформа разработки компилятора может помешать статической типизации? Когда у вас есть AST, вы можете сделать на нем любой статический вывод типов, какой вам только захочется. Какой-то универсальной поддержки на уровне Truffle я бы ожидать не стал бы — хотя бы потому, что какого-то общепринятого универсального метода вывода типов вроде как и не существует. Скажем, Хиндли-Милнер таким не является.

                        Что до первого вопроса — то вроде нет. По-моему, то что в статье перечислено — это и есть полный список поддерживаемых на сегодня языков. Но это не более чем личное впечатление. В списке экспериментальных есть например Лисп, как минимум.

                        Ну и что до взаимодействия — авторы фреймворка что могли сделали. Но для сильно разных языков проблемы при взаимодействии все равно можно ожидать — хотя бы потому, что не для всех сущностей одного языка у вас не всегда будут хоть сколько нибудь похожие сущности в другом.
                      • 0
                        Тоже пишу статью по Граалю на Хабр.
                        Теперь введение будет выглядить, как будто я скопипастил его отсюда. Эх :-(

                        В любом случае, хорошая работа!
                        • 0
                          Спасибо! Всё равно пишите. Моя статья — это просто перевод чужих слов.
                        • –4
                          Прямо скажу — статья попахивает жалким, пеароподобным лохотроном. Очень много воды о том, как всё будет радужно, но слишком мало инфы по сути — из-за чего конкретно будет всё круто??
                          Скользкое начало уже наводит уныние:

                          Давайте помечтаем, чего бы нам хотелось.

                          Способ создать новый язык всего за неделю


                          Глупые, детские хотелки. Язык — это очень серьёзный проект, такое не пилится школотой во время каникул! Мне смешно смотреть на «взрослых дядь», которые преподносят свои имперские амбиции через такие вот подростковые мечты.

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


                          А что мешает-то?? У десятков языков вполне себе удобные отладчики, значит это ни бог весть какие цели — обычная рутина.

                          Наличие качественного сборщика мусора, автоматически … но только, если он нам понадобится


                          Началось… то у них есть GC, то «если понадобится»… Мальчики, сделайте уже уроки и не пишите в тырнеты! GC — это не мечта и не требование, это вынужденный механизм для работы «автоматической памяти». Так что требовать GC — глупо, требовать надо «удобную работу с памятью».

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


                          Ясно. В третьем классе детям рассказали про ЯП.

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


                          :))) Это уже вообще ни в какие рамки! Отгоните Петросяна от клавиатуры, мы уже не можем больше ржать!

                          Чтобы поддерживал just-in-time и ahead-of-time компиляцию


                          Да зачем?? Причём тут вообще «язык» и все эти дебри из мира виртуальных машин? Кто вообще сказал, что нам нужна VM?!!!

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


                          Бред сивой кобылы. Таких «задач» — две на мильён, с какого перепугу нам в языке это нужно??

                          А ещё, мы, конечно, хотим иметь открытый исходный код этого волшебного инструмента.


                          Да нифига не хотим! Много из вас «накоммитило» в гитхабы? Единицы по десятку строк. Так зачем вам исходники, в которых вы всё равно ни черта не понимаете??
                          ===================
                          Да уж… повидал я разных Болгеносов и «Петриков от ИТ», но таких клоунов вижу впервые! Теперь понятно, чем могут заниматься «40 учёных из IT индустрии» — рисовать в небе пони и насиловать JVM в жалких попытках реванша перед .NET; Даже не буду желать успехов этим распильщикам — пусть уже загнутся и пойдут в таксисты.
                          • +2
                            Глупые, детские хотелки. Язык — это очень серьёзный проект, такое не пилится школотой во время каникул!

                            Это да, вот только помимо языка (парсер, семантический анализатор, библиотеки, дизайн), ещё есть рантайм, а это тоже куча человеко-лет. Причём, ещё непонятно, что из указанного требует больше времени на разработку. Скажем, написать хороший оптимизатор, хороший JIT, хороший GC — та ещё задача.


                            Ясно. В третьем классе детям рассказали про ЯП.

                            Исходный тезис немного громкий, но давайте не кидаться какашками. Просто есть платформа JVM, для неё можно писать языки (и люди пишут), и действительно, эти языки прекрасно работают с существующим кодом, написанным на Java.


                            Да зачем?? Причём тут вообще «язык» и все эти дебри из мира виртуальных машин? Кто вообще сказал, что нам нужна VM?!!!

                            Какие такие дебри. JIT и AOT — это всего лишь про рантайм. C++ обычно реализуется в виде AOT-компиляторов, Java — JIT, но может быть и наоборот (те же Excelsior JET — пример Java, компилирующейся AOT). И вообще, понятие VM — это достаточно расплывчатая штука. Вот есть какой-то IR у компилятора. Можно ли интерпретатор этого IR назвать VM? А AOT-компилятор в нативный код? А JIT? Что такое LLVM (у которого две последние буквы VM)? Таки VM или компиляторный бэкэнд? Почему GCC не содержит в себе буковки VM, хотя на деле он очень похож на LLVM?


                            Бред сивой кобылы. Таких «задач» — две на мильён, с какого перепугу нам в языке это нужно??

                            В языке это не нужно. Это нужно в рантайме. А нужно это с целью добиться лучшей производительности кода, написанного на языке. За счёт hot swap можно прямо во время исполнения собрать профиль и на основе профиля скомпилировать код более эффективно и заменить старую версию на новую.


                            Да нифига не хотим! Много из вас «накоммитило» в гитхабы? Единицы по десятку строк. Так зачем вам исходники, в которых вы всё равно ни черта не понимаете??

                            Это на уровне энтузиастов так. А на уровне компаний может быть иначе. Компании может стать интересен какой-то opensource-проект, и она может специально людей набрать, которые будут сидеть на з/п и в этот проект контрибьютить. Со всякими Linux и JVM примерно так дела и обстоят.


                            рисовать в небе пони и насиловать JVM в жалких попытках реванша перед .NET;

                            Это какой такой реванш перед .NET? Как бы мы живём в мире, где .NET всё ещё не убил Java, и вроде бы не собирается убивать. Наоборот, судя по объявлениям о работе у Java дела намного лучше идут. Если кто и убьёт Java (вместе с .NET в придачу), то какой-нибудь JavaScript, но мы же будем верить в лучшее, и понадеемся, что этого не произойдёт?

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