C++ умеет ровно то, за что его одновременно любят и боятся: дает разработчику почти полный контроль над происходящим, позволяет выжимать из программы максимум производительности, но при этом оставляет возможность столкнуться с ошибкой, которая проявится только через несколько часов или даже дней работы. На C++ строят высоконагруженные системы, движки, embedded-решения и инфраструктуру, хотя рядом уже много лет развиваются Go, Rust и другие языки, которые обещают сделать разработку проще и безопаснее.

Так зачем учить C++ в 2026 году? Насколько важно программисту разбираться в памяти и устройстве процессора? Почему сильных C++-разработчиков по-прежнему мало, хотя язык преподают в университетах? Где без C++ действительно сложно обойтись, а где бизнесу выгоднее выбрать Go и при необходимости добавить серверов? Сможет ли Rust потеснить C++, как нейросети меняют работу программиста и почему современному разработчику уже недостаточно просто знать синтаксис?

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Малковым — C++-разработчиком, бывшим сотрудником Яндекса и CTO компании «Вертикаль». Александр также ведет свой телеграм-канал «Thread of Thoughts | Поток мыслей», где делится материалами и наблюдениями из профессиональной практики.  

Разговор получился не только про сам C++, но и про то, что сегодня требуется от сильного разработчика. Мы обсудили userver и падения продакшена, высокие нагрузки и работу с памятью, HFT и геймдев, компиляторы и санитайзеры, работу с legacy-кодом, а также влияние ИИ на профессию. Поговорили о нейросетях в роли своеобразного «джуна на ревью», выгорании в Big Tech и о том, в каких задачах глубокое понимание устройства системы по-прежнему важнее знания конкретного языка.

Отдельно разобрали, стоит ли сегодня идти в C++, кому этот язык действительно подходит и в каких направлениях его знание по-прежнему дает разработчику серьезное преимущество.

Александр: C++ сегодня по-прежнему актуален или постепенно становится менее востребованным?

Александр Малков: Я бы сказал, что актуален. Но всегда нужно смотреть, в каких сферах, для каких задач и зачем он вам нужен. В целом я придерживаюсь позиции, что главное – не язык, а разработчик: как человек мыслит, как чувствует систему, как пишет код и как подходит к решению задачи. Язык – всего лишь инструмент.

Александр: Как вы сами пришли в C++? Это всё-таки не самый очевидный первый язык.

Александр Малков: C++ действительно не был моим первым и единственным языком. Путь получился довольно долгим: ещё в школе были QBasic и Turbo Pascal. Однажды в детстве мне подарили книгу «C++ за 21 день». Я открыл её, почитал и понял, что вообще ничего не понимаю. Решил, что вернусь к ней позже.

Потом смотрел множество уроков. Тогда ещё можно было через DC скачивать из локальной сети разные видео и материалы. Постепенно я вырос в программировании, попробовал PHP, Delphi и другие вещи, а уже в более осознанном возрасте вернулся к C++ и погрузился в него полностью.

Александр: Что помогало изучать язык? Книги, сайты, видео?

Александр Малков: В первую очередь интернет. Есть, например, cppreference – практически справочник по языку и стандартной библиотеке, куда можно прийти и найти описание нужной функции или конструкции. Есть экспертные книги – уже не базового уровня, а те, которые позволяют глубоко погрузиться в язык. Например, книги Александреску, Мейерса и других известных авторов.

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

Александр: А если человеку гораздо легче учиться по видео? Обязательно заставлять себя читать книги?

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

Нет одного обязательного способа получать знания. Главное, чтобы вы не ограничивались пассивным просмотром. C++ нужно пробовать руками.

Александр: У вас есть высшее образование?

Александр Малков: Да. Я окончил Пензенский государственный университет.

Александр: По специальности, связанной с программированием?

Александр Малков: Прикладная математика и информатика.

Александр: В 2026 году, когда программирование быстро меняется и появились нейросети, высшее образование разработчику вообще нужно?

Александр Малков: Здесь тоже всё зависит от человека. Хорошее высшее образование даёт определённую базу: учит думать, работать с фундаментальными понятиями, формирует математический и инженерный аппарат. Но есть другая проблема. Человек может окончить университет, четыре или пять лет что-то писать на C++, а потом прийти на реальный проект и практически не уметь программировать. Потому что реальная инфраструктура, архитектура, процессы разработки и промышленный код сильно отличаются от университетских задач. Поэтому при найме наличие высшего образования для меня не ключевой фактор.

Александр: Кого тогда вы скорее взяли бы: самоучку, который уже умеет делать реальные вещи, или отличника после вуза с хорошей теорией, но без практики?

Александр Малков: Всё зависит от задачи. Допустим, у меня есть проект, связанный с высшей математикой и ML. Тогда возникает вопрос: сможет ли самоучка вытянуть необходимую математическую часть или здесь особенно полезен человек с хорошей фундаментальной базой? То есть диплом сам по себе ничего не гарантирует, но знания, которые можно получить в университете, в некоторых областях действительно критичны.

C++ лучше изучать через сочетание теории и практики: видео может дать вход в тему, но глубокое понимание появляется, когда вы самостоятельно пишете, компилируете и разбираете код.

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

Александр: Был ли в вашей жизни проект, которым вы особенно гордитесь?

Александр Малков: Если брать технически сложные и интересные проекты, я бы в первую очередь отметил userver – C++-фреймворк, который мы делали в Яндексе для разработки веб-приложений и в первую очередь IO-bound-сервисов.

Александр: Что это означает на практике? Это что-то вроде Next.js, только для C++?

Александр Малков: Нет, это не фронтендовый, а бэкендовый фреймворк. Допустим, нам нужно сделать сервис, который принимает запросы, работает с базой данных и отдаёт JSON. Можно взять Python, Go или другой язык. Можно взять C++, но исторически для написания веб-сервера на нём требовалось довольно много обвязки.

Библиотеки существуют, но особенно сложным может быть асинхронный код: когда у вас много одновременных операций чтения и записи, большое количество запросов и высокий RPS. Одно из преимуществ userver в том, что он строился вокруг stackful-корутин; под капотом использовались Boost.Context и Boost.Coroutine2. Это позволяет писать код, который по виду остаётся достаточно синхронным и последовательным, хотя фактически выполняет асинхронную работу.

Александр: А какой проект или задача по-настоящему вынесли вам мозг?

Александр Малков: Таких задач было много во время разработки userver. Но есть ещё один интересный пример. В свободное время я люблю делать contribution в Open Source. В какой-то момент работал с LLVM – мне вообще интересно погружаться в компиляторы и сложные системы.

