Что ж, прошло 9 лет с момента моего последнего сообщения в блоге. В реальной жизни это был богатый событиями период: я женился, у нас двое детей, я стал гражданином Таиланда, построил дом и перенес серьезную операцию на спине.

Последние 18 месяцев я работал над дизайном нового языка программирования под названием Балерина. Версия 1.0 Ballerina только что вышла, так что сейчас хорошее время, чтобы начать объяснять, что это такое. В следующих постах я углублюсь в технические детали, но в этом посте я хочу предоставить некоторый контекст: кто и почему.

TL; DR Ballerina была разработана как ядро ​​языкового облачного подхода к корпоративной интеграции. Он исходит от WSO2, крупного поставщика корпоративной интеграции с открытым исходным кодом. Я занимаюсь дизайном и спецификацией языка. Я думаю, что у него есть потенциал, выходящий за рамки корпоративной интеграции.

Главный персонаж Балерины - Санджива Вираварана. Я знаю Сандживу примерно с 1999 года (20 лет!), Когда мы оба работали в W3C XSL WG и делали XPath и XSLT 1.0. Санджива в то время работал в IBM Research (где его начальником в какой-то момент была Шэрон Адлер, с которой я работал в комитете ISO DSSSL).

Это была эра пика XML, до изобретения JSON, и люди использовали XML для всех видов вещей, для которых он не очень хорошо подходил, включая SOAP и весь стек веб-сервисов, построенный на его основе. Санджива работал над несколькими важными частями этого, включая WSDL и BPEL.

Примерно в 2005 году Санджива решил, что хочет покинуть IBM и основать компанию с другими сотрудниками IBM. Он из Шри-Ланки и хотел вернуться. В то время я работал на правительство Таиланда. Я убедил их начать рекламную деятельность с открытым исходным кодом, и я проводил ее для них (однажды я должен написать об этом в блоге).

В День подарков 2004 года в Индийском океане произошло огромное цунами, которое стало катастрофой для нескольких стран, включая Таиланд и Шри-Ланку. В рамках процесса восстановления правительство Таиланда организовало международную ИТ-конференцию на Пхукете в начале 2005 года. Санджива приехал, чтобы поговорить о Сахане, которая была начата в Шри-Ланке, чтобы использовать открытый исходный код для помощи в восстановлении после цунами.

В кулуарах конференции Санджива предложил мне идею компании, которая в то время называлась Serendib Systems (слово serendipity происходит от Serendip, старого названия Шри-Ланки). Идея заключалась в том, чтобы сделать открытый исходный код, связанный с веб-сервисами, на Шри-Ланке. Это было на пересечении ряда моих основных интересов в то время (XML и открытый исходный код в развивающихся странах), и я был уверен в Сандживе, так что это было несложным решением инвестировать.

Название было изменено на WSO2 (WS - веб-сервисы, O2 - кислород), Санджива взял на себя роль генерального директора, а я вошел в совет директоров. WSO2 неуклонно росла за 14 лет с момента основания, и в настоящее время в ней работает около 600 сотрудников. Она осталась компанией с открытым исходным кодом и разработала комплексную корпоративную платформу интеграции с открытым исходным кодом. Возможно, вы никогда не слышали о WSO2; мы всегда были лучше в технической части, чем в маркетинговой. Но на самом деле мы являемся крупным поставщиком в области корпоративной интеграции с открытым исходным кодом с большим количеством клиентов из списка Fortune 500 по всему миру. Фактически, есть некоторый отчет Gartner, в котором говорится, что мы являемся поставщиком №1 в мире по интеграции с открытым исходным кодом, хотя я не совсем уверен, по каким показателям.

