С появлением LLM люди разделились на три лагеря: тех, кто верит в повышение КПД при помощи автодополнения и тех, кто относится к хайпу крайне скептически. Третий лагерь — это сами LLM, они же тоже что-то там про себя думают, наверное.

За долгие годы работы с кодом я привык слышать от среднего уровня разработчиков (и от тех, кто выбрал языки, которым требуется бесконечная генерация бойлерплейта): «Продуктивность программиста напрямую зависит от IDE». При том, что я всегда производил в несколько раз больше самого сложного в компании кода, используя vim с минимумом плагинов. Подсветка синтаксиса мне помогает, тут (как, впрочем, и почти везде) я с Пайком не согласен. Автодополнение — уже нет, я его иногда включаю «еще раз попробовать, вдруг это со мной что-то не так», и когда читаю курсы — но в основном мне мешают выскакивающие окошки: отвлекают, распыляют внимание, наталкивают на ложный путь.

Я часто говорю, что если язык лишен встроенных средств работы с AST — абстрактным синтаксическим деревом — то этот язык спроектирован не очень умными людьми. Идолопоклонники могут с пеной у рта доказывать, что AST никому не нужно, или что хорошего API к AST — достаточно, или что прикрученное сбоку AST-представление закрывает потребности…

Это все детский лепет, и ниже я собираюсь рассказать, почему. Оба самых «популярных» (читай: хайповых) языка программирования современности — Rust и Go — не обошлись без этой родовой травмы (если вы считаете, что экспорт AST при помощи костыля rustc_ast::ast — решает эту проблему, вы просто не понимаете, что такое AST и зачем он нужен).

В эрланге (и эликсире) мне всегда недоставало способа организовать «потоковый» обмен сообщениями, наподобие того, который обеспечивает какой-нибудь Message Broker. Нормальные разработчики смиряются с ограничениями, которые им задают их фреймворки: в Финиксе есть PubSub, в OTP — :gen_event, в эликсире — депрекейтнутый еще до рождения GenEvent.

Так родилась библиотека Antenna, которая предоставляет все те возможности, которые обычно обеспечиваются посредством вкрячивания дополнительной зависимости от брокера сообщений. Требования, которые я к ней предъявлял, были следующими:

Так получилось, что загруженный в меня годами разработки опыт привел к нигилизму и отрицанию общемировых ценностей. Например, я ненавижу демократию, самое первое запротоколированное проявление которой привело к решению распять нахрен одного там назаретянина (но сейчас не об этом). Я отрицаю пользу IDE, необходимость развития языков программирования, целесообразность существования паттернов и еще много достижений цивилизации по остаточному принципу.

Зато я являюсь ярым сторонником велосипедостроения. В подавляющем большинстве ситуаций лучше спроектировать и реализовать свой велосипед с перламутровыми пуговицами, чем пытаться приварить оные к выкидышу китайского велосипедопрома. Почему-то среди моих коллег принято относиться к собственным реализациям чего угодно — пренебрежительнее, чем к невнятной библиотеке версии 0.0.1, написанной албанским стажером три года назад по пьяни.

Если разработчик уровня выше стажера считает, что какой-то хрен из интернета уж точно напишет случайный кусок кода лучше него — это не программист, это самозванец, его надо гнать из команды с волчьим билетом.

Сегодня мы поговорим о еще одном, незаслуженно игнорируемом джейсоноукладчиками с узким кругозором, мощнейшем инструменте для работы со структурированными данными. О линзах. Удивительнейшим образом, поиск в интернетах по этому ключевому слову — из внятного — отдает только текст Эрика Эллиота с примерами на джаваскрипте. Эрик — умнейший человек и очень сильный популяризатор, но …кхм… «джаваскрипт, сэр».

Я покажу, как правильно использовать один из самых недооцененных и редко используемых инструментов эликсира — для умной выборки из структурированных данных, а также (на примере собственно библиотеки, куда без этого) — как абьюзить этот механизм для экстравагантных хаков.

В современном мире невозможно себе представить взрослое приложение, которое не экспортирует телеметрию. Метрики — важнейший атрибут поддерживаемого софта; для всех более-менее профессиональных технических специалистов термин «visibility» давно вытеснил прочие остальные баззворды наподобие «test coverage» и «continious integration».

Примерно двадцать лет назад я впервые узнал о философии отказоустойчивости Джо Армстронга, которая сводится к тому, что инструменты, помогающие разработчику не принести в код ошибку — штука хорошая, но по гамбургскому счету бесполезная, потому что не существует такой приблуды, которая сделает программиста идеальным. Разработчики, даже самые лучшие, будут ошибаться, и первоочередная цель инструментария — минимизировать потери от неизбежных ошибок, а не элиминировать оные полностью. Достижимые цели всегда лучше хрестоматийно правильных.

Отсюда вырос знаменитый «слоган» эрланга «Let It Crash!», высмеиваемый и всегда неверно трактуемый теми, кто неутомимо отслеживает все исключительные ситуации… и спотыкается об отсутствие нужного для их корректной обработки контекста в месте ловли. «Let It Crash» — означает не «Хрен с ними, с ошибками», а «Случилась какая-то ерунда в рантайме, но мы к ней готовы».