Я нашёл там сравнительно небольшой баг, исправил его и отправил изменение на ревью. И мне отвечают: у нас в Fortran есть похожая проблема – исправьте заодно и её этим же коммитом. Вот тогда пришлось внезапно погрузиться ещё и в Fortran.

Александр: А продакшен вы роняли? Есть известная шутка: «Не ронял прод – не эксперт».

Александр Малков: Конечно. Мне кажется, если вы совсем никогда не сталкивались с падением продакшена, то либо только пришли и ещё боитесь что-либо трогать, либо вам очень сильно повезло.

Александр: Была ситуация, из-за которой пришлось серьёзно понервничать?

Александр Малков: Неоднократно. Есть особенность разработки фреймворка: формально прод роняете не вы. Вы допускаете баг во фреймворке, после чего другие команды компилируют с ним свои сервисы, выкатывают их – и уже эти сервисы начинают падать. На userver работало очень много сервисов. Представьте: новая версия фреймворка разошлась, с ней постепенно выкатилось сто или двести сервисов, а внутри есть ошибка, которая не проявляется во время компиляции и даже первые часы рантайма может вести себя совершенно спокойно.

А затем всё начинает падать каскадом. Я, например, переписывал логер. Логирование было недостаточно быстрым, мы его оптимизировали, сделали асинхронным. И в какой-то момент я допустил ошибку – сейчас уже не вспомню точную деталь. В результате спустя время логи начали забивать диски и память, а сервисы – один за другим падать. Пришлось откатывать множество сервисов, исправлять баг и только после этого снова всё выкатывать.

Александр: Правда ли, что ошибка в C++ способна проявиться не сразу, а через несколько часов, день или даже несколько дней?

Александр Малков: Да, это правда.

Александр: Во фронтенде многие проблемы заметны практически сразу: условно, съехал элемент интерфейса – вы это увидели. В C++ всё может быть иначе?

Александр Малков: Да. Это одна из особенностей языка.

Александр: Почему?

Александр Малков: Потому что C++ даёт очень большую свободу. Вы можете напрямую работать с памятью, использовать указатели и арифметику указателей, читать данные из памяти и писать их туда. В этом и находится одна из причин его производительности: вы получаете zero-cost-подход и очень прямой контроль над ресурсами. Но расплачиваетесь тем, что некоторые ошибки становятся совершенно неочевидными. Они могут зависеть от состояния памяти, нагрузки, последовательности событий. Поэтому программа долго работает нормально, а затем возникает комбинация условий – и проявляется проблема.

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

Контроль над памятью – одновременно одно из главных преимуществ C++ и источник ошибок, которые могут проявляться далеко не в момент их появления в коде.

Александр: Если человек изучает C++, нужно ли ему сразу очень хорошо понимать устройство компьютера?

Александр Малков: Совсем не обязательно сначала изучить весь компьютер, а только потом приступать к языку. Но если вы хотите расти дальше – до middle, senior, заниматься производительностью и сложными системами, – вы всё равно постепенно столкнётесь с вопросами о том, как устроена память, как в ней располагаются данные, как она ведёт себя при многопоточности. И это касается не только C++. Возьмите Go: чтобы понимать поведение горутин под высокой нагрузкой и эффективно работать с данными, тоже полезно знать, как устроена память и почему определённая структура занимает именно столько места.

Александр: То есть новичку можно начать без этого, но дальше устройство компьютера всё равно догонит?

Александр Малков: Конечно.

Александр: Что ещё, кроме памяти, приходится изучать?

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

Александр: Речь именно о производительности программы?

Александр Малков: Да. Программы, которую вы пишете.

Александр: Как вообще понять, где она тормозит?

Александр Малков: Для этого существуют специальные инструменты. Например, можно строить flame graph – флеймграфы. На таком графике видно, где программа проводит больше всего времени и где находится узкое место. Вы смотрите: вот здесь процесс тормозит, значит, этот участок стоит исследовать и оптимизировать. Причём проблемы бывают неочевидными. Всё может долго работать нормально, а затем при определённых условиях производительность внезапно начинает деградировать.

Александр: Хотелось ли вам когда-нибудь бросить C++ и окончательно перейти, например, на Go?

Александр Малков: Как я уже говорил, язык – инструмент. Вопрос в том, как вы им пользуетесь. Сейчас я CTO, поэтому по работе мне приходится сталкиваться с разными языками: Python, Go и даже с legacy на PHP. Чем больше работаешь с разными технологиями, тем спокойнее начинаешь относиться к выбору языка.

C++ – прекрасный инструмент, если нужно выжать максимум производительности. Но в реальном бизнесе узкое место часто вообще находится не там, где вы ожидаете: например, в чтении из базы данных или сетевом взаимодействии. И тогда стоит задать практический вопрос: действительно ли нам нужно искать дефицитного C++-разработчика или проще взять Go-разработчика, который сделает этот сервис быстрее с точки зрения разработки и поддержки? Да, возможно, мы потеряем какую-то часть производительности. Но во многих проектах бизнес этого даже не заметит.

Если же речь идёт о компаниях с огромными нагрузками, где важна каждая миллисекунда, ситуация другая. Там C++ имеет гораздо больше смысла. Тем более в таких компаниях уже существуют большие кодовые базы и сильные C++-команды. Лично я люблю C++ за выразительность и за то, что одну и ту же задачу можно решать разными способами. Язык не говорит вам: «Делайте только так». Можно искать разные подходы и выбирать тот, который лучше соответствует конкретной системе.

Поэтому для меня C++ ещё и язык для души. После стандартной бизнес-логики иногда приятно погрузиться в него и написать что-то технически интересное.

Александр: Но обратная сторона свободы – чужой C++ может быть написан совершенно иначе. Легко читать такой код?

Александр Малков: Я достаточно быстро ориентируюсь. Есть разработчики, которые говорят, что не любят читать чужой код и не хотят разбираться с legacy. Но в конечном итоге вы идёте по коду: здесь вызывается функция, сюда приходят такие параметры, отсюда управление уходит дальше. Если совсем трудно понять происходящее, ставите debug-логи и смотрите, как система реально ведёт себя. Чтение чужого кода – навык, который всё равно приходится развивать.

Глубокий C++ постепенно приводит разработчика к архитектуре компьютера: памяти, кэшам, многопоточности, профилированию и реальной стоимости операций.

Производительность важна не сама по себе. Если bottleneck находится в базе данных или сети, бизнесу иногда выгоднее выбрать более простой в найме и сопровождении стек.

Александр: Где C++ сейчас особенно востребован? Игры, финтех, embedded?

Александр Малков: Я бы первым пунктом отметил HFT – high-frequency trading. Это область, где разработчики борются уже за микросекунды и в некоторых местах практически за наносекунды. Там могут очень глубоко оптимизировать работу с сетью, вплоть до взаимодействия с сетевыми картами на низком уровне.

