В исследовании языков программирования меня всегда наиболее привлекала их разработка.

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

Однажды на собеседовании меня попросили привести примеры написанного мной кода: один — которым я наиболее горжусь, и другой — который я считаю наиболее неудачным. Недолго думая, я осознал, что на оба вопроса у меня готов ответ, и это один и тот же фрагмент кода. Горжусь я им потому, что, пожалуй, из всей моей практики именно этот код оказался наиболее весом, а стыжусь из-за него, так как, по мнению большинства из его читателей, этот код начался с костыля, который затем стали развивать: 

Примерно в 2012-2013 году в сообществе сисадминов стали много говорить о технологии под названием «Borg». Складывалось впечатление, что это какая-то система управления контейнерами, основанная на Linux и применяемая в Google — с её помощью они эксплуатируют свои внутренние ресурсы. Терминология по этой системе немного озадачивала; внутри кластеров, состоящих из «ячеек» (cells), в ней находились какие-то «борглеты», но суть уже на данном этапе начинала ускользать. В системе существовали концепции «сервисов» (services) и «заданий» (jobs), так, что приложения могли при помощи сервисов откликаться на пользовательские запросы, после чего система собирала задания в пакеты, и эти пакетные задания уже выполнялись достаточно долго.

Затем 7-го июня 2014 года состоялся первый коммит в Kubernetes. Это греческое слово означает «кормчий», и в течение первых трёх лет существования этой технологии решительно никто не понимал, как его правильно произносить. Поэтому пришлось сдаться и позволить простым смертным обозначать его как k8s.

Я постарался охватить только основы, но текст всё равно получился очень длинным.

libriscv — это зрелый эмулятор RISC-V, который в настоящее время используется в игровых движках. Насколько мне известно, это единственный эмулятор, в котором основной акцент делается на обработке задержек, а также предоставляются специализированные решения и инструменты для выполнения быстрых вызовов при обращении с функциями — как входящих, так и исходящих. Причём, всё это заключено в безопасной песочнице. Задержки, наблюдаемые в libriscv,  гораздо ниже, чем в эталонных эмуляторах.

Меня многие спрашивали, как им пользоваться, но здесь интереснее то, как вообще может прийти в голову мысль писать скрипты на C++ — не слишком ли сложно это будет? Оказывается, нет, не очень. Вот уже несколько лет я пишу на C++ скрипты для одной большой и одной не очень большой игры, и меня почти не посещало ощущение, что виной каким-то возникающим при этом проблемам являются язык C++ или связанные с ним скриптовые API. Я много лет программирую на Lua, а до этого пользовался обычным C. Но сейчас современный идиоматический C++ — то, что мне нужно. Причём, я могу писать на этом языке как в самом игровом движке, так и за его пределами, при этом опираясь (буквально) на одни и те же абстракции и оперируя одинаковыми структурами данных. Наконец, C++ просто очень мощный. Правда, я признаю, что о вкусах не спорят, и при работе с C++ также не обойтись без компромиссов.

Усаживайтесь поудобнее, ребята! Сегодня мы с вами разберём следующий увлекательный вопрос: что будет, если заинлайнить вообще всё?

Если вы пока не знакомы с техникой встраивания (inlining) то примите к сведению, что в сообществе специалистов по разработке компиляторов многие, в том числе очень авторитетные фигуры (например, Чендлер Каррут) считают этот приём наиважнейшим при оптимизации компиляторов. Подробнее о том, как устроено встраивание, рассказано здесь — мы беззастенчиво хвалимся той презентацией, с которой выступили перед участниками конференции LLVM Developers' Meeting по межпроцедурной оптимизации. Я рассказывал о встраивании и очень рекомендую вам посмотреть хотя бы первые 6 минут. В этом видео я рассказываю, почему встраивание — очень простое преобразование, а вот тут вашему вниманию предлагается реализация встраивания, предложенная великим Крисом Латтнером уже около 20 лет назад — в ней всего около 200 строк кода. К сожалению, сегодня даже само преобразование пропорционально выросло: в качестве примера взгляните хотя бы на InlineFunction.cpp.

В вышеупомянутом видео я рассказываю, что у встраивания есть свои недостатки. Иными словами, встраивание позиционируется как супер-пупер инструмент в арсенале компиляторщика, но пользоваться этой штукой следует с осторожностью. И следует ли вообще?

Два варианта абстрактного синтаксического дерева (AST) для выражения a * b + c.

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

Многие по-разному понимают, что такое арены или регионы, поэтому здесь я собираюсь называть интересующую меня разновидность этих структур данных «выровненной», а сам процесс — «выравниванием» (flattening). Выровненная арена содержит всего один тип, то есть, в сущности, это обычный массив. В таком массиве можно обойтись индексами, тогда как обычно для работы с массивом требуются указатели. Здесь мы поговорим прежде всего о выравнивании абстрактных синтаксических деревьев (AST), но вообще описанная идея применима с любой структурой данных, отягощённой указателями.