В течение некоторого времени рабочей лошадкой корпоративной интеграции была Enterprise Service Bus (ESB). ESB отправляет и принимает сетевые сообщения через множество транспортных средств, и существует язык конфигурации, обычно в XML, который описывает поток этих сообщений. Язык конфигурации можно рассматривать как DSL для интеграции. Он поддерживает такие абстракции, как посредники, конечные точки, прокси-службы и запланированные задачи, которые позволяют описывать данный поток сообщений на более высоком уровне, чем это было бы возможно, если бы эквивалентный код был написан на языке программирования, таком как Java или Go. Продукты ESB (включая WSO2) обычно включают графический интерфейс для редактирования языка конфигурации. Абстракции более высокого уровня ESB обеспечивают гораздо более полезное графическое представление, чем это было бы возможно с решением, написанным на языке программирования.

Тот факт, что ESB не является полноценным языком программирования, имеет важные последствия. Это означает, что в определенный момент вы падаете с обрыва: есть вещи, которые вы просто не можете выразить на языке конфигурации XML. ESB обычно справляются с этим, позволяя писать расширения на Java. На практике это означает, что сложные решения пишутся как комбинация конфигурации XML и расширений Java. Это создает ряд проблем. Во-первых, ESB привязан к Java. 10 лет назад это не было проблемой, но Java все чаще становится новым COBOL. Крутые ребята интересуются Go, TypeScript или Rust и даже не рассматривают Java. Управление Java со стороны Oracle не помогает. Во-вторых, расширения Java - это черный ящик в том, что касается графического интерфейса. В-третьих, наличие нескольких языков создает дополнительную сложность для многих аспектов процесса разработки программного обеспечения: сборки, развертывания, отладки. В-четвертых, это плохо с точки зрения когнитивной нагрузки, которую он возлагает на команду разработчиков: разработчикам приходится изучать два совершенно разных языка и постоянно переключаться между ними.

Другая фундаментальная проблема концепции ESB заключается в том, что она разработана для модели централизованного развертывания. Идея состоит в том, что ИТ-отдел предприятия запускает Enterprise Service Bus для всего предприятия. В этом направлении движет не только большой размер ESB, но и модель лицензирования: ESB обычно недешевы и лицензируются для каждого сервера. Если вы думаете о языке конфигурации XML как о предметно-ориентированном языке программирования, а о ESB как о среде выполнения для этого языка, вы, по сути, имеете одну большую программу, контролирующую интеграцию всего предприятия. Более того, эта программа написана не на приятном современном языке программирования с поддержкой модульности, а скорее представляет собой просто груду XML. Как вы понимаете, это плохо для гибкости или DevOps.

Это предыстория, которая привела к созданию Балерины. Цель высокого уровня - обеспечить основу для нового подхода к интеграции предприятия, который лучше подходит для текущих тенденций в области вычислений, чем ESB. Очевидно, что облако - чрезвычайно важная часть этого. Концепция Ballerina развивалась на протяжении нескольких лет. Я вижу три этапа:

  1. Давайте сделаем DSL лучше, который больше похож на язык программирования!
  2. Давайте сделаем его полноценным языком программирования!
  3. Давайте попробуем стать основным языком программирования!

Этап 2 знаменует начало проекта «Балерина», и именно тогда было выбрано название; это произошло в августе 2016 года.

Мое первое знакомство с Ballerina было в начале 2017 года, когда Санджива попросил меня помочь с разработкой языковой поддержки для XML. Но я начал серьезно увлекаться Ballerina только в феврале 2018 года. К тому моменту уже существовала работающая экспериментальная реализация. Санджива попросил меня помочь написать спецификацию языка.

Когда я начинал, мы не думали, что написание спецификации займет у меня так много времени. Мы совершенно ошибались в этом! Прошло уже 18 месяцев, а работа еще не завершена. Что произошло, так это то, что, когда мы углубились в детали языка, стало очевидно, что есть много возможностей для улучшения дизайна. Оказалось, что работа заключалась в уточнении и развитии языкового дизайна, а не просто в документировании того, что было реализовано. Когда стало ясно, что цель состояла в том, чтобы попытаться в конечном итоге стать основным языком программирования, необходимо было поднять планку качества для реализации.