Александр: Почему в финансовых системах это настолько важно?

Александр Малков: Я сам глубоко HFT не занимался, поэтому не хочу изображать специалиста по этой области. Но общая идея понятна: существуют торговые алгоритмы, которые реагируют на изменения рынка, и скорость реакции для них принципиальна. Если система решила, что сейчас нужно купить или продать актив, преимущество может получить тот, кто быстрее отправил и исполнил операцию. В таких задачах задержка действительно имеет денежную стоимость.

Александр: Второе очевидное направление – игры?

Александр Малков: Да, геймдев. Но здесь важно понимать, о какой части разработки идёт речь. Не только о том, чтобы нарисовать персонажа, окружение и написать игровую бизнес-логику. C++ особенно важен глубже: физика, математические алгоритмы, сам игровой движок, производительные подсистемы. Возьмите Unreal Engine – огромная часть его инфраструктуры связана с C++. Саму игру можно делать на более высоком уровне и использовать другие инструменты, но внутри движка всё равно находится производительный системный слой.

Александр: Если человек просто хочет делать игры, обязательно ли ему сразу глубоко погружаться в C++?

Александр Малков: Нет. Можно взять Unreal Engine, начать собирать игру, постепенно дописывать необходимую логику. А когда вы поймёте, что возможностей верхнего уровня вам не хватает и хочется глубже управлять физикой, логикой или движком, тогда естественным образом придёте к более сложным вещам. Я вообще сторонник линейного погружения в профессию. Не нужно брать человека, который ещё ничего не знает, и бросать его сразу в самую сложную часть проекта в надежде, что он как-нибудь выплывет.

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

Александр: Что вы посоветовали бы подростку лет пятнадцати-шестнадцати, который хочет не просто собирать игры, а разрабатывать движки?

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

Александр: Кроме финансов и игр есть embedded?

Александр Малков: Конечно. И здесь как раз особенно важна модель zero-cost. Embedded – это огромное количество устройств и чипов вокруг нас: бытовая техника, различные контроллеры, электроника и так далее. Им тоже нужно выполнять программы. Во многих подобных системах до сих пор используются C и C++, потому что разработчику важны предсказуемость, контроль ресурсов и возможность работать близко к железу.

Александр: А робототехника?

Александр Малков: Там C++ тоже встречается очень часто. Везде, где есть сочетание железа, ограниченных ресурсов, сложных вычислений и требований к производительности, для него остаётся место.

Сильные ниши C++ находятся там, где задержки, память и аппаратные ресурсы действительно имеют значение: HFT, игровые движки, embedded, робототехника и высоконагруженная инфраструктура.

Чтобы начать делать игры, необязательно сначала становиться экспертом по C++; но если вы хотите заниматься движками, физикой и низкоуровневыми системами, без математики и глубокого технического фундамента далеко не уйти.

Александр: Как сейчас оценивается C++-разработчик? Это «золотое время», когда за хорошего специалиста борются компании?

Александр Малков: Ситуация двоякая. Если мы говорим о действительно высококлассном специалисте, таких людей очень мало. Это разработчики с огромным опытом и экспертизой, которая появляется только за годы работы. Некоторые вещи невозможно получить из книги или видеокурса. Вы должны столкнуться с реальными проблемами, несколько раз ошибиться, увидеть последствия, разобраться с большими системами.

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

Александр: Получается парадокс: язык считается одним из самых сложных, а условный Go-разработчик может зарабатывать больше?

Александр Малков: Да. Одна из причин в том, что C++ до сих пор массово преподаётся в университетах. Получается большой поток выпускников: они писали алгоритмы, делали небольшие программы и выходят на рынок как начинающие C++-разработчики. Поэтому внешне кажется, что C++-специалистов очень много. А действительно хороших разработчиков при этом мало.

Александр: То есть пять-семь лет опыта уже сильно меняют положение?

Александр Малков: Конечно, но здесь снова нужно смотреть на задачу и на то, чего вы хотите от профессии. Если единственная цель – максимально быстро увеличить доход, я бы не говорил: «Обязательно идите именно в C++». Есть и другие направления.

Александр: Но C++ интегрирован в огромное количество систем. Почему тогда рынок не испытывает тотального дефицита?

Александр Малков: Потому что его распределение довольно специфично. В России, например, большие концентрации C++-разработчиков исторически возникали в крупных технологических компаниях. Там есть масштаб, высокие нагрузки, legacy, инфраструктура и задачи, которые оправдывают сложность языка. А компания среднего размера чаще смотрит на другое: насколько легко найти разработчика и кто будет поддерживать систему через пять лет.

И здесь я понимаю бизнес. Допустим, вы наняли одного сильного C++-разработчика, он построил сложную систему. А потом ушёл. Кто всё это будет поддерживать?

Александр: То есть во многих проектах простота эксплуатации важнее максимальной производительности?

Александр Малков: В большинстве обычных веб-приложений – да. Огромное количество современной разработки – это получение данных, работа с JSON, сериализация, десериализация, обращения к базе, сети и внешним сервисам. Конечно, можно сделать такой бэкенд на C++ и добиться прекрасной производительности. Но вопрос – нужна ли она бизнесу именно в этой точке.

И здесь, кстати, интересен userver с его идеей «простота Python, скорость C++». Он позволяет писать веб-сервисы, работать с JSON и базами данных, не заставляя разработчика постоянно вручную разбираться со всей инфраструктурой. Но возникает другая проблема. Человек пишет сервис на userver и говорит: «Я C++-разработчик». А если копнуть глубже – он не знает, как устроена корутина, как переключается контекст, что происходит с памятью. И под поверхностью обнаруживается огромный айсберг.

Александр: А высоконагруженный сервис обязательно должен быть написан на C++?

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

Сложность языка сама по себе не превращается в высокую зарплату. Дорого стоит не знание синтаксиса C++, а опыт решения сложных системных задач.

Бизнес выбирает не самый быстрый язык в вакууме, а баланс между производительностью, скоростью разработки, наймом специалистов и стоимостью дальнейшей поддержки.

Александр: Когда появились современные генеративные модели, многие решили, что разработчики скоро станут не нужны. Ваше отношение к этому изменилось?

Александр Малков: Вначале действительно много говорили: сейчас бизнес избавится от дорогих senior-разработчиков, посадит junior-специалистов с GPT, и те будут генерировать весь код. Но на практике картина получилась как минимум не такой простой. ИИ прекрасно снимает рутину. Я воспринимаю его как современный вид кодогенерации.

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

Александр: Но если постоянно исправлять модель, давать ей правила и накапливать контекст, разве она в итоге не научится работать именно так, как нужно вам?