Чтобы изучить выравнивание, мы дважды напишем простейший интерпретатор: сначала как обычно, а затем с применением выравнивания. Логика поста прослеживается по коду из этого репозитория, где можно сравнить две ветки. Здесь важнее всего отметить, что изменения минимальны, но при этом микробенчмарки показывают, что после выравнивания код работает в 2,4 раза быстрее. Благодаря выравниванию не только повышается производительность, но и сам код становится эргономичнее, на чём я также остановлюсь.

В этом посте описана одна из причин, по которой растёт расход памяти и возникают утечки, что при работе под Windows может приводить к исключениям OutOfMemoryException. Проблема может возникать после того, как приложение обновится с версии .NET 6 или ниже до .NET 7 или выше, но также встречается и в новых или необновлённых приложениях.

Мне не раз приходилось сталкиваться с данной конкретной проблемой, когда я работал в техподдержке. Поскольку я отвечаю, в основном, за веб-составляющую приложений, мне такие вещи встречались только в приложениях ASP.NET. Однако, эта проблема характерна не только для ASP.NET Core и может произойти в любом приложении под .NET.

Она может возникать в .NET 6 и ниже, но чётче проявляется и лучше просматривается в .NET 7 и выше. Дело в том, что в этих версиях .NET иначе, чем прежде, обращается с блоками памяти, отводимыми под кучи для сборщиков мусора. Разница такова: в .NET 6 и ниже (а также в .NET Framework) используются сравнительно крупные сегменты, для каждой кучи — свои. А в .NET 7+ для этой цели применятся более мелкие регионы, доступные для повторного использования. Если вы хотите подробнее почитать о сегментах и регионах, посмотрите пост от Маони Стивенс, которая занимается архитектурой сборщика мусора в .NET: https://devblogs.microsoft.com/dotnet/put-a-dpad-on-that-gc/

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

Недавно мне попался следующий твит от OneHappyFellow:

Кажется, я понял, что меня настолько напрягает при программировании на языках с динамической типизацией. Дело в том, что никогда нет уверенности, будет ли конкретная библиотека работать определённым образом, и не сломается ли код при очередном минорном обновлении версии.

— One Happy Fellow (@onehappyfellow) 5 мая 2025

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

В прошлом году, просматривая пул-реквесты по поводу компилятора Rust, я обратил внимание на #126013. В нём к некоторым пакетам компилятора добавлялась проверка unreachable_pub. Естественно, меня это заинтересовало, так как на тот момент я о такой проверке не знал. Но, разобравшись с её описанием, я тем более удивился, так как эта проверка показалась мне абсолютным нонсенсом! Поговорив об этом с авторами пул-реквеста, я осознал, что, пожалуй, достаточно странно представляю себе, как устроена видимость в Rust. Как минимум, я воспринимал её не «так, как она была задумана».

Эта тема показалась мне достаточно интересной, чтобы раскрыть её в блоге. В этой статье я коротко объясню, как именно работает видимость в Rust, а потом опишу два достаточно разных способа её использовать. Если вы знаете, как в Rust устроена видимость, можете смело пропускать введение и переходить к главной теме. Оговорюсь, что в этом посте я просто вывалил различные мысли на данную тему, скопившиеся у меня, так что не ожидайте найти здесь каких-либо супер-откровений :).

Odin — это универсальный язык для системного программирования, придуманный Биллом Холлом aka «gingerBill». Odin задумывался как современная альтернатива C, и в нём делается акцент на простоте, производительности и удобочитаемости, но при этом не упускается контроль над низкоуровневыми деталями.

На сайте об этом языке Odin охарактеризован как «ориентированный на данные», именно поэтому в нём присутствуют, например, структуры массивов (SOA) и неявная инициализация значения в ноль. Удивительно, что, несмотря на такие приоритеты, в языке есть динамические словари и массивы, встроенные в сам язык. Притом, что памятью всё-таки приходится управлять вручную, такие встроенные вещи встречаются нечасто.

Возможно, вот те самые черты, придающие Odin собственный облик: язык задуман как эргономичный, такой, на котором удобно писать, и поэтому многое предоставляет «из коробки». Также в Odin предусмотрен «вендор», в котором содержатся привязки к разнообразным популярным библиотекам. Поэтому вкатываться в язык очень просто.

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

Раз в несколько лет я устраиваю в нашей исследовательской группе челлендж «Напиши медленный код». Цель – написать код с минимально работоспособным количеством инструкций на цикл (IPC) с условием, чтобы этот код выполнялся на заранее подобранном сервере с архитектурой x86.

