Пополнение в списке контрибьюторов:
New PostgreSQL Contributors 2025
Major Contributors:
Андрей Бородин (Andrey Borodin, Яндекс.Облако), наши ПОЗДРАВЛЕНИЯ!
Джейкоб Чемпион (Jacob Champion, EDB),
Йелте Феннема-Нио (Jelte Fennema-Nio Motherduck, DuckDB),
Роберт Трит (Robert Treat, pgtreats, за общественную деятельность).
Просто новые контрибьюторы:
Эндрю Кейн (Andrew Kane),
Энди Фэн (Andy Fan),
Ханс-Юрген Шёниг (Hans-Jürgen Schönig),
Хиан Хе (Jian He),
Марко Нанчиарини (Marco Nenciarini),
Михаил Гольдберг (Michael Goldberg),
Сара Конвей (Sarah Conway).
Захотелось прикинуть, из каких компаний теперь самые уважаемые люди сообщества.
Core Team:
EDB - 2 (Петер Айзентраут — Peter Eisentraut, Брюс Момджан — Bruce Momjian),
Redpill Linpro — 1 (Магнус Хагандер — Magnus Hagander),
Microsoft — 1 (Андрес Фройнд — Andres Freund),
pgEdge — 1 (Дейв Пейдж — Dave Page),
Snowflake‑Crunchy Data — 1 (Том Лейн — Tom Lane, Crunchy Data теперь часть Snowflake),
Джонатан Кац — Jonathan Katz — вроде, сам по себе (UPD: а вот и нет! Появилась информация, что Джонатан теперь в Databricks, старший менеджер по Lakebase).
А вот что делается у Major Contributors:
Amazon — 9,
EDB — 8,
MS — 7,
<пропускаем некоторые компании>
Databricks‑Neon — 3 (Хейкки Линнекангас — Heikki Linnakangas, Анастасия Лубенникова — Anastasia Lubennikova в Неоне и Джонатан Кац в Databricks).
Postgres Professional — 2 (Олег Бартунов — Oleg Bartunov, Фёдор Сигаев — Teodor Sigaev),
Snowflake‑Crunchy Data) — 2,
Supabase‑OrioleDB — 1 (или 2 — уточняем) (Александр Коротков — Alexander Korotkov),
Google Cloud — 1,
Яндекс.Облако — 1,
pgtreats — 1,
Nile — 1 (Жюльен Руо — Julien Rouhaud).
Кстати, об Олеге Бартунове:
Бартунов «в офисе»: под капотом Postgres, деньги open source и судьба разработчиков после прихода ИИ
С Олегом поговорил Ваня Ботанов aka StressoID, автор телеграм‑канала «Деплой».
«Есть большое сообщество, множество компаний, но нет одного „главного“. Google, Amazon, Microsoft участвуют, но не диктуют правила.»
Вообще, в этом интервью немало того, что в другие, кажется, не попадало.
«Мы писали программы, придумывали собственные языки. Даже операционные системы „взламывали“ — как тогда говорили, „хачили“. Как‑то раз нам какие‑то органы, возможно, сотрудники КГБ, принесли в подарок в университет две ленты с исходниками операционной системы ICL. Из этого в МГУ выросло, наверное, шесть или семь собственных ОС. Естественно, и астрономы — в том числе я — тоже включились, занялись улучшайзингом.»
Это было замечательное время: мы буквально на практике изучали, как устроены компьютеры и архитектура систем, сами железки. Вы видели как память устроена?
— Внутри?
— Внутри. Мы разбирали ту же БЭСМ-4: там память была на ферритовых колечках, соединённых проводами. Я знаю, что такое ртутная память: была память на ртути — это металлическая трубка длиной около метра, заполненная жидкой ртутью, подогретой до 40 градусов. И это была память.“
Статьи
Pipelining in psql (PostgreSQL 18)
Автор — Данил Истина (Daniel Vérité) — в своём блоге, который называется PostgreSQL Notes, исследует конвейеры psql. И приводит впечатляющие диаграммы.
В коротеньком историческом экскурсе он напоминает, что конвейеризация появилась ещё в версии 7.4 (2003), когда появился расширенный протокол запросов. Но только с 2021 года, с выпуском PostgreSQL 14, появилось возможность сооружать конвейеры, используя libpq. С тех пор некоторые драйверы, основанные на libpq, такие как psycopg3, начали её поддерживать.
Что же важное произошло сейчас? С выпуском PostgreSQL 18 psql получил команды для работы с конвейеризацией в SQL‑скриптах. Далее Даниэль придумал простые тесты и погонял на них Postgres с конвейерами и без.
И пришёл к такому выводу: если мы посылаем пакеты из небольших запросов, не погружая их в конвейеры (на конвейеры — язык не поворачивается сказать, они же, всё‑таки pipelines), то мы поймём, насколько недогружаем сеть. Это как (говорит Даниэль Веритэ) посылать один за другим автобусы с 50 сиденьями ради 1 пассажира в каждом.
Пересматривая концепцию мультимастера на Postgres / Revising the Postgres Multi-master Concept
Андрей Лепихов (Andrei Lepikhov) занялся логической репликацией и, по этому поводу решил переосмыслить концепции мультимастера, которым он сам занимался в конце 2010-х: я занимался созданием мультимастера несколько лет вплоть до того момента когда стало понятно, что концепция essentially consistent multimaster зашла в тупик.
Он рассуждает почти абстрактно, не привязываясь к конкретным реализациям. Не боясь распугать читателей, Андрей начиняет статью формулами. И в конце статьи приходит к списку требований к мультимастеру будущего:
Replication sets — чтобы классифицировать данные для репликации, отдельно обеспечивать синхронную и асинхронную репликацию.
Коммит с подтверждением (по аналогии с 2PC).
Протокол распределенного консенсуса для определения работоспособного подмножества нод и фенсинга сбоящих нод в 3+ конфигурациях.
Параллельная репликация — распараллеливание как отправки DML, так и их применения на удалённой стороне.
Automatic Conflict Resolution для автономного режима работы.
Когда‑то — осенью 2017 — и я писал о мультимастере в статье Различия Postgres Pro Enterprise и PostgreSQL. Там, кстати, не с 2-фазные, а с 3-фазные фиксациями транзакций (3PC).
Ну и как там старый добрый multimaster? Да, вот он в действующей документации Postgres Pro Enterprise: синхронный кластер, который обеспечивает масштабируемость OLTP и высокую степень доступности. Авторы: Postgres Professional; благодарности: механизм репликации основан на логическом декодировании и предыдущей версии расширения pglogical, которым поделилась с сообществом команда 2ndQuadrant.
Английский вариант статьи Андрея заканчивается словами The End, а русский — табличкой с теми технологиями, которые реализованы, и ссылками:
3-й пункт — это свободная версия мультимастера, и, поскольку нужно патченное ядро, то ссылка на него и прилагается. Там исходники для сборки, пропатченные на основе версии PostgreSQL 13.
Далее: есть сериал из 3 частей авторства Павла Конотопова (@kakoka) и Михаила Жилина (@mizhka), сотрудников Postgres Professional. Очень их рекомендуем. Вот они:
Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL. Части 1 | 2 | 3.
Михаил и Павел там рассказывают вовсе не только о разработках своей компании, а ещё и о EDB PGD (EnterpriseDB Postgres Distributed), Traktor и pgEdge/spock (опять же).
Расширения, посткабанчик и свинка в свинарнике
Как-то я обратил внимание на такой тред в рассылке hackers: Заид Шаббир (Zaid Shabbir) написал письмо All supported PostgreSQL 17 extensions list, в котором задал наивный вопрос:
Я ищу полный список расширений PostgreSQL 17 — как с открытым исходным кодом, так и коммерческих. Я нашёл ссылку, но, похоже, там не представлены все доступные расширения. Есть ли официальный, поддерживаемый сообществом список с достаточно полным списком поддерживаемых расширений?
Отвечает классик Лауренц Альбе (Laurenz Albe):
Нет «поддерживаемых». Каждое расширение само себя поддерживает. Исключение — те, что лежат в contrib и поставляются с PostgreSQL: они поддерживаются PGDG. Полного списка не существует, насколько мне известно. Поглядите ещё на pgxn.org, поищите поиском на Github.
Флоренц Целаи (Florents Tselai, албанец, переехавший в Грецию, довольно активен сейчас в переписке) сжалился:
Учитывая сказанное Лауренцом, гляньте ещё список https://yum.postgresql.org/extensions/.
И Чэпмен Флак (Chapman Flack) добавляет:
В презентации Adventures in Extension Packaging Дэвида Уилера (David Wheeler, PGDG, Tembo) на PGConf.dev 2025 в Канаде на 5-м слайде есть ссылка — по ней список, где, кажется, около 1200 расширений.
Как ни странно, хотя в слайдах Дэвида я этой ссылки не обнаружил, ссылка действительно ведёт к огромному списку. Понятно, что многие расширения из списка уже не действующие, и наоборот — многих важных расширений не хватает.
Мы же на эту тему тоже писали не раз: Postgresso #6 (67) было, например, такое:
Есть инициатива — pgextensions.org. Идея их — создать удобное место для сравнения расширений и поиска их по разным критериям у разных облачных провайдеров Postgres — PostgreSQL Cloud Extension Comparator. И особенно следует отметить Tembo Cloud и Trunk Extension Registry.
Мы тоже особо отметим Тембо (это крутой слон из игры) и Trunk (то есть хобот): они приказали другим Postgres‑облакам и Postgres‑установщикам долго жить: «Trunk закрылся [как и облако] 7 июля 2025». А жаль: вот на упомянутом ресурсе PostgreSQL Extensions on Cloud на диаграмме расширений, доступных в облаках, Trunk был безусловным лидером (218 расширений). Теперь лидер — Amazon Web Services (106). А на втором месте, кто бы вы думали? Neon (99). Дальше плотно.
Но как тут не вспомнить о свинарнике? (так переводится Pigsty, а произносится не пигсти, а пигстай).
Pigsty — Free PG RDS, вот их гитхаб
Pigsty — это, как написано на их 1-й странице, Battery‑Included, Local‑First PostgreSQL Distribution as a Free & Better RDS Alternative. Хм. То есть: бесплатная и улучшенная альтернатива RDS, ориентированная больше на локальное использование, с полным набором функций (это про батарейки). Также они сами называют всё это метадистрибутивом.
Там на сегодня 423 расширения. Они разбиты на разделы. Вот такая, например, богатая коллекция в разделе RAG, да ещё и с описаниями:
vector — векторный тип данных и методы доступа ivfflat и hnsw,
vectorscale — pgvectorscale, улучшенное индексирование для работы с векторными данными,
vectorize — самый простой способ выполнения поиска по векторам в PostgreSQL,
pg_similarity — поддержка запросов по сходству (similarity queries),
smlar — эффективный поиск по сходству,
pg_summarize — составление текстовых саммари с помощью LLM‑ов, реализовано через pgrx,
pg_tiktoken — токенизатор tiktoken для использования с моделями OpenAI в PostgreSQL.
pg4ml — фреймворк машинного обучения для PostgreSQL.
pgml — PostgresML: запуск задач искусственного интеллекта и машинного обучения через SQL.
(Богатая, но не то, чтобы совсем полная: ниже, в Релизах будет про VectorChord и vectorwrap).
А ещё есть разделы: Time, GIS, OLAP, FTS, Feat, языковые расширения, типы, утилиты, функции, админ. И в каждом десятки расширений.
Но набором расширений в Свинарнике не ограничиваются. Версия Pigsty 3.6 предоставляет ещё и набор из 10 разных ядер PostgreSQL. И отличное описание ключевых особенностей этих ядер прилагается:
PostgreSQL — Оригинальная версия. Vanilla PostgreSQL с более чем 420 расширениями.
Citus — Горизонтальное масштабирование. Распределённый PostgreSQL через нативное расширение.
WiltonDB — Миграция с SQL Server. Совместимость с протоколом SQL Server.
IvorySQL — Миграция с Oracle. Совместим с синтаксисом Oracle и PL/SQL.
OpenHalo — Миграция с MySQL. Совместимость на уровне протокола MySQL.
Percona — Прозрачное шифрование данных. Percona с pg_tde.
FerretDB — Миграция с MongoDB. Совместимость с протоколом MongoDB.
OrioleDB — Оптимизация OLTP. Zheap, отсутствие распухания, поддержка S3-хранилища.
PolarDB — Версия Aurora с RAC. RAC — соответствие требованиям Китая.
Supabase — Backend как сервис. BaaS на базе PostgreSQL, альтернатива Firebase.
Cloudberry (WIP) — MPP DW и аналитика. Масштабируемое параллельное хранилище
Хм, обманули: даже 11, а не 10.
У читателя, наверное, возникает вопрос: вот свинарник, а где же свинья?
Есть и свинья, а как же. Это утилита для установки PIG CLI. Сейчас актуальна Свинья pig‑v0.6.2.
Судя по многим признакам, проект сильно китайский. Возможно и название Pigsty связано как‑то вот с этой древней безделушкой Империи Хань:
Вот некоторые ссылки:
А причём здесь кабанчик? Точнее пост‑кабанчик. Да ни при чём, к слову пришёлся. Это аналитическая платформа, и среди прочих она берёт как источник данных и Postgres тоже. Но новостной повод: они запустили газету для разработчиков. Вот анонс:
The First Newsletter Dedicated to Product Engineers — пишут, что уже больше 100 тыс. подписчиков. Но, чтобы подписаться, надо вписать свой адрес в окошечко, а подписываясь, тем самым согласиться с правилами соцсети правилами соцсети Substack.
Это сообщение имело статус рекламы на сайте Postgresweekly, а сам номер тогда был с плашечкой together with PostHog. Но последнее время чаще встречается together не с посткабанчиком, а с тигриными данными.
Напоминаем, что TigerData это Timescale, подвергшаяся радикальному ребрендингу: Timescale Becomes TigerData: Reimagining PostgreSQL for the Era of Real‑Time Intelligence — в Postgresso 3–4 за 2025 (76-77) в разделе о об изменениях на рынке Postgres было:
Да что ж это делается? Хрустящие данные обратились снежинками, новый кирпичик данных стал неоновым, временная шкала обратилась в тигра и Xata переродилась.
Релизы
В блоге МамыУтки Йелте Феннема‑Нио (Jelte Fennema‑Nio, это он недавно получил статус Major Contributor) и Джейкоб Матсон (Jacob Matson) объявили о релизе расширения для Postgres УтинойБазы с круглым номером — 1.0.
Утки плавают в прудах. Postgres — слоняра, это вам не уточка в data lakes. Но у DuckDB есть нужная абстракция для Data Lakes — унифицированный SQL‑интерфейс, который работает с разными облачными провайдерами и форматами файлов. Поэтому, установив расширение pg_duckdb, можно получить безопасный доступ к облачным хранилищам (S3, GCP, Azure), напрямую выполнять запросы к удалённым файлам в различных форматах (CSV, JSON, Parquet, Iceberg, Delta), и пользоваться аналитическим движком, который обслуживает BI‑инструменты и приложения, используя привычный PostgreSQL SQL.
Надо помнить, что pg_duckdb встраивает экземпляр DuckDB непосредственно в уже работающий процесс PostgreSQL. Отсюда плюсы и минусы.
В версии 1.0 улучшена интеграция с MotherDuck, есть поддержка большого числа типов данных, повышенная стабильность и улучшена производительность, включая параллельное сканирование таблиц. Вот — прочитайте полный список изменений.
Introducing Elephantshark, a tool to monitor Postgres network traffic
Как выглядит СлоноАкула? В статье есть изысканная картинка. А вообще это ещё одно произведение Неона (вот GitHub):
Elephantshark устроился между двумя сторонами обмена по протоколу Postgres, пересылая сообщения в обоих направлениях, одновременно разбирая и записывая их в журнал. Это открытый исходный Ruby-скрипт, выпущенный компанией Neon, который работает со всеми видами сетевого трафика по протоколу Postgres. Включая, но не ограничиваясь, трафиком к и от баз данных Neon.
Два векторных релиза:
VectorChord (vchord) — это расширение PostgreSQL, разработанное для масштабируемого, высокопроизводительного и эффективного с точки зрения дискового пространства поиска векторов по схожести.
Tensorcord утверждает, что с этой штукой можно запросто разместить 100 миллионов векторов размерностью 768 (более 250 ГБ) на AWS i4i.xlarge (250 долларов в месяц), оснащённом 4 виртуальными ЦП и 32 ГБ оперативной памяти. И хранить 400 000 векторов всего за $1.
Чуть не прочитал разработчика как ... запрещённое (не везде) вещество. А это энтузиаст-одиночка Михир Ахуджа (Mihir Ahuja) из Сан Франциско. Он сделал универсальную обёртку для поиска в Postgres, MySQL, SQLite, DuckDB, ClickHouse (pgvector, HeatWave, sqlite-vss, DuckDB VSS, ClickHouse ANN). Переключаться между СУБД можно 1 строчкой кода.
Конференции и митапы
Про эту конференцию, прошедшую в конце сентября, мы уже говорили, но сейчас появляются, как говорится, фоллоуапы: например, 423 фотографии — ВК. Они же на сайте.
А главное — доклады доступны участникам (в публичном доступе — позже).
Кстати, доклад Егора Рогова, где он рассказывал в том числе про генератор, появился в виде статьи на хабре: Демобаза 2.0 для PostgreSQL.
Прошли и пройдут митапы, геораспределённые весьма широко:
PGMeetup.СПб/25 — февраль, Питер.
PGMeetup.NN 2025 — май, Нижний.
PGMeetup.PERM 2025 — август, Пермь.
PGMeetup.KZN 2025 — октябрь, Казань.
PGMeetup.EKB 2025 — ноябрь, Екатеринбург.
PGMeetup.EKB 2025 — декабрь, Владивосток.
В Екатеринбурге, например, 13 ноября будет 4 доклада:
Статический анализ в современной разработке: качество кода, безопасность, ГОСТ и open‑source Глеб Асламов из PVS‑Studio.
Решения для ИБ в СУБД на базе PostgreSQL — Андрей Гусаков консультант из Postgres Professional.
Проблемки с Postgres, когда меня призывали — Андрей Бородин (отрекомендовался как Postgres Hacker).
От RAG к автономности: как мы сделали ИИ‑агент для работы с PostgreSQL при помощи ReAct и MCP — Савелий Батурин, инженер по машинному обучению, Postgres Professional.
Но есть митапы и не с геомотивацией, а тематические - я в одном таком участвовал: у астрономов в ГАИШе, вместе с Крисом Трейверсом. Говорили об open source. Там действительно доклады слушали астрономы, но не только: в постмитапных, весьма интересных для докладчиков беседах выяснилось, что некоторые пришли послушать, просто увидев анонс.
Другие темы митапов: Аналитика в Postgres Pro — просто добавь OLAP! или, например: Шардирование больших баз данных.
Postgres Trip Report from PGConf NYC 2025 (with lots of photos)
На Microsoft Community Hub Клэр Джордано (Claire Giordano) говорит: кто пропустил это событие в Манхэттене, тот сильно потерял, но есть хотя бы три галереи фотографий, а многие выступающие предоставили слайды своих презентаций, их можно увидеть, гуляя по расписанию PGConf NYC.
PGConf NYC 2025 Recap: Postgres Advances & Insights — этот отчёт подписан: команда EDB. Мне сразу бросилась в глаза фотография: Брюс Момджан, Вадим Михеев и Марк Фурнье — трое из Core Team 90-х. Легенды. Особенно удивительно увидеть Вадима Михеева, о котором я не раз слышал от Олега Бартунова.
Говорят, обсуждалось всё: от глубокого погружения в оптимизатор до ИИ. Полно новых вызовов, но Postgres работает, так как был задуман так, чтобы меняться с обстоятельствами. Что, мол, Postgres становится базой (в обоих, а то и в трёх смыслах) для нарождающихся ИИ‑конвейеров (AI pipelines), не жертвуя главным — гарантиями реляционной целостности. И реализуется это всё в основном расширениями, а не изменениями в ядре.
Другая популярная на конференции тема — баланс реляционной строгости и гибкой работы с слабоструктурированными данными (JSON и массивы).
Выступления практиков показали, что огромные объёмы данных (авторы говорят не о пета‑, а о сотнях терабайт) из экзотики превращаются в новую норму.
Ещё там предвкушали большую многопоточную PostgreSQL Conference Europe 2025 в Риге.
О ней пишет их коллега Кристина Мартин (Christina Martin), но пишет в будущем времени, а сейчас она уже прошла. Пока отчётов мною не обнаружено, но, наверняка, будут. Расписание её — вот.
UPD: 29 октября появился отчёт Флоор Дреес (Floor Drees) My PGConf EU 2025 experience в блоге DEV Community. Но Флоор сама не слишков dev, она больше активистка, организатор. Ей полюбился женский PostgreSQL‑завтрак, понравился доклад Корнелии Бьяшиш (Cornelia Biacsics) о том, как каждый может стать контрибьютором проекта — ведь немало вкладов в проект не связано непосредственно с разработкой (non‑code contributions). Корнелия присоединилась к команде postgres‑contrib.org, а сама Флоор вошла в Contributors Committee, где Кристоф Берг (Christoph Berg), Джо Конвэй (Joe Conway) и Мелани Плейгман (Melanie Plageman). Ждём более технических отчётов.
UPD2: Появился отчёт Рафии Сабих (Rafia Sabih).
А в это время (15-17 октября) на Ибице проходила конференция, которую организует союз испаноязычных постгресистов Fundación PostgreSQL во главе с энергичным Альваро Эрнандесом (Álvaro Hernández). Пока отчёта не видно. О прошлой тусе на Ибице впечатлениями делился Хесус Эспино Jesús Espino: My experience at PGIbz 2024.
Штаб‑квартира ЦЕРН, оказывается, в городке Мерене (Meyrin) у границы Швейцарии и Франции, ближайший крупный город — Женева. Там же пройдёт и конференция 6 февраля 2026. Это вторая ЦЕРНовская конференция, она однотрековая с 6 докладами. Организуют её сами ускорительщики и швейцарское сообщество постгресистов — SwissPUG.
Также информация есть на PostgreSQL.org: PGConf India 2026: Call for Papers, хотя CFP уже закрыт, если верить объявленным срокам. Конференция пройдёт 11–13 марта 2026 в Бангалоре.
Языки успешные и/или прекрасные
IEEE Spectrum опубликовала рейтинги языков программирования:
The Top Programming Languages 2025
Нет. Это только половина заголовка. Вторая половина такая:
Does AI mean the end for the Top Programming Languages?
Тот, кто глянет рейтинги, не прочитав статью, много потеряет. Это почти философская статья в стиле «блажен, кто посетил сей мир [программирования] / в его минуты роковые». Автор — Стивен Касс (Stephen Cass) смотрит на список и видит, что главное изменение в топе — это провал JavaScript с бронзы в прошлом году на 6-е место. Как же так? Такой перспективный, казалось язык. Да, но это язык, которым широко пользуются сайтостроители. А за сайты всерьёз взялся ИИ.
Но приключения не только у языков, а и у составителей рейтингов тоже. В критерии входили количественные оценки активности на сайтах вопросов‑ответов. А сейчас люди сплошь советуются тэт а тэт с GPT или Клодом. И о чём они там беседуют и часто ли — тайна сия велика есть. Число вопросов в неделю на Stack Exchange в 2025 составляет 22% от того, что было в 2024!
Но: ещё более фундаментальная проблема is looming in the wings. Да что ж такое... В крыльях что‑то не так? Мы тоже спросим не у коллеги, а у Perplexity. Здесь «wings» — это кулисы сбоку сцены. Значит, что проблема находится неподалёку и вот‑вот проявится или вызовет серьезные последствия.
Религиозные войны по поводу того, форматировать ли отступы в коде табуляцией или пробелами, будут непонятны людям недалёкого будущего, которым вообще мало интересно на каком языке написана программа.
Вы не будете программировать стиральную машину на R, и анализировать статистику на C — говорит Стивен, — но раз это технически возможно, то вы можете попросить сгенерить LLM код для машины на R, а анализ статистики на С — им всё равно. На предыдущем этапе программисты аналогично перестали интересоваться командами процессора, на котором будет исполняться их детище.
Стивен, чувствуется, озабочен и ещё одной проблемой, о которой думают многие: не приведёт ли такая новая и странная языковая демократия к деградации программистского мышления? Ведь кроме прагматиков (нужен оптимальный язык для решения задачи, остальное от лукавого), есть и те — их много и в науке, и в образовании, — кто оценивает языки именно с точки зрения развития мышления и программисткой культуры. В статье Стивена немало интересных ссылок. Вот одна из них:
What We“ve Built Is a Computational Language (and That”s Very Important!)
Автор статьи, Stephen Wolfram Writings — сам Стивен Вольфрам, основатель Wolfram Research, которая подарила миру программу Mathematica. Он говорит, что поэт в России больше, чем поэт язык Wolfram — больше, чем язык, это чуть ли не мировоззрение.
Среди семейств языков есть, как мне кажется, языки‑аристократы, языки‑снобы. Это функциональные языки. То, что владение ими способствует и систематизации мышления, и просто взрывному росту нейронных связей, я не сомневаюсь: помню, как мозг закипал от кода Emacs Lisp в этом изысканном редакторе. Сам LISP создавался для ИИ, были даже железки — Лисп‑машины. Современному ИИ это всё не нужно. Язык R относительно неплохо (пока) себя чувствует: в списке он на 11-м месте, перед «народным» php и ещё что‑то свеженькое появляется. А вот Haskell замыкает 30-ку. А между тем:
В России с этим языком происходит что‑то (во всяком случае мне — стороннему ненаблюдательному наблюдателю) не очень понятное. Выходили интервью и нарезки‑интервью с такими названиями, например:
Говорят, Haskell — язык для гениев и академиков. Правда?
Джон Доу там даже так сказал: В Haskell строгая сильная (я бы сказал, фашистская) типизация [жаль, что Джона Доу не существует, это же такой джокер, средневековый виртуал].
Типизируя техническое интервью — задача о 7 ферзях (то есть визирях, но в статье они выше рангом: они — королевы).
FPConf 2017. Интервью с Денисом Шевченко — он «в прошлом — С++‑программист. В настоящем — апологет функционального программирования, сооснователь сообщества ruHaskell, практикующий Haskell‑программист.»
FPConf — это, как все догадались, конференция по функциональному программированию. Где она? Ау!
А вот и книжка выходила у Дениса Шевченко: О Haskell по‑человечески — но это книга 9-летней давности. Всё‑всё это уже где‑то в недрах старины глубокой — 8–9 лет назад. Где‑то Haskell‑жизнь наверняка ещё теплится, но где?
Или другая, драматическая история: всплеск интереса к гугловскому языку Dart (#15 в рейтинге) в отдельно взятой, но крупной компании: «у Wrike около 400 разработчиков. Они переписали фронт на язык, который тогда вряд ли знала и тысяча человек, и, кажется, до сих пор абсолютно в себе уверены.» — это сказано в статье Как нанимать людей в огромную компанию с непопулярным стеком. Разговор с Wrike весной 2019. До этого была статья Два года с Dart: о том, как мы пишем на языке, который ежегодно «хоронят» (часть 1) — летом 2017. Всё это происходило при гендире (и основателе) Андрее Филёве (с 2023 гендир Томас Скотт, Thomas Scott).
Dart, как мы видим по рейтингу, хоронят (пока) напрасно (он обогнал даже Ruby, идёт вслед за Rust), а вот весной 2021 читаем: Wrike уходит от использования языка Dart. Часть 1. Куда же уходит? В Typescript + React. Typescript в рейтинге идёт сразу за JavaScript. Тоже — мы помним слова Стивена Касса — кандидат на отмену?
И, в заключение, вернёмся к отечественным постгресистам:
Профессия программист С: плюсы, минусы и нужен ли свитер — Максим Орлов, разработчик Postgres Professional признаётся в любви любимому С.
Но мы не констатировали главное (да вы и так увидели): 1-е место у Python с колоссальным отрывом от Java, дальше C++, и — наконец! — SQL.
На сегодня всё.