Александр Малков: Контекст действительно можно улучшать. Есть rules, различные Markdown-файлы, документация и другие способы формализовать знания команды. Фактически вы переносите часть информации из своей головы в файлы, которые модель будет читать. Но вопрос: означает ли это, что модель заменила вашу экспертизу? Сам по себе набор правил ведь тоже кто-то должен создать, поддерживать и менять вместе с архитектурой.

Александр: А производительность команды при этом всё равно растёт. Условно, если раньше нужны были три senior-разработчика, с ИИ ту же работу могут сделать двое.

Александр Малков: Да, такой сценарий вполне возможен. Здесь я согласен. Не обязательно говорить о буквальной замене профессии. Но производительность труда повышается, и это влияет на необходимое количество людей. Если команда с тем же числом разработчиков теперь может сделать существенно больше, бизнес неизбежно будет учитывать это при планировании штата. ИИ в этом смысле уже меняет рынок.

Александр: Получается, нейросети скорее вскрывают эффективность команд, чем просто «заменяют программистов»?

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

Александр: А вы сами используете ИИ в ежедневной разработке?

Александр Малков: Конечно. Как я и говорил, отношусь к нему примерно как к джуну. Я всё меньше хочу механически печатать код руками и всё больше становлюсь читателем и ревьюером. Смотрю, что написал условный Codex или Claude, внимательно ревьюю, покрываю тестами.

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

Александр: Вас это до сих пор впечатляет?

Александр Малков: Да. Особенно интересно, что ИИ упростил не только написание, но и чтение чужого кода. Вы можете попросить модель проследить связи между функциями и классами, объяснить, куда передаются данные, подготовить черновик документации. А документация – традиционно больное место многих компаний. Код существует, люди с ним работают, а нормального описания может практически не быть.

Конечно, модель ошибается. Но проверять нужно всех: junior ошибается, senior ошибается, ИИ тоже ошибается.

Александр: Как теперь выглядит ваш типичный рабочий день?

Александр Малков: Очень по-разному. Иногда что-то случилось в проде – и нужно весь день разбираться. Иногда практически весь день состоит из созвонов с разработчиками, заказчиками, лидами и руководителями. Всё определяется текущим расписанием и ситуацией.

Александр: С кодом вы продолжаете работать?

Александр Малков: Да.

Александр: Но меньше?

Александр Малков: Меньше.

Александр: Не хочется иногда отказаться от созвонов и снова просто спокойно писать код?

Александр Малков: Нет, я достаточно спокойно отношусь и к одному, и к другому. Код и коммуникация – две части работы, баланс между которыми нужно поддерживать. Тем более сейчас у нас интересные проекты на пересечении ML, LLM и обычной разработки. Там есть математика, архитектура, обсуждения с людьми и технический код. Мне как раз нравится сочетание этих вещей.

ИИ смещает работу опытного разработчика от механического написания кода к постановке задачи, ревью, тестированию, архитектуре и контролю результата.

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

Александр: Вы несколько лет работали в Яндексе. Как туда попали?

Александр Малков: В значительной степени именно из-за C++. К тому моменту я уже давно писал на языке, но хотел погрузиться гораздо глубже. Хотел найти настоящий технический хардкор. Начал собеседоваться и примерно одновременно получил предложения от Сбера и Яндекса. В Сбере условия по деньгам были даже интереснее, но я выбрал Яндекс: подумал, что технически там будет более хардкорный уровень. И, кстати, не ошибся. Хардкор я там несколько раз нашёл.

Александр: Сколько в итоге проработали?

Александр Малков: Примерно три года или немного больше. Сначала я пришёл в Яндекс Еду. Там был интересный опыт с примерно десятилетним legacy на C++, к которому никто особенно не хотел прикасаться. Пришлось разгребать достаточно серьёзные баги, причём всё это происходило перед Новым годом.

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

Александр: А как сервисы вроде такси вообще довольно точно прогнозируют время прибытия? Это в основе математика?

Александр Малков: Да. В первую очередь математика и ML-модели. Есть множество факторов: расстояние, пробки, погода, исторические данные, состояние дорог и множество других параметров. Допустим, система спрогнозировала семь минут, а получилось десять. Значит, прогноз ошибся. Эти данные можно учитывать дальше и корректировать веса модели, чтобы на похожих условиях выдавать более точное значение.

Я сейчас объясняю очень упрощённо. В реальности сценариев и данных огромное количество.

Александр: Почему вы в итоге ушли?

Александр Малков: Выгорел.

Александр: Что к этому привело?

Александр Малков: Сложно выделить одну причину. У нас была прекрасная команда, очень сильные разработчики, люди действительно хотели развивать userver и вкладываться в Open Source. Проблема была скорее в постоянной смене организационного контекста.

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

А я человек, который любит погружаться в работу почти на сто процентов. Есть подход: работать на тридцать процентов, а в критический момент включать сто – и все будут восхищаться вашей эффективностью. У меня так не получалось. Я постоянно старался работать на максимуме.

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

Александр: Отпуск не помогал?

Александр Малков: Нет. Потому что если источник проблемы остаётся, короткая пауза не обязательно что-то исправляет.

Александр: Что тогда может сделать работодатель, чтобы сильные сотрудники не доходили до такого состояния?

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

Сложный legacy сам по себе может быть интересной инженерной задачей; гораздо сильнее выматывает постоянная смена организационного контекста и приоритетов.

Высокая вовлечённость – не бесконечный ресурс. Если постоянно работать «на сто процентов», даже сильная команда и интересный продукт не гарантируют защиту от выгорания.

Александр: Чем вы занялись после Яндекса?

Александр Малков: Сейчас я CTO в компании «Вертикаль». Причём познакомился с человеком из компании ещё когда работал в Яндексе. Им нужен был технический специалист. Там были реальные задачи, связанные с нейросетями для бизнеса: GPT, LLM, ML-модели, реальные заказчики, готовые платить за решения.

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

Александр: Это не Big Tech?

Александр Малков: Нет.

Александр: Почему после Яндекса не искать другой Big Tech? Для многих разработчиков это конечная карьерная цель.

Александр Малков: Здесь многое зависит от того, чего вы хотите. Big Tech привлекает брендом, масштабом, соцпакетом, интересными задачами. Но не нужно считать, что во всех случаях он автоматически означает максимальную зарплату. У известной компании есть ещё и имя: огромное количество людей сами хотят туда попасть, получить строчку в резюме и опыт. Мне в тот момент важнее было другое – возможность самостоятельно влиять на техническое направление и строить новые вещи.

Александр: Вы думали об эмиграции?