¡NB! В тексте нет прямых примеров использования телеметрии в ООП/ФП проектах, но я глубоко убежден, что этот текст будет полезно прочитать, даже если вы просто перекладываете джейсоны из пустого в порожнее на шарпах, котлине или хаскеле.

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

Вместо этого мы понапридумывали всякие sticky sessions, умный роутинг, да даже web-сокеты выросли не из целесообразности сохранения состояния соединения (что хорошо, правильно и часто нужно), а из приклеивания к инстансу сервера (что никогда не нужно, и что практически во всех решениях мешает открыть два вебсокета и получать данные вперемешку из обоих, как это можно сделать с брокером сообщений).

Приклеивать сессию к физическому инстансу (ноде, условно говоря, к IPv4/IPv6) — бред, лишний слой для обеспечения этого только мешает и всё портит, ведь сервер всегда обладает всей необходимой информацией для того, чтобы принять запрос на ноде A, выполнить его на ноде B, а потом ответить всё с той же ноды A. Но делегация выполнения функции на соседнюю ноду — существующая уже сорок лет в эрланге — это же какой-то прям рокетсаенс. Поэтому когда к нам всё-таки приходит понимание того, что иногда одной ноды для полной обработки запроса недостаточно, — мы городим микросервисную архитектуру поверх редисов, или даже брокеров сообщений, и выдумываем саги о каких-то совершенно в данном случае ненужных форсайтах и прочий хайтек — вокруг тривиальной задачи.

Больше двадцати лет назад мне довелось поработать в одном берлинском стартапе, где мы пилили визуальную трансформацию UML в код и обратно. Пользовательский интерфейс на свинге, изоморфная (в теории) обработка кода и диаграмм — на хаскеле. Было весело, потом полопались доткомы, кончилось финансирование и мы еще почти год пытались как-то дотянуть до продукта без денег. Капитализм победил, и продукт погиб (насколько я знаю) — так и не родившись.

Из интересного (помимо того, что я сам нарисовал почти полсотни иконок для нашего приложения, что до сих пор считаю самым выдающимся собственным достижением в IT) — там был придуманный и воплощенный мной механизм Undo/Redo, о котором я и собираюсь сегодня рассказать.

Как нерадивый Вася Пупкин воплощает в реальность маловнятную просьбу заказчика добавить «чтобы оно удалялось, а потом обратно появлялось, как в ворде»? — Строит линейную очередь изменений и ходит туда-сюда указателем по этому тоннелю без света в конце. После добавления ручной правки — все элементы в очереди дальше текущего — просто стираются, от греха подальше. Так ведь?

Как ту же самую задачу решает несдержанный на язык швед финского происхождения?…

Есть несколько стандартных вопросов для собеседований на позицию разработчик эрланг/эликсир. Речь не идёт про веб, там от людей обычно требуется умение писать код на Phoenix, который настолько хорошо абстрагирует OTP от ранимого разработчика, что можно годами клепать на нем сайты и не иметь представления о том, что такое акторная модель.

Но если речь идёт о понимании парадигмы, людей обычно спрашивают примерно о таких вещах:
  ▸ [junior] чем отличается GenServer.call/2 от GenServer.cast/2 и от Process.send/3
  ▸ [middle] как реализована модель синхронных вызовов (GenServer.call/2) и зачем в колбэке нужен второй параметр
  ▸ [middle] зачем нужен колбэк init/1 и в каких случаях из него имеет смысл вернуть кортеж {:ok, state, {:continue, arg}}
  ▸ [senior] как перенести процесс на другую ноду

Поскольку на хабре все без исключения носят лычку Синьёр++, сегодня мы поговорим о переносе процесса.

Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.

Если вы сфокусируете взгляд на синей рамке, вы увидите растопырившего лапы Амбидиректуса с вытянутой шеей и маленькой головой, развернутой влево. Перефокусируясь на красную рамку, вы познакомитесь с его приготовившимся нырнуть в стену справа Alter Ego, с плотно ввинченной в шею головой и замершими во взмахе назад передними конечностями.

Я показал вам этого Амбидиректуса для того, чтобы проиллюстрировать основную мысль этого текста: споры о превосходстве той или иной парадигмы над остальными — не имеют никакого смысла и всегда являются религиозной войной остроконечников против тупоконечников.

Книги делятся на две категории: fiction и non-fiction. Технические книги — внезапно — не исключение, и поддаются точно такой же классификации. Между учебником по научной дисциплине, начинающегося с аксиоматики и продолжающегося доказательствами теорем, — и практически любой современной литературой по «Computer Science» — лежит пропасть. Что происходит, когда люди долгое время оказываются рабами одной-единственной книги (с продолжениями), нам хорошо известно из истории. Возникает религия.

99% процентов литературы по ООП — это талмуд. Вероятность того, что вам подойдет «паттерн» — примерно 50%. Как встретить динозавра на Невском. Знание паттернов полезно в той же степени, что и теология, — и примерно тем же по специальности людям. Всегда полезно уметь отличать по запаху Пана от простого фавна, но практических применений такой эрудиции — не существует.

