Erlang больше не в моде. berry-lang — новый язык для BEAM со статической типизацией

В одной из предыдущих статей я рассказывал о языке gleam и даже хвалил его. Это тоже язык для платформы BEAM, и он тоже подходит под описание, которое я сделал для berry-lang. Что ж — хочу сказать, что gleam не выдержал моего более пристального взгляда и разочаровал меня полностью.

Приведу пару примеров. Во-первых, gleam намеренно и без всякой причины ломает совместимость с эрлангом. Взять, например, атомы: gleam их не поддерживает. Однако, большая часть API эрланга их использует — получается, нет совместимости. Причём, синтаксис для атомов из эрланга — имя в одинарных кавычках — в gleam ничем не занят! Одинарные кавычки в нём просто запрещены.

То же самое — с поддержкой OTP. Автор gleam решил, что для обмена между процессами будут разрешены только типизированные сообщения, и что он для этого сделает свой API. В итоге, получилось не очень — он выделил это в отдельный репозиторий и сказал, что OTP будет опциональной частью (она недоделана и вообще странная). Как OTP может быть опциональной для эрланга — непонятно. Зато, автор добавил Javascript как второй таргет, помимо эрланга. В общем, вы понимаете, почему я разочаровался.

Ещё есть Elixir. С синтаксисом у него всё более-менее нормально. Однако, семантически он не на 100% соответствует эрлангу. Например, в нём есть макросы, потом — есть struct-ы, которые под капотом — map, причём модулю соответствует struct. Почему модулю должен соответствовать map — непонятно. Ну, то есть, понятно: видимо, сказалась тяга автора к ООП.

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

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

Но давайте поговорим, наконец, о ягодах.

Стоит ли говорить, что придумывать новый синтаксис — дело неблагодарное и, лично мне, совсем не хотелось. Я думал взять за основу синтаксис питона, сделав поправку на то, что язык должен быть функциональным. Уже искал, какой лучше взять парсер и всё остальное — ничего нормального не было. Питоновский парсер написан на си и на питоне — не очень годится. Есть парсер и линтер на Rust — но к Rust я отношусь довольно прохладно.

В этих поисках, я совершенно случайно наткнулся на Сyber — «fast, efficient, and concurrent scripting language». Написан он на zig (отличный выбор!). Сyber пока далёк от применения в продакшне, но я желаю ему стать отличным скриптовым языком.

Но будущее Сyber — это одно, а ведь нам от него нужен только синтаксис. Так вот, синтаксис у Сyber — на удивление, хорош! Очень радует, что он смог утащить из питона, так сказать, не букву закона, а его дух.

Вот как, например, выглядит цикл for:

for 0..100 each i:     print i    -- 0, 1, 2, ... , 99

Как видите, синтаксис отличается от питона. Хотя и во многом совпадает.

Для импортов и объявления функций Сyber использует синтаксис го, а не питона:

import {sqrt} 'math'  func dist(x0 int, y0 int, x1 int, y1 int) number:     dx = x0 - x1     dy = y0 - y1     return sqrt(dx^2 + dy^2)

По мне, так двоеточие между переменной и типом — чуть более читаемо. Но, для моего случая, отсутствие двоеточия — ещё лучше. Почему — увидите позже. А вот возвращаемое значение мы всё-таки будем отделять символами ->:

func sum(x int, y int) -> int:     x + y

Дело в том, что аннотации типами и другие guards могут стоять и после объявления аргументов — то есть, после скобок:

func my_list_function([head | tail]) head int -> list:

В этом примере, в скобках мы делаем паттерн-матчинг списка, поэтому все условия стоят уже за скобками. Именно поэтому нам нужен разделитель -> перед типом возвращаемого значения.

Расскажу о статической типизации. Кстати, как ни странно, её в эрланге довольно часто используют, несмотря на плохо приспособленный синтаксис (аннотация -spec). Моя версия придумана специально для эрланга: паттерн-матчинг учитывает типы, так что guards обычно писать не нужно.

Так, предыдущий пример будет соответствовать следующему:

my_list_function([Head | Tail]) when is_integer(Head) -> 

Но это ещё не всё: после типов в скобках могут стоять условия:

func my_fun(m map(size>0)):

Выражения в скобках после типа отвечают исключительно за guards. Таким образом, эта функция превратится в следующее:

my_fun(M) when is_map(M), map_size(M) > 0 ->

Guards в эрланге обычно логически привязаны к типу, и для каждого типа их немного — до 10, в лучшем случае. Указание их в скобках, мне кажется, хорошо читаемо — плюс, обеспечивает лёгкую возможность автокомплита.

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

func my_fun((name, value)) name atom, value int:

Здесь, my_fun принимает tuple, состоящий из атома и целого числа. Теперь вы видите, почему хорошо, что между переменной и её типом нет двоеточия? Потому что двоеточие стоит в конце.

Для оператора case всё-таки нужен разделитель when перед guards:

match x:     []:         none     [head | tail] when head int:         throw "Not implemented" 

Да, Сyber использует match, а не case — ну, пусть будет match.

Кастомные типы, конечно, объявлять можно и нужно. У Cyber для этого такой синтаксис:

type Student record:      -- for Erlang records     name string     age int     gpa number  type Professor map:       -- for maps     name string     age int     known_info Info

Дух «значимых пробелов» (significant whitespace) в Cyber выдержан везде. Например, в нём есть полноценные лямда-функции — которых в питоне, между прочим, нет.

Pipeline-оператора — увы, нет. Всё-таки, Cyber — не функциональный язык. Но вот, как он, теоретически, мог бы выглядеть:

filtered =     range(10)     ..filter func(val):      -- pipeline operator ..         val % 2 == 0         -- even number

Что также эквивалентно

filtered =     range(10)     ..filter(_) func(val):    -- placeholder _ is for lambda         val % 2 == 0          

Идея использовать .. в качестве пайплайн-оператора, честно говоря, навеяна синтаксисом Cyber. Две точки + имя функции — это как бы частичная функция, привязанная к предыдущему результату — мне нравится.

Для передачи лямды в качестве параметра используем placeholder _:

filtered = filter(range(10), _) func(val): val % 2 == 0

В случае, если лямда — это единственный аргумент, placeholder можно не писать:

at0 = func(f): f(0)  f0 = at0 func(x):     math.sin(x)  -- or the pipeline version: f0 =     func(x):         math.sin(x)     ..at0()

В целом — мне кажется, синтаксис получается симпатичный, а как вам? По этому вопросу можно проголосовать в опросе.

Пару слов о реализации: мне нравится zig (без иронии), но новый язык я собираюсь писать на нём самом — like a boss. Это называется self-hosted. Конечно же, ещё напишу об успехах.

Опрос, как и обещал — про синтаксис, а вот нужен ли этот язык вообще — об этом напишите в комментариях!