Александр Малков: Конечно. Для разработчика доступ к глобальной технологической среде важен. Документация, cppreference, зарубежные сервисы, нейросети – всё это часть ежедневной работы. Когда с доступом к ресурсам возникают ограничения с разных сторон, это усложняет жизнь инженера. Мы, например, сталкивались даже с ситуациями, когда часть инфраструктурных уведомлений была завязана на Telegram, а доступ к нему с серверов работал нестабильно. Для мониторинга это уже не бытовое неудобство: если перестали приходить алерты, вы можете просто не узнать о проблеме вовремя.

Александр: Была реальная попытка переезда?

Александр Малков: Да. Мы с женой получили DTV-визу в Таиланд и несколько месяцев жили на Пхукете. В итоге поняли, что Азия нам не очень подходит – по климату, быту, еде. Кроме того, моя работа всё равно была связана с российскими заказчиками.

Потом появились семейные обстоятельства, и стало понятно, что в Москве нам сейчас комфортнее. Кардинального желания эмигрировать и полностью менять работу у меня пока нет. Что будет дальше – не знаю. С ребёнком такие решения уже воспринимаются совершенно иначе, чем когда вы отвечаете только за себя.

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

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

Александр: Вернёмся к самому языку. Как простыми словами объяснить, что такое C++?

Александр Малков: Это высокоуровневый язык программирования и инструмент для решения определённых задач.

Александр: А чем C++ отличается от C? У многих есть упрощённое представление: сначала появился C, потом – его «новая версия» C++.

Александр Малков: Здесь интереснее посмотреть на историю. Если сильно упрощать, C находится гораздо ближе к низкому уровню. Ниже уже ассемблер. На ассемблере писать большие программы сложно: разработчику приходится держать в голове множество деталей конкретной архитектуры и машинных инструкций.

C стал одним из самых удачных способов поднять разработку на уровень выше и при этом сохранить близость к машине. Один из ключевых моментов – переносимость. У нас сегодня есть разные процессоры и архитектуры: Intel, AMD, ARM-процессоры в современных Mac и так далее. На машинном уровне всё это отличается. Но разработчик может написать исходный код на C, а компилятор превратит его в инструкции для нужной платформы.

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

Затем вокруг языка сформировалась стандартная библиотека и огромная экосистема. При этом одно из главных свойств C C++ сохранил: возможность очень близко работать с памятью. И это фундаментальная вещь.

Александр: У вас с памятью связана история из детства?

Александр Малков: Да. Когда мне было примерно одиннадцать или двенадцать лет, я заинтересовался программированием. Мне хотелось делать красивые окна и кнопки. Я нашёл знакомого программиста и сказал: «Научите меня».

А он начал рассказывать про malloc, realloc, работу с памятью. Я смотрю на него: какие malloc и realloc? Я кнопки хочу делать! Тогда я от этого убежал. И только спустя довольно много времени, когда реально столкнулся с управлением памятью, понял, зачем он мне всё это рассказывал.

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

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

Александр: Что вы думаете о Rust?

Александр Малков: Я на Rust профессионально не программирую, но язык, конечно, знаю и за его развитием слежу. На мой взгляд, это один из самых серьёзных современных конкурентов C++. У Rust тоже есть идея zero-cost abstractions и нет привычного garbage collector. При этом язык намного жёстче контролирует lifetime и безопасную работу с памятью.

Александр: Может ли Rust на длинной дистанции вытеснить C++?

Александр Малков: На очень длинной дистанции я ничего точно предсказывать не хочу. Какие-то области Rust вполне способен забрать. Но говорить, что C++ завтра просто исчезнет, я бы не стал.

Александр: Rust часто воспринимают как более простой C++.

Александр Малков: Я бы не сказал, что его главное преимущество – простота. Скорее безопасность. В C++ благодаря свободе и zero-cost-абстракциям вы можете очень легко «выстрелить себе в ногу». Rust всеми силами старается не позволить это сделать.

Он проводит множество проверок на этапе компиляции. За это приходится платить – в том числе временем компиляции и необходимостью договариваться с borrow checker. Но взамен вы получаете гораздо меньше возможностей столкнуться с некоторыми классами неявных проблем с памятью. То есть Rust не просто «C++, только попроще». У него другой компромисс между свободой разработчика и контролем со стороны языка.

Александр: Стоит ли человеку, который сегодня выбирает направление, вообще учить C++?

Александр Малков: Можно. Но первый вопрос: зачем? Нужно честно ответить себе, чего вы хотите. Где хотите оказаться через пять или десять лет? Что вам интересно делать? Язык сам по себе не должен быть целью.

Александр: А работу через три-пять-семь лет такой специалист найдёт?

Александр Малков: Я думаю, да. Во-первых, legacy никуда не исчезает. Сегодня по-прежнему существуют специалисты по Fortran, Ada и множеству языков, о которых большинство разработчиков почти не слышит. Почему? Потому что остаются компании и системы, где этот код работает и приносит ценность.

C++-кода в мире огромное количество. Какие-то позиции заберёт Rust, где-то появятся другие технологии. Но C++ ещё очень долго будет нужен хотя бы потому, что на нём уже построена колоссальная инфраструктура. При этом я всё равно повторю: C++, Go и Rust – инструменты. Важнее становиться хорошим инженером, а не человеком, вся идентичность которого строится вокруг одного синтаксиса.

Александр: То есть спрос уменьшаться может, но язык никуда резко не исчезнет?

Александр Малков: Я не думаю, что он просто куда-нибудь денется. C++ продолжает развиваться. Новые стандарты выходят примерно раз в три года: C++20, C++23, C++26. Язык движется в сторону более удобных и безопасных конструкций, комитет реагирует на проблемы и запросы сообщества. Пока язык развивается, появляются стандарты и существует активное сообщество, он жив.

Rust конкурирует с C++ прежде всего безопасностью работы с памятью, а не тем, что якобы превращает системное программирование в простую область.

C++ ещё долго будет востребован из-за огромного массива существующего кода и продолжающегося развития стандарта, но выбирать его стоит под задачи, а не ради самого названия языка.

Александр: Если рынок наполнен выпускниками, которые изучали C++ в университете, как новичку выделиться? Что нужно знать кроме самого языка?

Александр Малков: Это как раз главный вопрос: всё языком не ограничивается. Во-первых, есть разные компиляторы – GCC, Clang. Если хотите стать сильным специалистом, полезно понимать их особенности и то, какие артефакты появляются в процессе сборки. Во-вторых, нужно видеть всю экосистему C++. Это не только синтаксис и STL.

Есть огромное количество библиотек. Например, Boost – целая коллекция решений для разных задач: сети, математики, работы с данными и многого другого. Есть фреймворки – тот же userver и другие. Есть инструменты диагностики.

