На этих выходных я написал статью о том, что хочу сделать новый язык для BEAM со статической типизацией. И получил объёмный фидбэк - большая часть его содержалась, как обычно, между строк. Теперь хочу вам представить издание 2е, полностью переработанное.

Новый план состоит в том, чтобы использовать синтаксис Elixir как он есть (да!) Ну, разве что, типы в него добавить. Также, нужно сделать соответствие модулей и физических файлов 1:1.

UPDATE: berry будет поддерживать макросы, но только импортируемые. use поддерживаться не будет.

import Ecto, macros: [from]

Таким образом, фанатам Ecto беспокоиться не о чём. Вы хотите спросить, не хочу ли я поделиться этой идеей с более широким сообществом? Я уже сделал это! А вот, какая была реакция - об этом читайте под катом.

Привет! Сегодня хочу поделиться идеей нового языка для платформы BEAM: читатели хабра всё должны узнавать из первых рук! Планируется, что он будет транслироваться в эрланг source-to-source, и семантически будет тоже максимально совместим с эрлангом.

berry-lang поддерживает статическую типизацию, однако типы в нём - не главное. Главное - это приятный синтаксис, о чём свидетельствует его ягодное название. Кстати, о названии: помимо того, что оно созвучно слову Erlang, у него есть и другая подоплёка.

Дело в том, что berry-lang крадёт весь свой синтаксис у языка Сyber (слышали о таком?) Получается - кибер-тема. А чем заняты в кибер-городе? Выращиванием ягод, конечно! Скриншот - из последней Матрицы, на нём генерал Найоби угощает Нео клубникой и говорит, не без гордости - "Zion could have never made something like this!".

Статья содержит много коротких примеров с кодом! Будет интересна всем поклонникам языка эрланг и платформы BEAM. А если о языке Сyber ничего не слышали, то вообще - must-see.

Вы когда‑нибудь замечали, что pattern matching и Dependency Injection чем‑то похожи? Я — да. Вообще, pattern matching, характерный для функциональных языков, матчит значения только по структуре и содержимому. Вызовы функций не разрешаются. Я подумал — что, если разрешить вызовы функций? В этом случае, мы получим нечто близкое к Dependency Injection.

MiddleAges(status, lifespan) = hipster

Вот так можно попробовать сматчить хипстера, отправив его в средневековье — чтобы узнать социальный статус, который он там займёт, а также его время жизни там. MiddleAges — это некоторая функция. Можно оставить слева только status или только lifespan, хотя, конечно, всем любопытно узнать и то, и другое. Похоже ведь на Dependency Injection?

В этой статье я попытался представить себе, как бы мог выглядеть функциональный язык, основанный на таких конструкциях. Спойлер: в нём есть оператор pop.

gleam - это новый язык со статической типизацией для платформы BEAM (Erlang). Уверен, что Вас он тоже заинтересует - в том случае, если Вы эрлангист, эрланговед или что-то в этом роде. Язык очень любопытный: например, в нём есть зарезервированное слово todo - для мотивации программистов. И, наоборот - отсутствует ключевое слово if.

В целом, gleam - пример того, как эрланг можно переделать для использования с типами. Мы с вами знаем, что есть функциональные языки, такие как Haskell и OCaml, которые работают с типами хорошо. Однако, языки ML-семейства выглядят совсем по-другому. gleam же имеет C-подобный синтаксис.

В этой статье я постарался описать основные черты языка gleam. Также, в конце читателя ждёт увлекательный мастер-класс о том, как (не) нужно превращать обычный императивный язык в функциональный. На примере Python.

И да, поросёнок - не совсем официальный mascot языка gleam. Но я позволил себе немного пофантазировать - надеюсь, попал в цветовую гамму плюс-минус :)

Поздравляю с годом Кролика и желаю сбычи ваших мечт!

Хочу вас обрадовать, что, судя по всему, в новом году будет продолжение франшизы про асинхронный django. Версия на гринлетах скоро получит новую, более изящную форму. И новое название - fibers (старое, greenhack, никуда не годилось).

Сюда просится пример с кодом, но здесь его вставлять нельзя. На платье Сати можно было написать, если бы она была в платье. Если кто не в курсе - это Сати, девушка и причёска - из Матрицы.

Здравствуйте, читатели хабра! Читайте в этой статье - развенчание мифов об асинхронном программировании в Python! Действительно ли асинхронная модель - более производительная? И как обстоят дела с драйверами баз данных?

На картинке - скриншот бенчмарков от авторов драйвера asyncpg. Как Вы можете догадаться, автор этой статьи с ними не согласен.

Некоторые читатели знают из моих предыдущих статей о моих (вполне успешных!) попытках сделать асинхронную версию django. Я решил прекратить работу над ней - столько труда напрасно! Читайте - и не делайте так.

Стандарту WSGI 19 лет (c хвостиком). Выясняем, есть ли ещё куда развиваться приложениям с блокирующим вводом-выводом в 2022.

Отрисовка страничек на сервере, похоже, снова начинает приобретать популярность (нет, я не имею в виду React SSR).