На первый взгляд, это абсурд В сущности, так и есть. Однако есть в этой безумной задаче и некоторая методическая ценность. Инженеры, проектирующие процессоры, прилагают все усилия ради достижения наивысшего возможного IPC… даже для очень неэффективного кода. Так и задумано, что писать код с очень высоким показателем IPC непросто. Следовательно, челлендж «Напиши медленный код» оказывается заковыристым упражнением, вынуждающим задумываться, как именно работает процессор, и как применить себе на пользу его острые углы.

Страшно вспомнить, сколько часов в день я проводил, работая в терминалах Unix и выполняя команды оболочки. По какой-то причине у разных людей сноровка при работе с оболочкой разительно отличается. Я знаю тех, кто даст мне в этом сто очков вперёд. В то же время, попадался мне один профессионал на зарплате, не знавший, что достаточно нажать клавишу «вверх», чтобы выяснить предыдущую команду.

Я неслучайно привёл такой пример: те команды, которые нам, как правило, приходится выполнять в оболочке, то и дело повторяются. Мне обычно доводится иметь дело с 50-100 уникальными (т.e., синтаксически неидентичными) командами оболочки в типичный рабочий день. Но среди этих команд можно выделить и крошечную подгруппу (напр., cargo test) таких, которыми я пользуюсь сотни раз в день.

Однажды клиент обратился ко мне с вопросом о застарелом, но частом зависании, причину которого никак не удавалось выявить. Насколько можно было судить, поток пользовательского интерфейса направлял вызов в ядро, и этот вызов просто зависал без видимых причин. К сожалению, в дампе ядра не выводился  стек пользовательского режима, поскольку стек был вытеснен из памяти. Причём, это логично: ведь зависший поток не использовал свой стек. Поэтому, как только в системе возникал дефицит памяти, этот стек из памяти вытеснялся.  

Наверное, я очень опоздал с изучением CUDA. До недавнего времени даже не знал, что CUDA — это просто C++ с небольшими добавками. Если бы я знал, что изучение её пойдёт как по маслу, я бы столько не медлил. Но, если у вас есть багаж привычек C++, то код на CUDA у вас будет получаться низкокачественным. Поэтому расскажу вам о некоторых уроках, изученных на практике — возможно, мой опыт поможет вам ускорить код.

Доводилось ли вам раскупоривать системник с Linux, который не грузится ни в какую – даже  после того, как вы убедились в корректности настроек BIOS и в том, что никаких серьёзных аппаратных ошибок в машине нет?

Если да – то вам просто необходимо изучить chroot. Он станет для вас настоящей палочкой-выручалочкой.

Например, мне пару недель назад удалось таким методом восстановить устройство Nanopore GridION, после того, как мне совершенно не помог официальный метод переустановки через  .iso-файл образа. Поэтому я решил задокументировать проделанные шаги.

Этот метод я нащупал только после того, как Linux более десяти лет был моей рабочей лошадкой (спасибо, Мэтт !). Поэтому у меня есть основания полагать, что этот метод очень полезен и заслуживает вашего внимания. Надеюсь, этим постом мне удастся помочь тем, кому не доставало такого рассказа.

Пишу этот текст совершенно без намерения оскорбить авторов Excel. Это фантастически успешный софт, который по праву считается золотым стандартом среди табличных редакторов. Тем не менее, в этом году Excel уже стукнуло 40. В таком почтенном возрасте его семантика всерьёз страдает из-за костылей, которые накапливались не один десяток лет, обеспечивая обратную совместимость.

Одно из самых интересных дел, которыми мне приходится заниматься на работе — это обратная разработка Excel. Я выискиваю причуды в его поведении и решаю, как поступать с ними в нашем фирменном табличном редакторе. Благодаря моему повседневному труду, наши пользователи, возможно, и не подозревают, сколько недокументированных грехов совершила Microsoft ради совместимости. Приглашаю вас одним глазком взглянуть на те ужасы, с которыми мне приходится тягаться — и тогда вы тоже станете бояться Microsoft Excel — не потому, что чего-то не знаете, а наоборот, так как знаете слишком много.

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

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

Именно такие ожидания я связывал с Next.js — опенсорсным фреймворком для веб-разработки, созданным и управляемым компанией Vercel. Vercel — это облачный провайдер, предлагающий управляемый хостинг Next.js как услугу.

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

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

В течение последнего полугода команда Discord по обслуживанию медиа-инфраструктуры модернизировала конвейер обработки изображений, добавив поддержку анимированных форматов WebP и AVIF. Теперь на платформе можно делиться анимированными картинками WebP и AVIF как в виде прикреплённых файлов, так и в виде вставок. При этом все эмодзи выдаются в виде анимированных WebP — и бесшовно отображаются на любой платформе Discord. Эти изменения были реализованы для того, чтобы повысить качество анимации и воспроизведения роликов на всех платформах. При этом одновременно резко уменьшается размер файлов, и поэтому их загрузка ускоряется!