В 2026 году я считаю использование санитайзеров практически обязательным при серьёзной разработке на C++. Вы всё равно будете ошибаться. Будут проблемы с памятью, границами массивов, неправильным временем жизни объектов. Санитайзеры позволяют обнаруживать целые классы таких проблем гораздо раньше, чем они попадут в прод.

Если пришли в C++ ради высокопроизводительных систем, нужно уметь пользоваться профилировщиками, понимать flame graph и находить узкие места. Кроме этого есть системы сборки – тот же CMake. Есть менеджеры зависимостей, например Conan. И это только начало.

Александр: Звучит так, будто студент должен изучить целую индустрию ещё до первой работы. Это вообще реально?

Александр Малков: Нет. И в этом как раз проблема. Невозможно за время университета изучить всё, что встречается опытному C++-разработчику за много лет практики. Поэтому очень важны менторы.

Нужны опытные разработчики, готовые брать стажёров и junior-специалистов и постепенно вести их через эти сложности. Мне в Яндексе нравилось работать со стажёрами – с людьми, которые хотят изучать C++. Вы помогаете человеку увидеть не отдельные факты, а всю систему. Это путь через тернии к звёздам.

Профессиональный C++ – это не один язык: это компиляторы, STL и сторонние библиотеки, санитайзеры, профилировщики, системы сборки, пакетные менеджеры и понимание платформы.

Нельзя требовать от выпускника сразу знать весь этот стек. В сложных инженерных направлениях качественное наставничество остаётся одним из самых быстрых способов вырастить сильного специалиста.

Александр: Вы сейчас сами собеседуете разработчиков?

Александр Малков: Да.

Александр: Встречаются кандидаты с сильно приукрашенным опытом?

Александр Малков: Очень часто.

Александр: Как это обнаруживается?

Александр Малков: Иногда – уже после найма. На собеседовании вы разговариваете с человеком: он знает одно, второе, третье, прекрасно рассказывает про concurrency, понимает брокеры сообщений, у него вроде бы релевантный опыт в хороших компаниях. Думаете: прекрасный кандидат. Человек выходит на работу, проходит некоторое время – и вы понимаете, что реальный уровень совершенно не соответствует тому, который он показывал на собеседовании. Более того, иногда выясняется, что некоторые вещи, которые кандидат очень уверенно объяснял, он на практике вообще не понимает.

Александр: То есть это становится видно именно в работе?

Александр Малков: Да.

Александр: Что делать в таком случае? Человек ведь уже попал в компанию.

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

Александр: Но всё-таки бывают люди, которые проходят фильтр?

Александр Малков: Конечно. И именно поэтому одной теоретической проверки никогда не будет достаточно.

Александр: А сейчас компания продолжает нанимать?

Александр Малков: Сейчас мы тоже ощущаем сложность рынка, поэтому активного набора в данный момент нет. Возможно, вакансии появятся позже.

Александр: То есть снижение спроса со стороны бизнеса заметно?

Александр Малков: Да. У нас, например, было несколько проектов, по которым шли переговоры. И в определённый момент заказчики начали говорить: бюджета сейчас нет, запуск откладываем. Это очень заметно.

Александр: Что тогда делать компании – просто пережидать?

Александр Малков: Работать дальше и адаптироваться. Мы делаем разные пивоты, смотрим, что сейчас востребовано рынком, от каких направлений стоит отказаться, а где, наоборот, появляется интерес. Например, проекты вокруг ИИ и ML у нас в какой-то момент после периода тишины начали заметно оживать. То есть рынок меняется, но это не означает, что нужно просто остановиться и ждать возвращения старых условий.

Выученные ответы на интервью могут помочь пройти собеседование, но реальная работа быстро показывает, умеет ли человек мыслить и применять знания.

На сложном рынке компании тоже вынуждены перестраиваться: замораживать найм, менять продукты и искать направления, где спрос появляется прямо сейчас.

Александр: Если появляются C++20, C++23, C++26, правильно ли понимать, что язык сознательно пытается стать удобнее и безопаснее, а не готовится уходить в историю?

Александр Малков: Я думаю, да. C++ развивается. В язык постепенно добавляются конструкции, которые позволяют человеку решать задачи более удобно и безопасно. Конечно, его фундаментальная природа никуда не исчезает. Но современный C++ сильно отличается от того C++, который люди изучали двадцать лет назад.

Александр: То есть задача в том числе в том, чтобы реже заставлять программиста вручную лезть туда, где легко допустить ошибку?

Александр Малков: Да. Современные абстракции именно для этого и существуют. Но абсолютной безопасности в C++ всё равно нет: язык исторически даёт разработчику слишком много свободы и должен сохранять совместимость с огромным существующим миром кода.

Современный C++ постепенно поднимает уровень абстракций и добавляет более безопасные конструкции, но не отказывается от низкоуровневого контроля.

Эволюция языка ограничена его огромным наследием: новые возможности должны сосуществовать с десятилетиями уже написанного кода.

Александр: Мы постоянно возвращаемся к памяти. Почему для C++ это настолько центральная тема?

Александр Малков: Потому что C++ позволяет работать с памятью очень напрямую. При этом сама память неоднородна с точки зрения скорости. Получить данные с диска относительно долго. Из оперативной памяти – гораздо быстрее. Из процессорного кэша – ещё быстрее.

Когда вы занимаетесь производительностью, эти различия становятся важны. C++ позволяет работать непосредственно с объектами в памяти, с указателями, в том числе с сырой адресацией и арифметикой указателей. В Go, например, указатели тоже есть, но привычной арифметики указателей язык вам не даёт. В C++ контроль гораздо шире.

И вместе с ним приходит обязанность понимать lifetime объекта. Если вы вручную выделили память, нужно сделать так, чтобы она была корректно освобождена. Сегодня, конечно, нормальный C++ далеко не всегда означает ручные new и delete: существуют RAII, умные указатели, контейнеры и другие конструкции. Но фундаментальная проблема времени жизни объектов остаётся очень важной.

Александр: А чем это отличается от языков с garbage collector?

Александр Малков: В языках вроде Java или Go есть сборщик мусора. Он снимает с программиста большую часть ручной ответственности: недоступные объекты автоматически обнаруживаются, и занимаемая ими память возвращается системе. Это сильно упрощает разработку. Но сборка мусора сама является работой.

При очень высокой нагрузке её поведение способно влиять на задержки. Я слышал истории, когда на сервисах под большой нагрузкой на графиках регулярно появлялась деградация – и при сравнении выяснялось, что она совпадает с работой garbage collector. В C++ можно получить более предсказуемое управление временем жизни объектов. Но расплата очевидна: если вы сами ошиблись, язык не всегда вас спасёт.

Александр: Какие ошибки возникают?