Сторонники оппозиции растущему влиянию javascript, наконец, смогли направить усилия в нужное русло - и в результате родился фреймворк htmx! Поговорим о том, как он работает, а также, какие ещё фреймворки используют серверные шаблоны в 2022.

Также поговорим о divkit - аналоге html для мобилок, недавно выпущенный Яндексом в опен-сорс - Вы, наверно, догадались, какое отношение может иметь одно к другому.

Здравствуйте, дорогие бэкенд-разработчики на Python, у меня опять статья про django. И так будет до тех пор, пока в нём не появится нормальная поддержка асинхронности (шучу).

Вопреки распространённому мнению, что django - это фреймворк "с батарейками", но не очень поддающийся кастомизации, это не так. Необходимость поддержки разных провайдеров, поддержка так называемого multi-db (одновременное использование нескольких баз), да и просто банальное использование здравого смысла (местами) - сделало этот фреймворк одним из наиболее расширяемых среди ORM.

В этой статье я расскажу, как устроен database backend - это та штука, которая отвечает за поддержку конкретной базы данных и конкретного драйвера для неё. Я сделаю это на довольно экзотическом примере: мы с вами добавим поддержку асинхронного драйвера - psycopg3. Да, для постгрес - иначе причём здесь были бы слоны? Да, асинхронного. Или вы думаете, что django так не умеет? Читайте и убедитесь сами.

Некоторые уже видели мои статьи про добавление асинхронности в django. Этот пост не об этом: вопрос более широкий и посвящён асинхронности в целом. И подход совсем другой.

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

Итак, асинхронность в стиле gevent - что бы это могло быть? Читайте под катом. На картинке - иллюстрация к сказке Киплинга "Слонёнок".

Как должны выглядеть современные сервисы на питоне, многие имеют представление. Все они, так или иначе, имеют поддержку асинхронных операций. А вот, как их лучше деплоить? Здесь некоторые руководства (как FastAPI) отвели целый раздел для рекомендаций, а некоторые (как Django) ограничились несколькими абзацами с крайне размытыми формулировками. Мне не посчастливилось следовать именно последнему.

Прочитав эту статью, Вы, возможно, захотите внести изменения в докерфайлы Ваших сервисов. Благодаря протоколам WSGI и ASGI, это можно сделать без особого труда. Именно поэтому все изложенные в статье советы - вредные. Также, Вы узнаете о nginx unit - ещё об одном годном сервере приложений.

Здравствуйте, читатели хаба про django. Эта статья о фреймворке для перфекционистов с дедлайнами, и о том, можно ли добавить в него асинхронность. Некоторые в курсе, что со стороны Django Foundation также есть некоторые усилия в этом направлении. Например, есть [DEP-09](https://github.com/django/deps/blob/main/accepted/0009-async.rst), который примерно очерчивает границы будущих изменений. Причём, некоторые преобразования, на взгляд авторов, слишком объёмные, и про них явно говорится, что они выходят за рамки DEP. Такой, например, является задача сделать django orm асинхронной. Учитывая, что, по любым меркам, django orm - это больше 50% всего django, а на мой взгляд - его главная часть, DEP-09 мне кажется какими-то непонятными полумерами.

У меня есть альтернативное предложение по добавлению асинхронности, в какой-то степени, более радикальное. Такое, для которого не нужен DEP. В общем, я хочу сделать новую версию, которая заменит собой django. Не то чтобы это была самоцель: главное, я хочу выпустить асинхронную версию django, но синхронная будет тоже поддерживаться, так что традиционный django вряд ли будет очень нужен. К слову, если даже выбирать между только синхронной и только асинхронной версией, то только асинхронная имеет явное преимущество, на мой взгляд. Кстати, я хочу портировать только django orm, а не весь django. То есть, именно ту часть, которая выходит за рамки DEP-09. Итак, встречайте.

Здравствуйте, дорогие читатели хабра и хаба про django. Да, эта статья о фреймворке для перфекционистов с дедлайнами и о том, как в нём не хватает асинхронности. По духу это больше похоже на Enhancement Proposal (менее формальный, чем он мог быть) или RFC, так что, если Вы любите подобные вещи, то Вам может быть интересно.

Вопросом добавления асинхронности сама Django Foundation тоже интересовалась. Дискуссии вылились в DEP-09, который описывает текущий примерный roadmap. Я даже неожиданно обнаружил, что мой этот пост ему не противоречит. Просто о нативной поддержке асинхронности там не очень много и написано. Это считается там последним этапом, до которого ещё нужно дойти. Напоминает мем про то, как рисовать сову: вначале рисуем два круга, потом дорисовываем остальное.

Но давайте, всё-таки, попробуем сделать django асинхронным. Точнее, django orm. Забыл сказать: я считаю django orm главным препятствием на пути django к асинхроннности. Это, как-никак, наибольшая по объёму часть. Потом, именно orm содержит тот набор допущений и характерных черт, которые делают django узнаваемым, как минимум.

Значит, orm. Драйвера базы данных нужны асинхронные, но такие, конечно, уже есть.