Системный архитектор
C++ has trapped itself in an evolutionary dead end due to backward compatibility and UB, and the only realistic successor capable of displacing it in large codebases will be a transpiler that generates C++ and enables gradual, low-risk adoption.
Это перевод на английский язык статьи моей статьи Ахиллесова пята C++ и будущая р̶е̶ эволюция
Недавно я опубликовал мнение о фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должна способствовать) массовому переходу с C/C++ на «безопасные» языки программирования Экономика безопасности кода или почему Rust не нужен.
Но чтобы оставаться честным перед читателями, решил опубликовать и статью-контраргумент с описанием обратной стороны медали, то есть почему C++ всё равно будет рано или поздно заменён, а заодно попробовать разобрать, каким будет новый язык программирования, который неминуемо придёт на смену C++.
Привет, Хабр!
Если не читали предыдущие статьи — кратко: в РФ сейчас работают белые списки (а мы не знали) подробнее тут, ТСПУ работает в режиме drop‑all, пропуская только одобренные IP + SNI.
Обходилось это легко — покупаешь VPS у VK/Timeweb/Яндекса, получаешь подсеть которая есть в белых списках, поднимаешь VLESS.
Только вот скоро это перестанет работать.
Статья о том, как настроить точечный обход блокировок по нужным доменам на роутере с OpenWrt. На мой взгляд, это самый удобный способ, который можно реализовать сейчас.
Я предоставляю уже готовый конфиг с самыми востребованными доменами, который можно дополнять.
Настроить роутер можно с помощью скрипта. Если вдруг не заведётся сразу, то другим скриптом можно найти, что не работает. Настройка с помощью Ansible никуда не делась, только модифицировалась и стала лучше.
Помимо инструкций по настройке туннелей Wireguard и OpenVPN, написал инструкцию по использованию технологий, которые помогут в обходе блокировок по протоколу: Shadowsocks, VLESS и прочими.
Прочитал статью Параллелизм с общим состоянием в Rust и обратил внимание, что её общий смысл можно выразить известной фразой: “делай как нужно, а как не нужно, делать не нужно”. Другими словами, это точно такой же совет, какой можно дать разработчику любого другого языка программирования, например С++.
И решил не продолжать дискуссию в комментариях, а написать отдельную статью с кратким описанием фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должно способствовать) массовому переходу с C/C++ на «безопасные» альтернативы. Так как из-за особенностей распределения затрат у разработчика ПО отсутствует экономическая мотивация к полному устранению ошибок, и как следствие - к переходу на использование «безопасных» языков программирования.
Со мной случилась ситуация, в которой особенно неприятно признаваться. Хоть я и технарь с опытом работы в ИТ, включая информационную безопасность, но какое-то время я был действительно уверен, что разговариваю с сотрудником Социального фонда России (СФР).
Уверен настолько, что после окончания разговора я уже начал делать черновик гневной статьи для Хабра: что бизнес‑процессы СФР (т.е. фактически самого государства) обучают людей быть удобными жертвами мошенников.
Потому что всё выглядит как обычная бюрократическая рутина, а значит мошенникам остаётся только изменить один единственный кусок пазла… Однако вся ирония в том, что пока я писал черновик разгромной статьи, до меня дошло: а ведь это реально были мошенники!
После этого я уже писал заявление в полицию, а потом пришлось переписывать и саму статью, но уже не про «как плохо устроен бизнес‑процесс в СФР», а про ещё один рабочий сценарий социальной инженерии, который звучит слишком правдоподобно даже для неплохо подкованного ИТ специалиста.
В ИТ есть странная форма «информационной инерции»: когда фраза однажды удачно легла на реальность, стала цитатой, превратилась в маркер «своего» - и дальше продолжила жить сама по себе. Реальность уехала, практики сменились, инструменты стали другими, экономика разработки перевернулась, а штамп формулировки остался. И особенно охотно её повторяют те, кому нужно писать быстро и убедительно, но нет времени (или компетенции) разбирать в технических деталях.
И проблема не в том, что старые тезисы изначально были бессмысленными. Проблема в том, что их продолжают подавать как вечные законы природы - без даты, без контекста и без поправок на то, что индустрия в корне изменилась.
Например, фразы про “серебряную пулю” и "небезопасный С++ ", которые звучат почти в каждом популярном тексте о разработке и безопасности, и оба часто переворачиваются так, что становятся откровенной неправдой.
Anthropic забыли добавить *.map в .npmignore — и весь исходный код Claude Code оказался в открытом доступе через npm. Тамагочи в терминале, система снов для консолидации памяти, режим прикрытия для коммитов в open-source, 30-минутные сессии планирования на удалённом Opus 4.6, мультиагентный рой с координатором — и всё это спрятано за feature flags, которые source map’ы радостно проигнорировали. Разбираем, что нашлось внутри.
Я работаю разработчиком. Каждый день пишу код, ревьюю PR, хожу на стендапы. Обычная жизнь в 2026 году — только за последние полтора года она изменилась сильнее, чем за предыдущие пять.
Cursor, Claude Code, Copilot. Коллеги из западных команд говорят, что скорость разработки выросла в два раза. Не в полтора — в два. Это не хайп, это реальные цифры от реальных людей.
А потом закрываешь ноутбук и понимаешь: большинство этих инструментов в России либо не работают нормально, либо требуют VPN который отвалится в самый неподходящий момент, либо стоят $20 в месяц которые ещё надо как-то оплатить иностранной картой.
Это меня достало. Поэтому я сделал своё.
Решил на днях приобрести корпус для апгрейда компьютера. И выбор пал не на интернет-магазин массовой торговли, а на обычный офлайн-магазин DNS, так как цены на его отдельные товарные позиции дешевле, чем в Озоне, более чем вдвое. Тем более в нашем городе получать товар в Озоне или Валдберис нужно идти ножками в ПВЗ и нести его домой самостоятельно, а у DNS есть доставка до двери.
И все было бы хорошо и не было бы текущей статьи, если бы я не выбрал "доставку курьером" и способ оплаты "по карте при получении товара". В результате меня чуть не развели как лоха.
Точнее, это я думаю, что меня попытались развести, а на самом деле, может быть, никакого развода не было, и это пошла такая тенденция - прикрываться якобы блокировками интернета, предлагать непонятные и крайне сомнительные способы безналичной оплаты.
История о том, как военкомат собирался применить ко мне ограничительные меры, несмотря на то, что в военкомат я явился (также был риск, что меня доставят в военкомат полицейские - для составления протокола). И как я обжаловал их намерения (на данный момент ограничения не введены и информации о таких намерениях тоже больше нет).
29.11.2025 я получил СМС от номера 117 с текстом: "Вам направлена повестка в военкомат. Ознакомиться: реестрповесток.рф".
По закону возможные ограничение за неявку по повестке (согласно статьи 7.1 Закона №53-ФЗ "О воинской обязанности и военной службе"):
‣ запрет выезда из страны;
‣ запрет на государственную регистрацию физических лиц в качестве индивидуальных предпринимателей;
‣ запрет на постановку на учет в налоговом органе физического лица в качестве налогоплательщика;
‣ приостановки на постановку недвижимого имущества на государственный кадастровый учет и (или) государственную регистрацию прав;
‣ ограничения права на управление транспортными средствами;
‣ запрет на государственную регистрацию транспортных средств;
‣ отказ в заключении кредитного договора, договора займа.
tldr: ИБП использует Modbus (а не Megatec/Voltronic), параметры BAUDRATE = 9600, DEVICE_ID = 10, START_ADDR = 30000.
У меня была задача - купить ИБП для домашней системы хранения / homelab сервера.
Идея была купить что-то не слишком дорогое, с возможностью подключения внешних АКБ и мониторинга через стандартный протокол NUT (Network UPS Tools, стандартный протокол по которому можно мониторить UPS в linux, NAS типа Synology и т.д.) .
Практическое руководство по итогам анализа заявок прошлого года
Каждый год Call for Papers (CFP) на PHDays Fest собирает сотни заявок. В прошлом году их было 825 – и это хороший индикатор не только популярности фестиваля, деловую программу которого посещает несколько десятков тысяч человек, но и уровня конкуренции. При этом отклонено было более 500 заявок, а принято – лишь около трети от рассмотренных. Это означает простую вещь: качество заявки критично. Даже сильная тема может «не доехать» до сцены и быть отбракованной программным комитетом, если она плохо упакована.
LangChain или LangGraph? Какой фреймворк для ии-агентов выбрать? А может быть LangSmith? Или LangFuse? LangFlow? Если вы сходу не отличаете все эти Lang-что-то там между собой или просто хочется побольше узнать о внутренностях LangChain и LangGraph, то добро пожаловать в эту статью, которую мне хотелось сделать фундаментальной, чтобы ответить сразу на все возникающие вокруг LangChain вопросы.
Поговорим про архитектурные различия между LangChain и LangGraph, их подходы, посмотрим как это выглядит в коде, поищем лучшие точки применения и взглянем на сформированную экосистему вокруг.
На самом деле, мы, как ИТ специалисты, так и конечные пользователи довольно сильно привыкли к западным программным решениям за последние несколько десятков лет. Известные вендоры заполонили рынок информационных систем и технологий, начиная от Microsoft, Oracle, SAP, завершая SAS. В голове мелькала мысль: зарубежное, значит качественное и общепризнанное, довольно часто игнорируя тот факт, что есть и наше, отечественное программное обеспечение, в которое нужно инвестировать и которое требуется развивать. Казалось, что западные программные продукты безальтернативны, ведь их внедряют во многие предприятия, в том числе и государственный сектор. Особенно это касалось программных решений SAP, несомненно, линейка продуктов вендора обладает качеством, устойчивостью и масштабируемостью, однако инициативы вокруг SAP в какой-то момент превратились из средства реализации в самоцель. Выпуская программные решения на каждый чих, постоянно обновляя продукты до более совершенных версии, SAP-проекты превратились в успешный бизнес, дающий выгоду не столько конечным пользователям, сколько руководству и компаниям интеграторам. Сейчас же нам предстоит вернуться с небес на землю, вспомнить, что такое кастомная разработка и отечественные программные решения, чтобы занять ту нишу, что оставили за собой, уходя, зарубежные вендоры. В связи с этим, разберемся, что нужно делать для вывода нового программного решения на российский рынок.
Основными документами, описывающими план действий реализации корпоративных целей предприятия служат:
Развивая идею доверенного языка программирования я пришел к выводу, что за счет ограничений синтаксиса и создания соответствующих проверок в статическом анализаторе кода, можно защититься практически ото всех технических ошибок, кроме двух - контроль динамически выделяемой памяти и переполнения стека.
Причем, если для подсчета ссылок в рантайме, решения существуют, то контроль переполнения стека невозможно сделать не только во время анализа исходного текста программы, но это практически невозможно и во время выполнения приложения! Ведь ошибка переполнение стека (stack overflow) - это всегда фатально, так как не существует способа поймать и обработать эту ошибку изнутри выполняемой программы, чтобы потом продолжить её выполнение как ни в чем не бывало.
Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?
Среди почти 800 заявок конкурса технических статей Технотекст 7 было буквально меньше десятка статей, в создании которых принимал активное участие искусственный интеллект. Решиться на Технотекст 8 было сложнее: ИИ-фрагменты встречаются часто, Песочница переполнена нейрослопом, на Хабре нет-нет, да появится полностью сгенерированная статья. Мы, конечно, шутим (со значительной долей правды) на тему: «Ну как-то же вы писали до ИИ?», но горячие дискуссии о допуске промптов к созданию текстов для Хабра не умолкают даже в специальных авторских сообществах. И всё же мы решились провести ещё один конкурс без ИИ. Встречайте — Технотекст 8.
Давно хотел написать подобный текст, но все никак не доходили руки. А вот после завершившегося летнего заседания комитета по стандартизации C++ и поднявшегося воя о том, что сложность языка еще больше увеличилась, пришлось таки изыскать время и зафиксировать собственные мысли на этот счет.
Текста будет много, поэтому тех, кому не жаль своего времени, приглашаю заглянуть под кат.
Некоторое время назад довелось прочесть интересную книгу «Дилемма инноватора». Там на примерах технологичных продуктов показывается, как возникают новые продукты, которые сперва проигрывают доминирующим сейчас на рынке решениям, а затем кардинальным образом меняют состояние рынка.
Один из самых ярких примеров: цифровая фотография, которая в 1990-х была вообще никакой, но спустя всего 20 лет привела к краху такого монстра XX-го века, как Kodak (который, кстати говоря, первым и сделал прототип цифровой камеры).
Исходный вариант этого опуса я написал еще в 2019 на другом ресурсе. Он планировался как вялый ответ на поток совершенно незаслуженной критики, направленной на такое свойство языка, как Variable Length Array (VLA). Поток обладал свойствами типичной эхо-камеры и пытаться противостоять ему было бесполезно. Однако относительно недавно я с удивлением узнал, что выходящий вскорости стандарт C23 встал на ту же самую точку зрения, которой придерживаюсь в этом вопросе и я: в C23 поддержка VLA снова становится обязательной, а опциональной остается лишь возможность объявления локальных VLA. Я, разумеется, ни в коем случае не претендую на то, что мои разглагольствования на эту тему сыграли какая-то роль в принятии этого эпохального решения. Состояние дел в С23 я упоминаю лишь потому, что оно воодушевило меня опубликовать здесь несколько причесанную версию этого текста, даже если теперь VLA не нуждаются в чьей-либо защите.
Недавно написал статью о проблемах использования ИИ (Иллюзии Интеллекта) при разработке программного обеспечения / Хабр, и решил не ждать у моря погоды, когда (и если) провайдеры исправят ситуацию на своей стороне, а попытаться самостоятельно выработать приемлемый алгоритм работы с ИИ, который был бы экономически выгодным и целесообразным при разработке ПО хотя бы лично для меня.
Данная статья - это очередной Хабрахак с подведением итогов и получением обратной связи об использовании ИИ-помощников при разработке программного обеспечения с примерами кода и итоговыми выводами о целесообразности использования ИИ в том или ином проекте.
А также поделюсь неожиданным инсайдом, который я случайно обнаружил в процессе работы над ИИ-кодом, который будет очень полезен матёрым программистам, которые до сих пор скептически относятся к использованию ИИ в своих проектах.