Александр Малков: Утечки памяти, dangling pointers, обращение к уже освобождённым данным, неправильная арифметика указателей, undefined behavior. Допустим, вы регулярно выделяете небольшой кусок памяти и никогда его не освобождаете. Программа не обязательно упадёт сегодня. Память может накапливаться очень медленно – мегабайтами в день.

Неделю всё хорошо. Вторую неделю хорошо. Потом внезапно ресурс заканчивается, сервис падает, и вы начинаете искать причину. Или сохранили указатель на объект, который уже уничтожен. Он какое-то время может как будто бы работать – просто потому, что по этому адресу ещё лежат прежние данные. А затем память переиспользовалась – и вы получили совершенно другое поведение. Вот почему некоторые C++-баги так неприятны: причина появилась давно, а симптом вы увидели значительно позже.

Александр: И поэтому нужны санитайзеры?

Александр Малков: Именно. Современные инструменты позволяют обнаруживать большое количество проблем во время тестирования и раннего запуска приложения. Если можно поймать ошибку до продакшена, нужно это делать. Полагаться на то, что «я опытный разработчик и с памятью не ошибаюсь», нельзя. Ошибаются все.

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

Самые неприятные проблемы с памятью часто отделены по времени от причины, поэтому AddressSanitizer и другие диагностические инструменты – не роскошь, а нормальная часть современного процесса разработки.

Александр: Назовите три вещи, за которые вы не любите C++.

Александр Малков: Интересный вопрос. Мне даже сложно сразу ответить.

Александр: Сложность изучения вас, кажется, как раз не пугает.

Александр Малков: Да, я люблю разбираться в сложных вещах, поэтому сама сложность для меня не обязательно минус. Но есть другие проблемы. Первая одновременно является и преимуществом: одну и ту же вещь можно сделать множеством способов. Свобода прекрасна, пока не возникает вопрос: а какой способ в конкретной команде считается правильным?

Александр: Получается много разных стилей и подходов.

Александр Малков: Именно. Вторая проблема – размер стандарта. C++ стал настолько огромным, что практически никто не знает язык полностью. Даже Бьёрн Страуструп не пытается делать вид, что держит в голове абсолютно каждую деталь современного стандарта.

Поэтому, если человек приходит и говорит: «Я знаю C++ в совершенстве», к такому заявлению я бы относился очень скептически. Язык слишком большой. И третья проблема – разрозненность инструментария. С одной стороны, большое количество инструментов – плюс. С другой – новичка этот выбор легко запутывает.

Александр: Что именно здесь неудобно?

Александр Малков: Исторически даже начать было непросто. Вы ставили Visual Studio C++, смотрели на всё это и пытались понять: где здесь вообще нормально писать и собирать программу? Затем узнавали про MinGW, Linux, GCC, Clang – и постепенно открывался целый отдельный мир. С зависимостями тоже до сих пор не всё идеально.

Есть Conan, vcpkg и другие решения, но мне в целом не нравится ситуация с пакетными менеджерами C++. То, что прекрасно собирается на одном компьютере, иногда не собирается на другом из-за версии библиотеки, компилятора или особенностей окружения. После современных экосистем, где package management воспринимается почти как данность, в C++ это особенно заметно.

Главное достоинство C++ – свобода – одновременно порождает множество стилей и способов решить одну задачу, из-за чего командные договорённости особенно важны.

Современный C++ практически невозможно «знать целиком»: профессионализм проявляется не в запоминании всего стандарта, а в умении понимать систему и находить нужную информацию.

Александр: Что такое многопоточность в C++?

Александр Малков: Это возможность выполнять несколько потоков работы параллельно. Представьте сложное вычисление, которое можно разделить на части. Современный процессор имеет несколько ядер, поэтому отдельные части задачи можно выполнять одновременно. Условная аналогия – столовая.

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

Александр: В чём разница?

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

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

И наоборот: многопоточность не обязательно означает ту модель асинхронности, которую мы видим в Python, Go или современных C++-фреймворках. Дальше уже scheduler решает, как конкретная реализация будет распределять работу. Поэтому важно не считать слова «корутина», «асинхронность» и «многопоточность» синонимами.

Многопоточность отвечает прежде всего за параллельное выполнение работы, а асинхронность – за возможность не блокировать выполнение, пока одна задача ждёт внешнего события.

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

Александр: У вас есть хобби?

Александр Малков: Я стараюсь оставаться разносторонним человеком, хотя получается не всегда. Бывают периоды, когда полностью погружён в код и почти ни на что другое времени не остаётся. Но в обычной жизни стараюсь уделять время семье и спорту. И я бы вообще всем разработчикам советовал не забывать про тело и здоровье.

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

Александр: Если полностью убрать программирование, кем вы могли бы стать?

Александр Малков: Я об этом думал. Наверное, пошёл бы в бизнес. Мне нравится разбираться в сложных системах, а бизнес – это тоже сложная система. Нужно понимать, куда движется рынок, следить за изменениями, реагировать на новые условия.

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

Александр: А сейчас есть большая мечта?

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

Если собрать разговор в один ответ, C++ в 2026 году находится в довольно необычном положении.

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

Но именно там, где производительность перестаёт быть абстрактной цифрой, C++ по-прежнему чувствует себя очень уверенно. Игровые движки, embedded, высоконагруженная инфраструктура, финансовые системы, системное программирование, библиотеки и огромные массивы legacy не исчезнут только потому, что появился более молодой язык.

При этом современный C++ – это уже давно не набор new, delete и указателей из старых учебников. Он развивается, получает новые стандарты, высокоуровневые конструкции и инструменты безопасности. Вместе с ним растёт и объём знаний, необходимых специалисту: компиляторы, сборка, память, профилирование, многопоточность, библиотеки, архитектура и понимание железа.

Поэтому, пожалуй, главный вопрос перед изучением C++ не «жив ли язык?», а «что именно вы хотите с его помощью делать?».

Если ответ – «хочу просто войти в IT», существуют более короткие маршруты.

Если вам интересны системы, производительность, движки, железо, компиляторы и возможность однажды докопаться до проблемы на уровне байтов и кэшей – C++ всё ещё способен обеспечить практически бесконечную глубину.

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

Учить C++ имеет смысл не потому, что он «самый сложный» или «самый престижный», а когда вас действительно привлекают задачи, где его свойства дают преимущество.

Самый устойчивый карьерный навык – не верность одному языку, а способность понимать системы. C++, Rust, Go и следующие технологии в таком случае становятся тем, чем и должны быть: инструментами.

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

ARM – семейство процессорных архитектур. В частности, ARM-архитектуру используют процессоры Apple Silicon и огромное количество мобильных и embedded-устройств.

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

Ассемблер – низкоуровневый язык, инструкции которого близко соответствуют машинным командам конкретной архитектуры процессора.