Основная область знаний Санджива - распределенные системы, а коллективный опыт WSO2 сосредоточен на корпоративном промежуточном программном обеспечении, а не на разработке и реализации языков программирования. Когда они начали проект Ballerina, я думаю, что они недооценили масштабность проекта, за который они взялись, как и я в некоторой степени. По мере того, как я боролся с дизайном языка Ballerina, я гораздо лучше понял, насколько сложен дизайн языка программирования. В поисках вдохновения я посмотрел на многие другие языки программирования. Я был невероятно впечатлен тем, насколько хороши языки программирования нынешнего поколения. Я бы особо выделил TypeScript, Go, Rust и Kotlin. У каждого из них очень разная языковая концепция, но каждый из них проделал потрясающую работу по разработке языка программирования, реализующего их концепцию. Снимаю шляпу перед их дизайнерами.

Я должен кое-что сказать о том, что означает версия 1.0. Сначала я должен объяснить, что сначала мы проводим различие между версией реализации и версией спецификации. 1.0.0 - это версия реализации. Языковые характеристики указаны в хронологическом порядке (это уровень жизни!). Реализация 1.0.0 основана на спецификации языка с пометкой 2019R3, что означает 3-й выпуск 2019 года.

1.0 не означает, что у нас есть дизайн или реализация языка там, где мы этого хотим. Если бы мы жили в мире, незапятнанном коммерческой или конкурентной реальностью, мы могли бы легко потратить пару лет на расширение и улучшение дизайна и реализации. Но WSO2 - небольшая компания, и мы уже сделали очень существенные инвестиции в Ballerina (порядка 50 инженеров за 3 года). Итак, нам нужно что-то сделать, чтобы мы могли получить некоторые доказательства, оправдывающие продолжающиеся инвестиции. Ориентиром для 1.0 является то, работает ли он лучше для интеграции предприятия, чем наш текущий продукт на основе ESB. Он должен быть достаточно стабильным и производительным, чтобы мы могли поддерживать его в производстве для корпоративных клиентов.

У нас также есть разумная степень согласованности между спецификацией языка и компилятором: то, что реализует компилятор, является подмножеством того, что описывает спецификация, с несколькими оговорками. Первое предостережение заключается в том, что есть некоторые неосновные функции, которые не совсем стабильны. В спецификации они помечены как «предварительный просмотр». Мы ожидаем их стабилизации в ближайшее время, что повлечет за собой некоторые незначительные несовместимые изменения. Второе предостережение заключается в том, что в реализации есть некоторые экспериментальные особенности, которых нет в спецификации; мы планируем, что в конечном итоге язык будет включать функции, обеспечивающие аналогичные функции.

Дизайн языка, описанный в текущей спецификации, имеет две уникальные фундаментальные особенности (по крайней мере, не является частью какого-либо основного языка программирования). Комбинация других функций также уникальна: каждая функция индивидуально представлена ​​на каком-то языке, но ни один язык не имеет их всех. Я думаю, что дизайн языка интересен не только для корпоративной интеграции, но и для любого приложения, которое в основном связано с объединением сервисов, будь то их использование или предоставление. По мере перехода в облако все больше и больше приложений будут попадать в эту категорию. Хотя текущее состояние языкового дизайна интересно, я думаю, что потенциал еще более интересен. В течение следующего года или двух мы стабилизируем больше функций языка, ориентированного на интеграцию, что сделает Ballerina совершенно отличным от любого другого языка программирования. К сожалению, для создания надежных функций общего назначения требуется много работы, и это необходимо сделать до того, как будут завершены более специфичные для предметной области функции.

В целом, дизайн языка 2019R3 и реализация 1.0 - это начальный стабильный шаг, но впереди еще долгий путь.

В следующих статьях я займусь дизайном языка. А пока вы можете опробовать реализацию и прочитать спецификацию. Процесс проектирования изначально был довольно закрытым, но постепенно стал более открытым. Большая часть обсуждения спецификации происходит в проблемах в репозитории GitHub спецификации. Основные новые языковые функции имеют публичные предложения. Комментарии и предложения приветствуются; лучший способ внести свой вклад - открыть новую проблему.

Первоначально опубликовано на https://blog.jclark.com.