Здравствуйте, дорогие читатели! Сегодня я расскажу вам о проекте hornbeam, который переводится на русский язык как “граб” – это такое дерево, похожее на дуб. Он позволяет деплоить сервисы на питоне, используя для этого виртуальную машину эрланга, BEAM (!) А также, позволяет удобно запускать код на питоне, если вы уже используете Erlang или Elixir.
Фреймворк, на мой взгляд – полностью в духе эпохи, в которой доминируют питон, дата-саенс, машинное обучение и LLM, и в которой в программирование продолжают проникать полупрофессиональные инструменты из среды дата-саентистов и других энтузиастов – к счастью. Дошло уже до того, что инструменты и практики с почти безупречной репутацией, такие как kubernetes и контейнеризация, уступают место крайне любительскому подходу вроде “для инфраструктуры используйте эрланг”.
Проект задумал и осуществил автор широко известного веб-сервера gunicorn, он адресован широкому сообществу программистов на питоне и эрланге.

Скажу хочу сказать – лично мне этот фреймворк нравится, так что я с удовольствием буду его использовать для проектов на питоне – если, конечно, разрешат. Непонятно, конечно, чем можно будет аргументировать необходимость тащить этот “дуб” в проект, да ещё вместе с эрлангом. Извините, что отклоняюсь от темы, но я вспомнил, как в “Мастере и Маргарите” кот-бегемот решил превзойти меткий выстрел Азазелло и потребовал не один, а сразу два револьвера:

Если что, я об этом вспомнил, потому что тут нам тоже нужны сразу два языка – питон и эрланг. Но, в сторону лирику. Несмотря на экзотику, hornbeam следует существующим стандартам для питоновских сервисов – WSGI и ASGI. То, что внутри у него эрланг – это всего лишь особенность реализации.
Как я уже говорил, важная часть целевой аудитории – приложения в дата-саенс и ML. В этом случае, имеет смысл использовать в питоне блокирующий ввод-вывод и ограниченное число воркеров. И здесь, hornbeam предлагает максимально современный подход, позволяя использовать subinterpreters, GIL-less сборку и всё остальное, что позволяет жить без GIL (или почти без него). Именно поэтому он требует минимум версию 3.12, а ещё лучше 3.14. Это одна из основных фич, и она будет развиваться одновременно с питоном.
Вообще, чтобы получить представление о фичах, можно на главном сайте долистать до “See It In Action”:

Как видите, первая вкладка – “ML Caching”. Действительно, одна из фич – “встроенный” кэш, замена Redis. Как думаете, это достаточно для того, чтобы люди стали этим пользоваться?)
Есть плюшки и для поклонников асинхронного программирования: например, в hornbeam есть свой собственный event loop – его можно использовать вместо встроенного в asyncio:
import asyncio
import erlang
loop = erlang.new_event_loop()
asyncio.set_event_loop(loop)
Реализованы классы транспорта, протокола и прочего, что нужно для соединений по TCP или UDP. Из высокоуровневых фич для веб-разработки – есть поддержка вебсокетов и всяческого реалтайма из коробки – может пригодиться.
Плюшки – это хорошо, но у вас, наверное, возникает вопрос, что, всё-таки, там делает эрланг и какова его роль. Ответ – масштабирование путём объединения серверов в кластер. Дело в том, что эрланг поддерживает кластерный режим – Distributed Erlang. В этом режиме, несмотря на то, что процессы распределены по разным хостам (узлам), для разработчика мало что меняется, по сравнению с одним хостом. Это такой дешёвый способ объединить вычислительные узлы в кластер, о котором мало кто знает – запустить на них эрланг. Другое дело, что сам эрланг плохо подходит для вычислений – для этого в нём используют Ports, Dirty NIFs и другие ухищрения. Теперь вы понимаете, для чего нужен питон? Вычисления как раз можно запускать внутри него.
Таким образом, эрланг нужен для масштабирования, но это не главная его функция! Главная – это психологическая: ну и что, что у нас обычный WSGI сервер, зато рядом – целый эрланг! С ним мы столько всего сможем сделать – когда-нибудь в будущем. Что, всё равно не очень убедительно? Ну что ж, как говорила Масяня – это авангард, в это так сразу не въедешь.
Автор: abetkin