Bottleneck, узкое место – участок системы, который ограничивает общую производительность. Например, медленный запрос к базе может быть bottleneck независимо от скорости остального кода.

Boost – большая коллекция C++-библиотек. Многие идеи и решения из Boost впоследствии влияли на стандартную библиотеку C++.

Boost.Context – библиотека Boost с низкоуровневыми механизмами сохранения и переключения контекста выполнения.

Boost.Coroutine2 – библиотека для работы с корутинами, основанная на механизмах Boost.Context.

Borrow checker – механизм Rust, который во время компиляции проверяет правила владения, заимствования и времени жизни данных, предотвращая ряд ошибок с памятью.

C – язык системного программирования, созданный в начале 1970-х и тесно связанный с историей Unix. C++ вырос из идей и синтаксиса C, сохранив возможность низкоуровневой работы с памятью.

C++20, C++23, C++26 – последовательные редакции стандарта языка C++. Новые стандарты добавляют возможности языка и стандартной библиотеки.

CMake – одна из наиболее распространённых кроссплатформенных систем конфигурации сборки C/C++-проектов.

Clang – компилятор C/C++ и связанных языков из экосистемы LLVM.

Claude – семейство больших языковых моделей Anthropic, которое может применяться в том числе при программировании.

Codex – инструменты и модели OpenAI для задач программирования.

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

Concurrency – организация нескольких независимо развивающихся задач. Не обязательно означает физически одновременное выполнение на разных процессорных ядрах.

Conan – пакетный менеджер для C и C++, используемый для управления библиотеками и зависимостями проекта.

Contribution / contribute в Open Source – вклад в открытый проект: исправление ошибки, новая функция, документация, ревью и другие изменения.

cppreference – популярный справочный ресурс по C++, C и стандартным библиотекам.

CTO, Chief Technology Officer – технический директор компании, отвечающий за технологическое направление, архитектуру, инженерные процессы и технические решения.

Dangling pointer, висячий указатель – указатель, который продолжает ссылаться на область памяти после того, как объект в ней уже перестал существовать.

Debug-лог – диагностическое сообщение, добавляемое разработчиком, чтобы увидеть состояние и ход выполнения программы.

Embedded – разработка программного обеспечения для встроенных устройств: контроллеров, бытовой техники, электроники, промышленного оборудования и других систем, часто имеющих ограниченные ресурсы.

Fallback – запасной сценарий, который используется, если основной способ выполнить операцию недоступен или завершился ошибкой.

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

Fortran – один из старейших языков программирования, который до сих пор применяется прежде всего в научных и инженерных вычислениях.

Garbage collector, сборщик мусора – механизм автоматического поиска и освобождения памяти, занятой объектами, которые больше не нужны программе.

GCC – GNU Compiler Collection; набор компиляторов, включающий один из основных C/C++-компиляторов.

Go / Golang – язык программирования Google, популярный в серверной и инфраструктурной разработке.

Горутина, goroutine – лёгкая конкурентная задача в Go, исполнением которой управляет runtime языка.

HFT, High-Frequency Trading – высокочастотная алгоритмическая торговля, где большое значение имеет минимальная задержка обработки данных и отправки операций.

IO-bound – класс задач, скорость которых в значительной степени ограничивается ожиданием ввода-вывода: сети, диска, базы данных и других внешних ресурсов.

JSON – распространённый текстовый формат представления и обмена структурированными данными.

Legacy – существующий, часто достаточно старый код, который продолжает использоваться и поддерживаться. Legacy не обязательно означает «плохой код».

Lifetime – время жизни объекта или ресурса: период, в течение которого он существует и к нему допустимо обращаться.

LLM, Large Language Model – большая языковая модель, лежащая в основе современных генеративных ИИ-систем.

LLVM – инфраструктурный проект для создания компиляторов и связанных инструментов. Clang является частью этой экосистемы.

malloc – функция языка C для динамического выделения блока памяти.

realloc – функция C для изменения размера ранее выделенного блока динамической памяти.

Middle-разработчик – специалист среднего уровня самостоятельности и опыта. Границы уровня зависят от конкретной компании.

ML, Machine Learning – машинное обучение: методы построения моделей на основе данных.

Многопоточность – использование нескольких потоков выполнения. Может позволять программе задействовать несколько процессорных ядер параллельно.

Open Source – модель разработки, при которой исходный код проекта доступен в соответствии с условиями его лицензии и к проекту могут подключаться внешние разработчики.

Профилировщик – инструмент, который измеряет поведение программы во время выполнения и помогает находить участки с повышенным потреблением CPU, памяти или других ресурсов.

Прод, production – рабочая среда, обслуживающая реальных пользователей. «Уронить прод» означает вызвать серьёзный сбой работающей системы.

RAII, Resource Acquisition Is Initialization – один из фундаментальных C++-подходов: ресурс привязывается к времени жизни объекта и автоматически освобождается при его уничтожении.

RPS, Requests Per Second – количество запросов, обрабатываемых системой за секунду.

Runtime – период выполнения программы либо инфраструктура, обеспечивающая её выполнение; значение зависит от контекста.

Rust – системный язык программирования, сочетающий низкоуровневый контроль и zero-cost abstractions с сильными compile-time-проверками безопасности памяти.

Sanitizer, санитайзер – класс инструментов динамической диагностики, которые помогают находить ошибки памяти, гонки данных и другие проблемы.

Scheduler, планировщик – компонент, распределяющий задачи или потоки между доступными вычислительными ресурсами.

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

Stackful-корутина – корутина, которая имеет собственный стек и может приостанавливать выполнение внутри цепочки вызовов, сохраняя контекст.

STL, Standard Template Library – историческое название набора шаблонных контейнеров и алгоритмов, идеи которого стали важнейшей частью стандартной библиотеки C++.

Undefined behavior, неопределённое поведение – ситуация, для которой стандарт языка не задаёт обязательного результата. Программа может внешне работать нормально, падать или проявлять непредсказуемое поведение.

Unreal Engine – игровой движок Epic Games, значительная часть которого написана на C++.

userver – C++-фреймворк для разработки высоконагруженных приложений и сервисов, исторически развивавшийся в Яндексе.

Указатель – значение, содержащее адрес объекта или области памяти. В C++ указатели позволяют выполнять низкоуровневые операции с памятью.

Утечка памяти – ситуация, когда программе больше не нужна выделенная память, но она не была освобождена и продолжает занимать ресурсы.

Умный указатель – C++-объект, управляющий временем жизни динамически созданного объекта. Примеры – std::unique_ptr и std::shared_ptr.

Zero-cost abstractions – принцип, согласно которому удобная высокоуровневая абстракция не должна добавлять существенных накладных расходов по сравнению с эквивалентной низкоуровневой реализацией.