Когда Грубер со Шварцем выкатили маркдаун, он был как глоток свежего воздуха. Минимум разметки, читаемый текст даже до обработки, достаточный для рядового средней руки блогера набор красивостей.

Спустя пару лет мне стало мучительно недоставать возможности тонкой настройки. Я никогда не использовал маркдаун для разметки научных статей и документов с вложенными в нумерованные списки таблицами, а CommonMark двигался, почему-то, именно в этом направлении. Не, серьёзно, цитата с вложенной таблицей, в одной из ячеек которой — список? Кому вообще может прийти в голову реализовывать это на маркдауне?

Если на Силикатной улице (это в Мытищах) остановить тысячу случайных прохожих и спросить их, на каких трёх слонах покоится ООП, каждый второй назовёт инкапсуляцию. В коридорах МИФИ, или на собеседовании в Яндексе — процент будет даже выше. Даже LLM способна на шести пальцах объяснить, почему.

И, тем не менее, ООП — один из худших способов обеспечить инкапсуляцию. Идолопоклонники на этом месте могут поставить тексту, мне и вселенной — минус, остальным я на примерах попытаюсь объяснить, что побудило меня к столь резкому заявлению.

Все современные средства разработки — практически без исключения — наделены двумя родовыми травмами. Они не дают доступа к чуть более низкому софтверному уровню (синтаксическому дереву) без помощи сторонних хаков и ориентированы на синхронное исполнение.

Прежде, чем продолжить, я сразу оговорюсь: я не имею в виду узкоспециализированные задачи, типа написания драйверов, программирования контроллеров и прочей околожелезной разработки; там другие правила. Я говорю про мир приложений: от инди-игр до энтерпрайза. Языки высокого уровня, на которых сегодня ведется более (оценка навскидку) 98% всей разработки продуктов для конечного пользователя, лишены примитивов представления AST и параллельного (не путать с асинхронным) исполнения.

Когда к нам пришел докер и — как тот муж из анекдота — перее^W научил нас отказоустойчивости на свой манер, я написал бесчисленное количество костылей, чтобы действительно отказоустойчивый (а главное, долгоживущий) код продолжал нормально работать в условиях, где сброс горячего кэша из-за внезапного перезапуска контейнера, вызванного близостью Андромеды к Меркурию, — норма.

Потом какому-то гению из соседнего отдела пришла в голову блистательная мысль использовать consul в качестве единого конфигурационного хранилища, некоторые ошметки локальных конфигов по-прежнему валялись в редисе, каждый микросервис выдумывал свою систему легкой раскатки и предпочитал автономно управлять конфигурацией из локальных переменных среды, и в этом зоопарке, разумеется, начали возникать конфликты на почве видово́й борьбы за выживание (ласково именуемой в народе «кто первый встал — того и тапки»).

С этим надо было что-то делать, и я написал библиотеку на обоих используемых тогда в компании языках (руби и эликсире), позволяющую поддерживать общую конфигурацию приложения из нескольких источников, обновлять её в режиме реального времени через изменение этих самых источников (поменял значение в консуле/редисе/локальном джейсоне — и оно автоматически обновилось в конфиге, а уведомления разослались всем заинтересованным).

Введение: Архитектурное дежавю

Вы когда-нибудь замечали, как цифровой мир движется по спирали? В 2018 году я, размахивая Dockerfile и Helm-чартами, внедрял микросервисы на C# с RabbitMQ — всё ради священной цели «низкой связанности». А через три года, переключившись на Angular, с ужасом осознал: фронтенд-компоненты общались через цепочки Input/Output, словно это 2005-й, а мы пишем WinForms.

Это как собрать космический корабль, но управлять им через телеграф. На бэкенде мы гордо декларируем event-driven architecture, а на фронтенде компоненты перешёптываются через пропсы, будто подростки на школьной дискотеке. Ирония? Чем сложнее становились наши системы, тем больше они напоминали те самые монолиты, от которых мы бежали в мире backend.

Когда мы думаем об играх, почти автоматически предполагаем, что у них есть цель. Победить. Пройти. Достичь чего-то. Но в последние годы на поверхность выходит другой подход — игры, в которых нет привычной структуры выигрыша и проигрыша, игрока не торопят, не оценивают и не говорят, когда он «молодец». Это не баг, а фича — и именно такая, которая говорит о взрослении индустрии.

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

Используем силу уравнений Ньютона и численных методов для моделирования динамики простых плоских мешей в реальном времени! В конце вы сможете моделировать падение ножниц ✂️ как на анимации

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

Хочу сразу пояснить, что я лично пишу на Go уже около 10 лет и уходить от него не планирую. Но тем не менее мне интересно мнение других разработчиков, которые работают или работали с Go на больших проектах. Во многом я согласен с недостатками Go, описанными ниже, так как сам сталкиваюсь с этими проблемами и на не самых больших проектах. Вот мой перевод статьи.