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

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

Для инди-разработчиков и небольших команд это означает, что HarmonyOS и OpenHarmony становятся официальной целью сборки SDL3, а не отдельной веткой, которую приходится поддерживать самостоятельно. Работа над портом была профинансирована Outfit7.

Источники

• harmonyos: Port SDL3 to HarmonyOS/OpenHarmony. by icculus · Pull Request #16281 · libsdl-org/SDL · GitHub

Уязвимости затрагивают разные этапы обработки файла. Для ошибки iinf/max_items достаточно чтения контейнера через heif_context_read_from_file, без декодирования изображения. Отдельная проблема возникает при обходе ссылок на этапе декодирования, а взаимная блокировка потоков связана с параллельным декодированием grid-тайлов. Поэтому проверка только загрузки метаданных не воспроизводит все три проблемы с высокой оценкой.

• Лимит max_items не применялся к дочерним боксам iinf: файл объявляет сколько угодно элементов, разбор становится квадратичным. Замер: 1,7, 6 и 23 секунды процессора на файлы 1, 2 и 4,1 МБ; файл 6,9 МБ держит 480 МБ памяти, 23 МБ файл 1,5 ГБ, и max_total_memory этого не видит. В сборке под Emscripten тот же счётчик задавал размер alloca на 64-килобайтном стеке WebAssembly: 16 000 элементов проходят, 17 000 роняют вызов, с 18 000 модуль ломается необратимо.
• Неограниченная рекурсия при обходе ссылок могла исчерпать стек; исправленный обход на этапе декодирования использует явный список в куче.
• Инверсия порядка блокировок при параллельном декодировании тайлов grid (включено по умолчанию) давала вечный дедлок; циклические графы ссылок отклоняются до начала декодирования.
• Три проблемы средней важности: чтение за границей буфера в плагинах кодировщиков aom и x265, неисправимая утечка памяти в heif_track_get_next_raw_sequence_sample и чтение за границей в экспериментальном плагине WebCodecs.
• Уязвимы версии от 1.16.0 до 1.23.3 включительно (в зависимости от проблемы), исправлено в 1.23.4; номера CVE будут присвоены позже.

Как одна неучтённая ветка отключила лимит на число элементов

В отчёте описана классическая ошибка перегруженного параметра. Функция Box::read_children принимает max_number, у которого два смысла: со значением-сентинелом READ_CHILDREN_ALL она читает до конца бокса и проверяет лимит max_items, а с любым другим числом читает ровно столько детей и ничего не проверяет. Box_iinf::parse передавала туда счётчик из самого файла, поэтому проверка, написанная специально для iinf, никогда не выполнялась.

Дальше цена растёт квадратично: для каждого элемента вызывается полный проход по списку ссылок iref без раннего выхода. Исследователь измерил на одном ядре 1,7, 6,0 и 23 секунды для файлов в 1,0, 2,0 и 4,1 МБ; абсолютные цифры различаются вдвое между машинами, но рост в 3–4 раза на каждое удвоение стабилен против 2 раз у линейного парсера. Всё это происходит внутри вызова, который затем возвращает heif_error_Ok, без коллбэка отмены и прогресса. В 1.23.4 лимит проверяется заранее, объявленное число ограничено оставшимся входом, а запросы к iref индексируются по идентификатору элемента: на файле с 1 000 элементов и 160 000 ссылок dimg время чтения упало с 1,83 до 0,26 секунды.

Сборка под WebAssembly страдала отдельно. Два вспомогательных метода в Emscripten-обвязке выделяли массив идентификаторов через alloca с размером из того же счётчика. Скрипт сборки не задаёт ни размер стека, ни проверку его переполнения, поэтому использовался стек по умолчанию в 64 КБ: 16 000 элементов занимают 64 000 байт и декодируются, 17 000 прерывают вызов, а с 18 000 переполнение уходит в сегмент статических данных и экземпляр модуля перестаёт работать до перезагрузки страницы. Хелпер вызывается при каждом HeifDecoder.decode().

Рекурсия и дедлок: две другие высокие уязвимости

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

Третья проблема затрагивает серверы с параллельным декодированием: параллельное декодирование тайлов grid включено по умолчанию, а ImageItem::decode_image() держит нерекурсивный мьютекс элемента на время вложенных декодирований. Два рабочих потока, чьи элементы ссылаются друг на друга, берут два мьютекса в противоположном порядке и зависают навсегда; процесс не падает и не освобождает ресурсы. Исправление отклоняет циклические графы декодирования, включая рёбра dimg и alpha auxl, до старта.

Кому обновляться в первую очередь

Всем, кто принимает HEIC и AVIF от пользователей: это серверные конвертеры, бэкенды фотохостингов и мессенджеров, CI-пайплайны с ImageMagick, а также веб-приложения, которые декодируют HEIC на клиенте через libheif-js или собственную Emscripten-сборку. Для последних важно, что обрушение WebAssembly-модуля необратимо в рамках страницы. Мейнтейнеры советуют обновиться всем пользователям; в дистрибутивах смотрите на пакет libheif1 или libheif в вашем менеджере. Уязвимость средней важности в плагине WebCodecs касается только Emscripten-сборок с WITH_WEBCODECS=ON, по умолчанию выключенной опции, и только без libde265.

Отдельный отчёт о расходе ресурсов опубликован для Go-библиотеки Excelize: файл на 3 КБ заставляет библиотеку выполнять произвольное число итераций хеширования, и патча пока нет (исправление в сохранённом отчёте не указано). Из недавних выпусков безопасности того же масштаба мы разбирали curl 8.22.0 с девятью уязвимостями и внеочередные релизы PostgreSQL от Postgres Pro.

Источники: libheif v1.23.4 – security maintenance, release notes, GHSA-vg7w-rp49-4fc2: The max_items security limit is not enforced for iinf child boxes, GHSA-xrp2-63fq-jm8q: Unbounded iref entry list and unbounded recursion, GHSA-prgh-72vc-3xmc: Lock-order inversion in parallel grid tile decoding

Разбираем, откуда взялось это слово — его придумал создатель Bourne Shell Стивен Борн — и зачем оно нужно в современном C и C++.

— В C и C++ ключевое слово void используется четырьмя способами: возвращаемый тип, отсутствие параметров, указатель на неизвестный тип и явное приведение к «ничему».

— Слово void предложил Стивен Борн, автор Bourne Shell; до этого функция без возвращаемого значения просто не указывала тип.

— f(void) и f() — разные вещи в C: первая форма явно говорит «параметров нет».

— void* — универсальный указатель, но разыменовывать его нельзя.

— Приведение к void помогает подавить предупреждения о неиспользуемом возвращаемом значении или параметре.

Краткая история: как появилось void

В самой ранней версии C, так называемом K&R-диалекте, функция без возвращаемого значения писалась без типа. Если возвращаемый тип не указан, компилятор считал, что функция возвращает int. Параметры тоже можно было описывать отдельно от списка аргументов — прямо как в старых учебниках:

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

Это раздражало Стивена Борна — да, того самого, который создал Bourne Shell. Он пожаловался Деннису Ритчи, и Ритчи увидел выгоду: если явно сказать, что функция ничего не возвращает, можно сэкономить одну машинную инструкцию. Так в C появилось слово void.

Позже void обросло новыми смыслами и перекочевало в C++, C#, Java, D и Swift — хотя Swift предпочитает писать его с заглавной буквы: Void.

Четыре смысла void

1. Функция не возвращает значение

Самый известный смысл. Вместо того чтобы молча возвращать int, функция явно объявляет: «я работаю ради побочного эффекта».

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

2. Явное отсутствие параметров: f(void)

В C++ пустые скобки f() означают «функция не принимает параметров». В K&R C те же пустые скобки означали лишь «это функция», без всякой информации о параметрах. Чтобы сохранить совместимость со старым кодом и одновременно ввести прототипы, в C придумали запись f(void):

Разница тонкая, но важная. Если в C объявить void foo();, а потом вызвать foo(42), компилятор не проверит количество и типы аргументов — это старая K&R-форма. Запись void foo(void); защищает от таких ошибок.

Совет:
Всегда пишите int main(void) в C. Форма void main() не соответствует стандарту и может ломать работу runtime.

3. Указатель на неизвестный тип: void*

Объект типа void создать нельзя, но указатель на void — можно. void* — это универсальный указатель: он может хранить адрес данных любого типа. В отличие от char*, который в K&R C выполнял ту же роль, void* чётко говорит: «тип здесь не важен».

Практически все функции динамического выделения памяти — malloc, calloc, realloc — возвращают void*. В C это удобно: компилятор неявно приводит void* к целевому типу. В C++ такой неявный каст запрещён, поэтому там пишут int* arr = (int*)malloc(...) или, что лучше, используют new.

4. Приведение к void

Последний смысл — самый неочевидный. Приведение выражения к void означает: «я намеренно игнорирую результат». Это полезно в двух случаях.

Первый: отбрасывание возвращаемого значения функции. Например, printf возвращает число напечатанных символов, но обычно оно не нужно:

Такая запись читается как «вызываем функцию только ради побочного эффекта». Большинство компиляторов и так не ругаются на неиспользованный результат printf, но для функций с атрибутом [[nodiscard]] приведение к void — единственный легальный способ проигнорировать результат.

Второй случай — неиспользуемый параметр функции. В callback-интерфейсах часто приходится принимать аргументы, которые конкретная реализация не использует:

В C23 можно просто опустить имя параметра, а в C++ — всегда можно было. Но приведение к void работает в любом стандарте и явно показывает намерение.

Практика: что проверить в своём коде

• В C пишите int main(void), а не void main().
• Для функций без параметров используйте f(void), особенно в заголовочных файлах.
• Не разыменовывайте void* — сначала приведите указатель к конкретному типу.
• Если игнорируете возвращаемое значение, добавьте (void) — это помогает при включённых предупреждениях.
• Не пытайтесь объявить переменную типа void: объект «ничего» в C не существует.

All uses of void are valid in both C and C++. If that weren't the case, I would have said so.

Выводы

void — не просто синтаксический сахар для «пустоты». Это ключевое слово, которое помогает компилятору различать четыре разных ситуации: отсутствие результата, отсутствие параметров, неизвестный тип данных и намеренное игнорирование значения.

Исторически void появилось из инженерной прагматики: сэкономить одну инструкцию возврата и сделать код понятнее. Сегодня оно остаётся незаменимым инструментом — особенно если вы пишете на C, работаете с системными библиотеками или объясняете студентам, почему void main() — не лучшая идея.

Источник: Paul J. Lucas, «Into the Void», Dev.to. Дополнительный справочник по void — cppreference.com.

Сразу скажу - я не считаю себя втором Терри Дэвисом и тем более не хочу делать аналог Виндовс. Изначально я все это затеял только ради прикола и изучения ассемблера.

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

Так а в чем же проблема x86_64?

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

Не буду говорить, что RISC-V лучшая, но я просто выбрал ее. Прикол в том, что инструкции короткие, да и в целом достаточно перспективно. Хотя и тут были проблемы.

Был драйвер, стала ОС

Я ничего с нуля не писал.Все началось с пыток ИИ, когда я пытался выдавить из него то обращение по конкретному адресу для доступа к графике, то опрос портов, то еще что-то такое. Мне стало лень и я пошел искать что-то плюс-минус готовое. И я нашел его - ramfb. По сути я получил готовый указатель на фреймбуфер для вывода на экран… И все. Но и на этом большое спасибо авторам драйвера. Дальше началась моя ОС.

А где хранить данные?

А тут первая проблема - как таковой кучи у меня еще нету. Есть стек, который за меня выделил автор драйвера. Есть всякие глобальные переменные. Но что если мне нужно много памяти (например, под картинки) и я не знаю точный размер? И в добавок, кто вообще рисует напрямую на экран? Тут нужен некий массив пикселей, который будет лежать в памяти, а по нашей команде быстро перенесется на экран (называется backbuffer).

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

Это когда ты делишь память на куски, каждый помечаешь как занятый или свободный. Нужно мало памяти - откусываем от большого куска блок. Блок освободился, а рядом есть другой свободный блок - соединяем в один большой.Сразу же добавил функцию, чтобы узнать сколько памяти занято. Сейчас, например, занято около 3-4 мб. Ну это учитывая, что backbuffer и занял почти 3.5 мб.

В оперативной памяти что-то типа

Такая разная многопоточность

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

Многопоточность кооперативная

Так мы можем сказать потокам, чтобы если один из них решит, что стоит сделать паузу, сам вызвал yield() и отдал процессор другому потоку. И я это сделал. Все что нужно было - сохранить s-регистры процессора (те, в которых лежат всякие важные значения), указатель на личный стек потока (размер стека задается при создании) и указатель на “дорогу назад” ra. То есть yield() сохраняет эту информацию потока А, затем вместо нее загружает информацию потока Б. И так по кругу.

Кстати, стеки самих потоков я выделял в той самой куче. Просто брал блок на пару кб и говорил потоку: “Это твой стек”.

Но у такого концепта есть проблема - зависает один поток, остальные перестают выполняться. Да и в целом писать yield() каждый раз сложно.

Многопоточность вытесняющая

Поэтому я и решил переписать все на вытеснение. Для начала я сделал так - каждые 100к тиков процессора сохраняются все регистры и пинается функция обработки прерываний. Таймер, по которому будет работать многопоточность - это тоже прерывание. Так же эта функция ловит ошибки по типу kernel panic. Это было сложнее - так как потоки не добровольно отдают процессор, приходится сохранять вообще все 32 регистра. Но криво-косо я написал это и функцию sleep(), во время которой функция простаивает, ее никто не трогает.

А тут еще и ИИ начал выдавать бред, пока я тестировал у меня… начинал выполняться основной код, все было хорошо, а потоки - нет. Я сам не вижу ошибку, ИИ тоже. Он то предложит заменить какую-то часть функции, то еще что-то такое. Наконец я вспомнил про замечательную штуку - gdb. Запустил, посмотрел… Оказалось так - цикл отрисовки экрана был слишком долгим, во время него вызывалось переключение потоков, а их еще не было кроме главного. В итоге я подумал что смысла создавать потоки в конце, после отрисовки, нет, и перенес их в самое начало. Удивительно, но все заработало.

Немного про режимы

Как выяснилось, в RISC-V есть 3 режима (точнее 4, включая гипервизор, но тут он мне точно не нужен) - M-mode с полными привелегиями, S-mode для ядра ОС (я думал что и мое его использует), ну и U-mode для пользователей, но до этого мои ручки еще не дошли.

Ну и по пути я случайно осознал, что мое ядро выполняется аж в М-режиме:

Вызываю я ecall из потока. Смотрю - kernel panic. В логах какой-то код “11”. Оказалось, это и есть ecall - в M-mode он 11, а в S-mode (в котором, как я думал, работало ядро, и который я пытался выловить) это 9. Ну когда я нашел, уже быстро исправил.

Визуальчик

Но в это время на сам экран эмулятора Qemu… Ничего и не выводилось. Совсем. Просто белый экран. Хотелось красоты.

Тогда я вспомнил, что день назад прикрутил qoi.h к моему коду. QOI - формат изображений. Выбрал я его, так как декодер легкий и его удобно использовать в любой ОС, где есть базовые функции.

Я аккуратно, разумеется, согласно лицензии, взял из pop os, которой когда-то пользовался, картинку для фона. Конвертировал ее в .qoi, а так как моя ос еще не умела читать с диска, перевел картинку в заголовочный файл .h. Весит правда много, но влезает.

Дальше я нашел шрифт (Liberation Mono от Red Hat), перегнал и его в .h. Честно, визуал меня не сильно интересовал, поэтому быстро попросил ИИ переделать функции вывода в консоль в функции вывода на экран. Проверил, просмотрел что и как сделано, получилось нормально для старта. Правда пока что в графической консоли нет нормальной перемотки и много чего другого.

Вывод

Конечно, еще нету даже ввода с клавиатуры, мыши, файловой системы (даже простой). Но я считаю, что вышло неплохо, пусть и далеко от уровня реальной ОС типа Линукса. Понятно, что код не очень-то красивый, достаточно простой. Статью я выкладываю больше просто чтобы разобраться самому в том, что я написал.

Если я не забью на код, хотел бы написать еще и MMU и переход в U-mode.

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

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

Denwer SE решает все эти проблемы, оставаясь при этом таким же портативным — достаточно скопировать папку на флешку или в облачный каталог.

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

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

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

После этого любые HTTPS-запросы к локальным хостам работают без единого предупреждения.

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

Исходники панели управления не открыты (распространяется скомпилированный EXE), но архитектура и конфиги полностью прозрачны. В планах — добавить поддержку Nginx в качестве альтернативы. Следите за обновлениями.

GameNetworkingSockets (GNS) — это open-source транспортный слой для игр от Valve. UDP-сокеты с надёжной доставкой, шифрованием end-to-end, congestion control, NAT traversal через ICE, retry-логикой поверх ненадёжной сети. По устройству ближе всего к QUIC — UDP в основе, поверх свой надёжный канал, шифрование, фрагментация. Но это не QUIC: формат пакетов и хэндшейк свои, совместимости с RFC 9000 нет. Когда Valve открыла исходники в 2018 году, у инди-разработчиков и небольших студий появился рабочий движок сетевой части без необходимости заказывать его за миллионы долларов или писать самим с нуля.

С тех пор библиотеку взяли в самые разные продукты — от шутеров до симуляторов и до RPG. Major-тег 1.4.0 вышел в январе 2022 года, патч-релиз 1.4.1 — в июне 2022. С тех пор в репозитории шла обычная разработка — около 350 коммитов в master с фиксами и улучшениями, — но нового тега не было. 28 апреля 2026 года Valve собрала весь этот хвост в релиз 1.5 и подытожила, что именно изменилось.

v1.5.0 — первый тег за почти 4 года. Major-тег 1.4.0 вышел в январе 2022, патч 1.4.1 — в июне 2022. Накопленный хвост — около 350 коммитов в master с прошлого тега.

Поменялась семантика SendMessages. Раньше функция возвращала единый код, по которому невозможно было понять, какие из сообщений ушли. Теперь каждое сообщение получает свой результат, и интерфейс облегчает retry. Старый код, который игнорировал результат и работал как «отправь и забудь», нужно пересмотреть.

Новые конфиги: Explicit Congestion Notification (ECN), статистика jitter, IPLocalHost_AllowWithoutAuth и ещё несколько. Помогают тюнинговать поведение в стрессовых сетях и тестовых окружениях.

Native ICE-клиент по-прежнему в beta. Race-баги, ведущие к hang, починили; для production-P2P пока всё равно WebRTC ICE.

Появились первые Rust bindings — community-вклад, не официально поддерживаемый Valve, но рабочая отправная точка для Rust-проектов.

Что такое GameNetworkingSockets и кто на нём работает

GameNetworkingSockets — это библиотека сетевого транспорта, открытая Valve в 2018 году. По смыслу она ближе всего к QUIC: UDP в основе, поверх — собственный надёжный канал, шифрование, контроль перегрузки, фрагментация. Главное отличие — ориентация на игровой трафик: маленькие частые сообщения, тонкая конфигурация ретраев, поддержка ненадёжной доставки рядом с надёжной (можно выбрать на каждое сообщение).

Использует библиотеку прежде всего сама Valve: на ней работают Counter-Strike, Dota 2 и любой другой мультиплеер из Steam, который ходит через Steam Datagram Relay (SDR) — собственную сеть Valve, агрегирующую трафик через быстрые узлы поближе к игроку. Кроме Valve, библиотеку взяли разные инди- и middleware-проекты, плюс она встроена как дополнительный backend в несколько игровых движков.

У GNS есть два режима. Первый — клиент-сервер по обычному IP, без участия Steam-сети. Второй — P2P, через ICE для NAT traversal. P2P-режим требует внешнего signaling-сервера для обмена ICE-кандидатами между пирами; пример Valve поставляет в репозитории.

Что нового в 1.5

API: новая семантика SendMessages, плоский C API для Messages

Главное изменение в API — поведение ISteamNetworkingSockets::SendMessages при ошибках. Раньше функция возвращала единый код, который не давал понять, какие из сообщений ушли, а какие нет. Теперь каждое сообщение получает свой результат, а интерфейс облегчает retry — можно прозрачно переотправить только упавшие, не дублируя успешные. Если у вас в коде есть обёртка «отправил пачку — получил ОК или нет», её надо переписать под новый паттерн, иначе при сбоях часть сообщений просто потеряется.

Добавлен flat C API для ISteamNetworkingMessages — это режим, где сокеты привязываются не к connection-у, а к идентичности игрока, и отправка идёт по принципу «отправь пользователю X». Раньше этот режим был доступен только из C++. Теперь можно дёргать его и из C, и из любого языка с C FFI без C++-обёртки — что особенно актуально для Rust-, Go- и Python-биндингов.

Появилась хук-функция SteamNetworkingSockets_SetServiceThreadInitCallback — для тех, кто хочет подкрутить поведение сервисного потока (приоритет, имя, привязка к ядру) до того, как библиотека начнёт обрабатывать пакеты.

Надёжность и наблюдаемость

На уровне пакетов и очереди сообщений библиотека теперь автоматически корректирует часть out-of-order ситуаций — раньше эти случаи выливались в reorder-events для прикладного кода, и каждый разработчик разбирался с ними сам. Не идеальное решение для всех сценариев, но для игрового трафика — обычно то, что нужно по умолчанию.

Из новых конфигов и метрик:

• ECN (Explicit Congestion Notification) — поддержка пометок в IP-заголовке, чтобы роутеры могли сигнализировать о перегрузке без потери пакетов.
• Jitter stats — статистика разброса времени доставки, видимая через стандартные accessor-ы. Полезно для тонкой настройки буферов и плавности геймплея.
• IPLocalHost_AllowWithoutAuth — режим без аутентификации для localhost-соединений, удобен в тестовых сборках, dedicated-серверах локальной отладки и CI.
• ETW (Event Tracing for Windows) — диагностические события, видимые в Windows Performance Analyzer и аналогах.

P2P: ICE-клиенты, race-баги

P2P-стек получил серию точечных фиксов. В WebRTC ICE-клиенте, который Valve использует как основной для P2P, починили race-баги, которые приводили к hang при определённых таймингах рукопожатия. В нативном ICE-клиенте — собственной имплементации ICE-стека Valve, которая развивается параллельно ICE из WebRTC, исправили несколько багов, но он по-прежнему помечен как beta — для production пока рекомендуют WebRTC ICE.

Пример сигнального сервера в репозитории переписан с нуля на Python — раньше он жил на C++ и имел набор багов, которые мешали запустить локальный P2P-тест из коробки. Сейчас пример работает «как описано» и заодно проверяется в CI: P2P-сценарии добавили в авто-тесты, что для самоподдерживающейся кодовой базы серьёзный шаг.

Rust bindings, CMake/vcpkg, протобафы

В релиз попали первые официальные Rust bindings — но с дисклеймером community contribution: их пишет и поддерживает не Valve, а сторонние мейнтейнеры. Если планируете сетевой стек на Rust поверх GNS — подключите биндинг как зависимость, но будьте готовы к тому, что приоритет фиксов и обновлений отличается от основной библиотеки.

Интеграция с CMake и vcpkg существенно упрощена — собрать GNS без сторонних рецептов теперь реально на обычной машине. Параллельно починили совместимость с новыми версиями protobuf и abseil — последняя регулярная боль для тех, кто строил на vcpkg или conan.

Почему 4 года тишины

Valve в release notes причину не комментирует. Видимая динамика — около 600 коммитов в master за этот период, регулярные мерж-реквесты от внешних контрибьюторов, активное реагирование на issue. Пакетный релиз делается, по всей видимости, по другому критерию — когда внутреннее использование в продуктах требует фиксированной версии для интеграции.

Для пользователей библиотеки это означало одно из двух: либо собирать сборку из master и брать на себя риск сломанных интерфейсов, либо сидеть на 1.4, не получая четырёх лет улучшений. Релиз 1.5 закрывает обе дороги: можно зафиксироваться на стабильном теге и получить весь хвост.

Стоит ли переходить на 1.5

Если у вас 1.4 в продакшене:

• Тщательно проверьте код вокруг SendMessages — теперь по каждому сообщению есть свой результат, и старый «отправь и забудь» нужно дополнить логикой ретраев.
• Прогоните регрессионный тест P2P, если используете — race-баги в WebRTC ICE и нативном ICE затрагивали реальные сценарии и могли проявляться раз в N подключений.
• Подключите ECN и jitter stats к телеметрии — за 4 года накопилось чем мерить качество соединения, грех не воспользоваться.
• Если в ваших сборках болела совместимость с протобафом или abseil — берите 1.5: эти места починили.

Если выбираете между GNS и альтернативами для нового проекта — релиз 1.5 не меняет принципиально позиционирование. GNS остаётся хорошим выбором, когда нужен стабильный, проверенный в Counter-Strike транспорт с готовым P2P для NAT traversal. Для проектов, где важно глубже интегрироваться с QUIC, WebTransport или WebRTC напрямую, существуют более специализированные стеки. Между GNS и более минималистичными ENet, kcp, RakNet выбор зависит от потребностей: GNS даёт из коробки больше фич (ICE, шифрование, контроль перегрузки), ценой большего C++-кода и зависимостей; ENet и kcp компактнее и быстрее интегрируются.

Выводы

GameNetworkingSockets 1.5 — это спокойный пакетный релиз: четыре года накопленных улучшений, без масштабных переписываний интерфейсов. Главное API-изменение — семантика SendMessages, и это та правка, которую разработчики на 1.4 пропустить не смогут. Всё остальное — про observability, P2P-стабильность и удобство сборки.

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

Источники: релиз v1.5.0 на GitHub, репозиторий и документация, обзор у Phoronix.

Пизло — человек, от которого обычно ждут постов про «как мы выкрутили очередной трюк в JIT JavaScriptCore». Его прошлые тексты — это FTL JIT, B3, Riptide GC и другие вещи, которые требуют двух лет опыта в компиляторах. Но этот текст — принципиально другой. Он показывает ровно то, о чём обычно не пишут: что делать, когда у вас ещё нет JIT, а GC ещё не является главной болью.

Стартовая версия интерпретатора Zef была в 35 раз медленнее CPython 3.10, в 80 раз медленнее Lua 5.4.7 и в 23 раза медленнее QuickJS-ng 0.14.0. После 21 оптимизации (ни одной из которых не требует SSA-преобразований (static single assignment), переделки сборщика мусора, байткода или машинного кода) тот же интерпретатор проигрывает CPython всего в 2,1 раза, Lua — в 4,8 раза, QuickJS — в 1,35 раза. Если же собрать тем же обычным C++ без Fil-C — Zef становится быстрее CPython в 1,9 раза и быстрее QuickJS в 3 раза.

Представление значений: tagged 64-битные значения с NaN-boxing (упаковка целых и указателей в неиспользуемые биты double) позволяют держать числа на стеке и отличать их от указателей по битам.

Symbols вместо строк: один раз интернировать все имена методов и переменных в Symbol*, потом сравнивать указатели — даёт +18%.

Object Model + Inline Caches + Watchpoints: самый большой прирост (+355%, 4,55x) — одна мегакоммит-оптимизация, без которой остальное не работает.

Специализация мелочей: выделенный AST-узел для a + b вместо строкового a.add(b), Getter/Setter-инференс, специализированные ZeroArguments/OneArgument/TwoArguments.

Штраф Fil-C — 4x: memory-safe C, в котором автор пишет, даёт GC бесплатно, но накладывает штраф; итоговый буст после перехода на обычный C++ — 67x.

О каком интерпретаторе речь

Zef — это учебный динамический язык, который Пизло написал для удовольствия. В нём есть классы с наследованием, приватные поля (по умолчанию), замыкания, кастомные операторы, getter'ы и setter'ы. На уровне идиом он похож на Ruby и тихую версию JavaScript. Исходный интерпретатор — наивный AST-walker, в котором каждая нода — это C++-объект с виртуальным методом Node::evaluate, а все переменные живут в std::unordered_map<std::string, Value>.

Весь исходный код интерпретатора, diff-просмотрщики для каждой оптимизации и бенчмарки выложены на zef-lang.dev/implementation. Бенчмарки — набор ScriptBench1: Richards (OS scheduler), DeltaBlue (constraint solver), N-Body (физика) и Splay (самобалансирующееся двоичное дерево). Все портированы на Zef, Lua, Python и JavaScript.

Одна деталь про измерения: Пизло собирает свой интерпретатор компилятором Fil-C++ — это его собственный memory-safe C, который даёт сборщик мусора из коробки, но платит за это примерно 4x производительности. То есть когда в тексте написано «в 35 раз медленнее CPython», держите в голове, что 4x из этого — стоимость безопасности памяти, а остальные ~9x — это то, что будем выжимать.

Исходная точка: в 35 раз медленнее Python

В базовом варианте Пизло сделал два единственных осознанных про производительность выбора:

• 64-битное tagged-представление значений. Значение может быть int32, double или Object*. Double'ы сдвигаются на 0x1000000000000 — техника из JavaScriptCore, которую в литературе зовут NaN-boxing. Целые и указатели лежат как есть. Это позволяет определить тип значения битовой проверкой и не выделять int'ы в куче.
• Язык — C++. Пизло обосновывает: «Java — потолок низкоуровневых оптимизаций слишком низкий, Rust — сборщик мусора требует глобального изменяемого состояния и циклических ссылок, с этим придётся драться или писать много unsafe».

Всё остальное — сознательные «плохие» решения ради скорости разработки:

• Fil-C++ — штраф 4x, но GC бесплатно.
• Рекурсивный AST-интерпретатор через виртуальные вызовы.
• std::string везде — для имён переменных, методов, полей.
• std::unordered_map везде — на каждый Get переменной идёт хеш-лукап по строке.
• Цепочки рекурсивных вызовов по scope chain: класс внутри функции внутри класса внутри функции — каждый доступ проходит через несколько уровней вызовов.

Результат — 35x медленнее CPython, 80x медленнее Lua, 23x медленнее QuickJS. Дальше — что с этим можно сделать, не переписывая интерпретатор на JIT.

#1–2: Прямой вызов операторов и RMW

В Zef выражение a + b эквивалентно a.add(b). Наивный парсер делает одну и ту же AST-ноду для обоих случаев — DotCall(a, "add", [b]). Каждый плюс превращается в лукап строки "add" в Value::callMethod, который каскадом сравнивает её со всеми возможными именами операторов.

Первая оптимизация — парсер генерирует отдельные ноды Binary<> и Unary<>, каждая со своим виртуальным evaluate, который сразу зовёт Value::add, Value::sub и так далее. Без строковых сравнений на каждый плюс.

+17,5%. Вторая оптимизация делает то же самое для += и аналогов — отдельные ноды SetRMW, DotSetRMW, SubscriptRMW. +3,7%. Итог: 1,22x быстрее старта.

#3: Убрать проверку IntObject из быстрого пути

В базовой версии Value различал четыре случая: tagged int32, tagged double, IntObject (для int64, не влезающих в 32 бита) и всё остальное. Фастпас вызывал isInt(), который через виртуальный вызов спрашивал Object::isInt() — на случай, если под обложкой лежит IntObject.

Правка — пусть Value работает только с int32 и double, а весь int64-код уезжает внутрь IntObject. +1%. Мелочь, но копеечка.

#4: Symbols вместо std::string

Это первый по-настоящему большой прирост. В исходном интерпретаторе std::string — это ключ везде, где есть хеш-лукап: локальные переменные, dot-доступ, имена операторов, имена методов. То есть на каждый x + 1 идут хеширование строки "x", strcmp на каждой коллизии, ещё раз для "+".

Оптимизация — классический interning. Новый класс Symbol. Строки превращаются в Symbol* через глобальный hash-consing — одна строка = один указатель. Равенство Symbol* теперь проверяется сравнением указателей, а хеш-таблицы ключуются по Symbol*, а не по std::string.

Правка большая по количеству затронутых файлов, но по сути тривиальная — меняются сигнатуры функций с const std::string& на Symbol*. +18%. Суммарно: 1,46x быстрее старта.

#5: Value Inline

Простая техника: вынести часть методов Value в отдельный заголовочник valueinlines.h, чтобы они видели типы, которые нельзя было включить в value.h из-за циркулярных зависимостей. Компилятор теперь может их инлайнить в горячих местах. +2,8%.

#6: Объектная модель + inline caches + watchpoints — 4,55x одним махом

Самая большая оптимизация в статье, и единственная, которую Пизло специально защищает:

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

Патч объединяет три независимо бесполезных вещи:

Новая объектная модель: Storage + Offsets

В исходной версии каждый lexical scope выделял объект Context, а внутри Context жил hashmap с «полями» — локальными переменными. Объекты пользовательских классов были хуже: каждый объект содержал hashmap «класс → Context», потому что если Bar наследует Foo, поля у них приватные и могут иметь одинаковые имена — нужно различать, к какому классу относится поле.

Новая идея — Storage, который держит данные по Offsets, вычисленным на этапе resolve AST. Context всё ещё существует, но создаётся заранее, а объекты на рантайме просто выделяют Storage размера, который Context уже посчитал. Доступ к полю становится индексом по offset'у, а не лукапом в хеш-таблице.

Inline caches

Классическая техника — обычно её описывают в контексте JIT-компиляторов. Но здесь Пизло применяет её в интерпретаторе: для каждой AST-ноды типа expr.name запоминается тип, который expr имел в прошлый раз, и offset, куда резолвилось name. Запоминание — через placement-new на месте старой ноды: под той же памятью лежит новая специализированная нода, которая умеет быстрый путь.

Специализация может быть: «прямой load из Storage» (для локальной переменной), «проверка класса + direct call в функцию, которую видели в прошлый раз» (для метода). Плюс chain steps и watchpoints, если access требовал обхода scope chain.

Watchpoints

Представим: класс Foo внутри lexical scope, в котором есть переменная x. Метод Foo обращается к x. Внутри Foo имени x нет. Казалось бы, можно делать доступ без проверок. Но кто-то может унаследовать Foo и добавить геттер с именем x — тогда доступ должен пойти в геттер.

Watchpoint — это пассивный охранник: «если кто-то переопределил имя x в подклассе, инвалидируй мой inline cache». Пока имя не переопределяли, доступ работает на минимальных циклах.

Почему всё вместе

Пизло объясняет, почему эти три вещи не разделить:

• Новая объектная модель без inline caches не даёт никакого прироста.
• Inline caches без watchpoints не могут кешировать большинство интересных случаев — слишком много условий.
• И объектная модель, и watchpoints должны работать вместе с самого начала.

+355% — 4,55x быстрее. После этого Zef в 5,2 раза медленнее CPython, в 11,7 раза медленнее Lua, в 3,3 раза медленнее QuickJS. То есть накладные расходы Fil-C++ (примерно 4x) — это уже почти вся разница. Суммарно: 6,8x быстрее старта.

#7: Arguments — свой тип вместо std::vector

Раньше аргументы функций передавались как const std::optional<std::vector<Value>>&. optional нужен, чтобы отличать геттер-вызов o.getter от функции без аргументов o.function() — в Zef это разные вещи для некоторых типов. То есть каждый вызов аллоцировал std::vector, копировал его, и ещё раз копировал в scope функции.

Правка — новый тип Arguments, физически совпадающий с layout scope, который callee создаст. Caller выделяет его напрямую, callee не копирует. Плюс в Fil-C++ std::optional всегда живёт в куче из-за специфики invisicaps — это отдельный штраф. +33%.

#8–10: Специализация геттеров, сеттеров и callMethod

Много методов в Zef устроены тривиально:

Это запись readable f. Метод fn f f — просто чтение переменной. Гонять это через полноценный eval AST'а расточительно. Оптимизация #8 — инференс: если тело функции — это просто Get, заменяем UserFunction на специализированный GetterFunction, делающий load по известному offset'у. +5,6%.

Оптимизация #9 — то же самое для сеттеров (fn set_x(v) x = v). Инференс сложнее — нужно матчить параметр сеттера как источник присваивания. +3,4%. Оптимизация #10 — тривиальная однострочная: inline-инг callMethod в заголовочник. +3,2%. Суммарно: 10,2x быстрее старта.

#11: Глобальная hashtable для method dispatch

Когда inline cache промахивается, старый путь лез через ClassObject::tryCallMethod и tryCallMethodDirect, которые делают два хеш-лукапа на каждый уровень иерархии наследования: «есть ли метод в этом классе» и «есть ли вложенный класс с этим именем». O(depth × 2).

Правка — глобальный hashmap (ClassObject*, Symbol*) → callee, который запоминает все успешные резолвы. Промах по IC теперь — один лукап в эту таблицу, и только если её нет — полный медленный путь. +15%. Суммарно: 11,8x.

#12: Избавиться от std::optional на горячем пути

В Fil-C++ std::optional почти всегда аллоцируется в куче — из-за особенностей union-типов и invisicaps. LLVM может непредсказуемо потерять capabilities указателей внутри union'ов; Fil-C++ компилятор страхуется и вставляет интринсики, которые заставляют всё, что выглядит как union, аллоцировать на heap.

Правка — обход кода, ведущего к std::optional на горячем пути. +1,7%. Важный сайд-эффект для тех, кто пишет на Fil-C++: избегайте union-типов в горячем коде.

#13: ZeroArguments, OneArgument, TwoArguments

Большинство встроенных функций Zef берут 0, 1 или 2 аргумента. Им не нужен полноценный Arguments-объект — он просто занимает память. Три новых типа: ZeroArguments, OneArgument, TwoArguments. Функции шаблонизируются и инстанцируются отдельно для каждого.

ZeroArguments нужен отдельно, потому что (Arguments*)nullptr уже используется для геттер-вызова. Теперь ZeroArguments означает «функция без аргументов». +3,8%.

#14: Slow paths Value через static + by value

Раньше медленные пути Value были member-функциями и принимали неявный const Value*. Значит, caller должен был stack-аллоцировать Value. В Fil-C++ любая stack-аллокация это heap-аллокация.

Правка — сделать эти методы static и принимать Value по значению. Аллокации не нужны. +10%. Суммарно: 13,6x. Это ещё одна «специфичная для Fil-C++» оптимизация, которая в Yolo-C++ (обычный C++) была бы бесплатной по умолчанию.

#15–17: Дедупликация, быстрый sqrt и toString

#15 — «оптимизация» в кавычках: убрать дублированный код в DotSetRMW. Пизло надеялся на прирост от уменьшения кода. Прироста нет — но код чище.

#16 — специализация Dot-ноды для value.sqrt. Inline caches хороши для объектов, но для числовых примитивов они не работают — там фастпас другой, через Binary<>/Unary<>. sqrt в базовом варианте летел через общий путь. Теперь — свой специализированный код. +1,6%.

#17 — то же самое для toString. Плюс чуть меньше аллокаций при конвертации int → string. +2,7%. Суммарно: 14,2x.

#18: Специализация литералов массивов

Код вроде my whatever = [1, 2, 3] по-старому каждый раз спускался в AST и вычислял 1, 2, 3. Но если литерал константный — результат известен на парсинге.

Оптимизация — специализированная ArrayLiteral-нода, которая при вычислении просто копирует заготовленный массив значений. +8,1%. Суммарно: 15,35x.

#19: Value::callOperator по значению

Та же идея, что в #14 — не передавать Value по ссылке в медленный путь callOperator, а принимать его по значению. Ещё одна Fil-C++-специфичная аллокация убирается. +6,5%. Суммарно: 16,3x.

#20–21: Настройки компилятора и отключение ассертов

#20 — билд-система: отключить RTTI и libc++ hardening, потому что Fil-C++ их всё равно перекрывает. Ни одного изменения в C++-коде, только флаги сборки. +1,8%.

#21 — отключить по умолчанию ассерты. Код использовал макрос ZASSERT (всегда проверяет). Замена на ASSERT (только если ASSERTS_ENABLED) должна была дать прирост, но — не дала. Зато готовит код к сборке в обычном C++.

После 21 оптимизации: 16,6x быстрее старта. Zef в 2,1x медленнее CPython, в 4,8x медленнее Lua, в 1,35x медленнее QuickJS. Стартовали с 35x, 80x и 23x разрывов — оказались в окрестностях конкурентов, без строчки JIT.

Переход на обычный C++ — ещё 4x

Финальный эксперимент — собрать тот же код обычным C++ (GCC 11.4.0) вместо Fil-C++. Пизло называет это Yolo-C++ — без гарантий безопасности памяти. Получается ещё 4x. Суммарно: 67x быстрее базовой версии. Zef в 1,9x быстрее CPython 3.10, в 1,2x медленнее Lua и в 3x быстрее QuickJS.

Сборка неидеальна: вместо Fil-C++ GC там calloc, память не освобождается — интерпретатор течёт, просто ScriptBench1 слишком короткий, чтобы это заметить. С реальным GC Yolo-C++-версия была бы ещё быстрее.

В этот момент Zef в 1,9 раза быстрее CPython 3.10, в 1,2 раза медленнее Lua 5.4.7 и в 3 раза быстрее QuickJS-ng 0.14.0. Мы стали в 67 раз быстрее, чем там, где начали.

Итоговая таблица всех оптимизаций

Что получается по ходу работы — в одной таблице (геосреднее по четырём бенчмаркам, чем быстрее, тем лучше):

Выводы

Главное в этом тексте Пизло — не сами оптимизации, а то, что они все простые. SSA здесь нет. GC переделывать не надо. Байткода нет. Машинного кода нет. Есть базовые вещи: не хешировать строки (Symbols), не аллоцировать лишнее (Value by value, специализированные Arguments), не ходить по hashmap'ам (Offsets + IC), запомнить то, что уже видели (inline caches), инвалидировать кеш только когда реально что-то поменялось (watchpoints).

Для тех, кто пишет интерпретатор с нуля — список в статье Пизло работает как чеклист. Первые оптимизации (#1–#5) дают суммарные 1,5x — они дешёвые. #6 даёт 4,55x — это день работы, но переворачивает игру. Всё остальное — серия из 3–8% приростов, которые в сумме добирают разницу.

Для тех, кто хочет потом написать JIT — эта статья объясняет, как выглядит база, на которую JIT потом ложится без сюрпризов. NaN-boxing, новая объектная модель, IC и watchpoints — это ровно то, что должно быть у интерпретатора до того, как вы начнёте генерировать машинный код.

Оригинал: How To Make a Fast Dynamic Language Interpreter, Filip Pizlo, 21 апреля 2026 года. Автор — один из ключевых инженеров WebKit JavaScriptCore, автор FTL JIT, B3, Riptide GC.

В субботу, 29 марта, около 210 экспертов из 24 стран — 130 очно и 80 удалённо — разрешили оставшиеся международные комментарии на встрече в Лондоне (Кройдон, Великобритания). Документ отправляется на финальное голосование ISO (DIS — Draft International Standard) и будет опубликован в ближайшее время.

— C++26 завершён — самый значимый релиз со времён C++11

— Четыре главные фичи: рефлексия, безопасность памяти, контракты, std::execution

— Рефлексия позволяет C++ инспектировать и генерировать собственный код на этапе компиляции

— Hardened stdlib уже развёрнута в Google (1000+ багов исправлено, segfault-ы −30%) и Apple с оверхедом 0,3%

— GCC уже имеет рефлексию и контракты в trunk — можно пробовать сейчас

— Работа над C++29 стартует в июне с фокусом на дальнейшую безопасность памяти

Четыре главные фичи C++26

Херб Саттер, почётный председатель комитета ISO C++ (chair emeritus с 2025 года), называет их «Fab Four» — четвёрка фич, которые делают C++26 прорывным релизом.

1. Рефлексия — крупнейшее обновление со времён шаблонов

Compile-time рефлексия позволяет C++ описывать самого себя и генерировать код на этапе компиляции. Оператор ^ (reflection operator) превращает сущность в её метаданные, а шаблонные функции из пространства std::meta позволяют работать с ними:

По словам Саттера, это «самый мощный новый движок для выражения эффективных абстракций за всю историю C++». Рефлексия попала в драфт C++26 ещё в июне 2025 года.

2. Меньше UB — больше безопасности памяти

C++26 делает существующий код безопаснее просто при перекомпиляции, без изменений в исходниках. UB (undefined behavior, неопределённое поведение) — исторически главный источник уязвимостей в C++. Два ключевых улучшения:

• Чтение неинициализированных переменных больше не UB. Целая категория уязвимостей исчезает при переходе на C++26
• Hardened стандартная библиотека — автоматические проверки границ при обращении к элементам vector, span, string, string_view и десятков других типов. При выходе за границы — trap вместо тихого повреждения памяти

Это не теоретический дизайн. В Google hardened stdlib уже развёрнута на сотнях миллионов строк C++: исправлено более 1000 багов, прогноз — предотвращение 1000–2000 багов в год, segfault-ы по всему production-флоту снизились на 30%. В Apple — аналогичный масштаб. Средние накладные расходы — всего 0,3% производительности.

Из сотен миллионов строк C++ в Google только пять сервисов полностью отказались от hardening из-за проблем с производительностью. Гранулярный API для небезопасного доступа использовался всего в семи местах.

3. Контракты: pre, post, contract_assert

Языковые контракты позволяют задавать предусловия, постусловия и утверждения прямо в объявлениях функций — вместо хрупкого макроса assert из C, который не знает ни о параметрах, ни о возвращаемых значениях:

Фича вызвала серьёзные дебаты. Часть комитета считает, что текущий дизайн контрактов недостаточно продуман — в частности, спорным остаётся поведение при нарушении контракта (вызов хендлера vs немедленный terminate). На финальном голосовании 114 экспертов проголосовали за, 12 — против, 3 воздержались. Рекордно низкое число воздержавшихся показывает, что все определились с позицией.

4. std::execution — асинхронная модель C++

std::execution (Sender/Receiver) предоставляет унифицированный фреймворк для конкурентности и параллелизма. В отличие от std::async и сырых потоков, фреймворк обеспечивает структурированную конкурентность — код свободен от гонок данных по конструкции.

Саттер предупреждает: фича мощная (его компания Citadel Securities уже использует её в production), но пока её сложнее освоить, чем большинство фич C++ — не хватает документации и вспомогательных библиотек.

Быстрое внедрение

Саттер ожидает, что C++26 будет внедряться значительно быстрее, чем C++17/20/23. Две причины:

1. Экстраординарный спрос. Рефлексия нужна всем, кто пишет сериализацию, ORM, конфигурации, логирование. Hardened stdlib даёт безопасность бесплатно. В отличие от нишевых фич C++20 (концепты, модули), здесь каждый C++-разработчик найдёт применение в своём коде
2. Компиляторы уже готовы. На протяжении разработки C++26 и GCC, и Clang уже реализовали две трети фич. GCC уже имеет рефлексию и контракты в trunk — можно пробовать прямо сейчас

Как попробовать C++26 уже сейчас

Рефлексию и контракты можно попробовать в Compiler Explorer (godbolt.org), выбрав GCC trunk с флагом -std=c++26 -freflection. Hardened stdlib в libstdc++ активируется флагами:

C++29: ещё больше безопасности

На встрече приняли расписание C++29 (следующий трёхлетний цикл). Главный фокус — дальнейшее усиление безопасности памяти, в том числе профили безопасности Бьёрна Страуструпа.

Особенно примечателен доклад Оливера Ханта из Apple (P4158R0): WebKit захардинил более 4 миллионов строк кода подходом «подмножество надмножества» (аналогично Profiles). Результат: закрыты целые классы уязвимостей, политики предотвратили бы большинство исторических эксплойтов.

Следующие встречи комитета — в Брно (Чехия) в июне и в Бузиос (Рио-де-Жанейро, Бразилия) в ноябре, где начнётся работа над фичами C++29.

Выводы

C++26 — начало фундаментально новой эры: C++ становится безопаснее по умолчанию, оставаясь верным принципу zero-overhead. Рефлексия даёт инструмент, который заменит тонны макросов и кодогенераторов. Hardened stdlib уже доказала свою эффективность на сотнях миллионов строк кода в Google и Apple.

Подробный отчёт со встречи — в блоге Херба Саттера.

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

Движок на Flutter, но с С++ под капотом

Ключевая идея Fluorite — «Dart-first» архитектура. Логика пишется на Dart и напрямую интегрируется с экосистемой Flutter: виджеты, Hot Reload, Widget Inspector и пакеты из pub.dev работают так же, как в обычных приложениях.

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

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

Графика уровня AAA за счет Filament

Для рендеринга Fluorite использует Filament — 3D-движок Google с поддержкой физически корректного освещения (PBR). Это дает современное качество картинки без необходимости писать собственный рендерер или жертвовать производительностью ради кроссплатформенности.

По словам команды, связка Flutter + Filament позволяет разделить ответственность: UI и взаимодействие остаются на Flutter, а графика и сцена — на специализированном движке.

Чем Fluorite отличается от конкурентов

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

За счет этого итерации быстрее, а входной порог ниже, чем у традиционных игровых движков.

Toyota подчеркивает, что Fluorite — open-source проект и его дальнейшее развитие во многом зависит от сообщества. Судя по архитектуре, компания делает ставку на то, что интерактивные 3D-приложения станут таким же обычным сценарием для Flutter, как мобильные и веб-интерфейсы.

*WhatsApp заменил более 160 000 строк C++-кода на Rust в критически важной части приложения — обработке медиафайлов. Новый код уже развернут на миллиардах устройств: от Android и iOS до веба, десктопа и носимых гаджетов.

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

Откуда вообще взялась проблема

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

Проблема была в системных медиабиблиотеках операционной системы. Именно поэтому приложения вроде *WhatsApp не могли решить ее самостоятельно.

После этого в *WhatsApp появился собственный C++-модуль wamedia, который проверял медиафайлы на соответствие стандартам, чтобы не скормить ОС заведомо опасный контент.

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

Почему именно Rust

В *WhatsApp довольно рано сделали неприятный, но честный вывод: значительная часть критических багов связаны с банальными ошибками работы с памятью в C и C++. Rust эту категорию проблем убирает на уровне языка.

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

Их прогоняли через дифференциальный фаззинг, тесты и сравнение поведения, пока результаты не совпали.

Что получилось на выходе

Итог оказался даже лучше ожидаемого. 160 000 строк на C++ превратились примерно в 90 000 строк на Rust. И это уже с тестами.

Производительность не просела, а потребление памяти в ряде сценариев даже снизилось. Основные сложности были не в коде, а вокруг него: размер бинарников из-за стандартной библиотеки Rust и сборка под десятки платформ.

Тем не менее, библиотеку полностью выкатили в прод. Сейчас этот Rust-код ежемесячно доставляется на миллиарды устройств, включая *WhatsApp, *Messenger и *Instagram.

В *Meta прямо называют это крупнейшим клиентским деплоем Rust, о котором им известно.

Зачем это пользователю, который «просто шлет мемы»

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

Она отсекает битые и нестандартные структуры, ловит подмену типов (когда «картинка» на деле исполняемый файл), отдельно помечает рискованные форматы вроде PDF со скриптами и вложениями.

По сути, это еще один слой защиты. Пользователь его не видит, но это и не нужно.

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

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

Python в 2026: универсальный усилитель для бэкенда, данных и ИИ

В 2026 году Python остаётся языком, который проще всего встроить в уже существующий стек. Он живёт в областях, где важны скорость разработки и плотность экспериментов: машинное обучение и прикладные AI-задачи, data engineering и ETL-процессы, автоматизация рутинных операций, разработка девтулов и утилит; а также в бэкенде, где критичнее гибкость, чем низкоуровневая оптимизация.

Переходить на Python проще всего тем, кто привык мыслить объектно и работать с динамикой. Самый оптимальный вариант — из JS, PHP и Java:

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

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

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

C в 2026: опорный язык для embedded, драйверов и систем реального времени

В 2026 году С остаётся фундаментом там, где железо важнее абстракций. Он работает на микроконтроллерах, в промышленной автоматике, драйверах, прошивках и в RTOS-средах, где критична предсказуемость времени выполнения и полный контроль над ресурсами. Это язык, вокруг которого ещё долго будут строиться системы, способные жить десятилетиями.

Проще всего переход даётся тем, кто уже держал в руках низкоуровневый стек — в C можно войти из C++ и эмбеда:

• Переход с C++ на C естественен из-за общей модели памяти и необходимости понимать стоимость операций.
• Специалисты по встраиваемым системам (embedded) часто начинают с C/C++ и глубоко понимают аппаратную часть, что делает переход к чистому C логичным.

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

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

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

C++ в 2026: высокопроизводительные системы, игры и сложная инженерия

В 2026 году C++ остаётся рабочей лошадкой там, где важны скорость, предсказуемость и возможность вручную управлять каждым уровнем системы. Он используется в игровых движках, графических пайплайнах, симуляторах, системах хранения и в любом ПО, где миллисекунды стоят денег или определяют игровой опыт. Это язык, который не потерял актуальность и вряд ли потеряет — слишком много инфраструктуры на нём держится.

Проще всего переходят те, кто уже понимает низкоуровневую модель — специалисты по C и Rust:

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

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

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

Переход оправдан тогда, когда нужна работа в performance-доменах: игровой dev, real-time-системы, графика, симуляции, базы данных. Если задачи требуют скорости и полного контроля над процессом — C++ остаётся одним из самых мощных инструментов для этого уровня.

Java в 2026: стабильный корпоративный бэкенд и инфраструктура, которая не рушится

В 2026 году Java остаётся одним из самых устойчивых языков для корпоративных систем. Банки, страховые компании, платёжные сервисы, крупные ритейлеры и весь классический enterprise-сегмент продолжают работать на JVM-стеке, потому что он проверен, масштабируется и выдерживает десятки лет развития продукта.

Переход проще всего даётся тем, кто уже жил в объектно-ориентированной модели — C#, Kotlin.

• C#-спецы попадают почти в привычную среду, где меняются лишь инструменты, но не логика разработки.
• Kotlin-разработчики ощущают Java как чуть более формальную, но узнаваемую основу JVM.

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

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

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

C# в 2026: универсальный стек для бэкенда, геймдева и кроссплатформы

В 2026 году C# уверенно держит позицию одного из самых практичных языков для разработчиков, которым нужен сбалансированный стек: промышленный бэкенд, стабильные корпоративные продукты, кроссплатформенная разработка и геймдев на Unity. Это язык, который позволяет работать сразу в нескольких направлениях, не выпадая из экосистемы .NET.

Чаще всего C# живёт в web-бэкенде, корпоративных приложениях и десктопных продуктах — там, где важны производительность, предсказуемость и хорошая интеграция с инфраструктурой. Unity по-прежнему остаётся главным входом в геймдев для начинающих, и именно через него многие приходят в C#, а не наоборот.

Переходить сюда проще Java-разработчикам, из-за схожего объектно-ориентированного синтаксиса.

C# усиливается благодаря развитию .NET и всё более уверенной кроссплатформенности. Этому стеку уже не нужно доказывать свою жизнеспособность: он стабильно используется в компаниях разного масштаба, даёт хороший гарантированный спрос на рынке и регулярно обновляется без резких ломок экосистемы.

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

JavaScript в 2026: опора веба и самый быстрый путь в fullstack

В 2026 году JavaScript остаётся одним из главных рабочих языков для продуктовых команд: он ведёт фронтенд, закрывает часть бэкенда через Node.js и работает в мобильных приложениях.

Перейти сюда проще всего тем, кто уже работал с вебом — PHP и Python:

• PHP-разработчики смогут быстро адаптироваться к асинхронности и современным подходам.
• Python-разработчики оценят низкий порог входа и скорость, с которой можно развернуть рабочий прототип.

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

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

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

Visual Basic в 2026: язык, который до сих пор жив

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

Visual Basic всё ещё встречается в старых внутренних продуктах, отчётных системах, инструментах на базе Excel и в корпоративных контурах, которые строились до эпохи массовой веб-разработки.

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

Входить в Visual Basic с нуля в 2026 году почти никогда не рационально. Это не инвестиция в карьеру, а узкая специализация, завязанная на конкретный контур внутри конкретной компании. Смысл появляется только в одной ситуации: вы уже работаете в организации, которая держит ключевую систему на VB, и переход даёт повышение или расширение роли. Но если слишком хочется, то ориентируйтесь на требования конкретной компании.

Почему не стоит слепо доверять общим рейтингам языков

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

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

Именно поэтому у практикующих разработчиков рейтинги часто вызывают скепсис. В реальной работе языки живут внутри конкретных областей. Геймдев не переезжает на Python или TypeScript, мобильная разработка не отказывается от Swift и Kotlin, системное программирование, embedded и highload по-прежнему требуют C, C++ или Rust. Универсального списка «главных языков года» просто не существует — есть разные наборы под разные задачи.

Отдельный аргумент — рынок вакансий. Он часто даёт более приземлённую картину спроса, чем глобальные индексы. Например, как сообщает Евгений Красников, разработчик ПО, в лидерах оказываются совсем не те языки, которые традиционно доминируют в международных чартах: высокие позиции занимают 1С, Python, Java, JavaScript, PHP, Go. Это не отменяет глобальных трендов, но показывает, насколько сильно результаты зависят от региона и структуры экономики.

Ещё одна проблема рейтингов — они плохо учитывают влияние ИИ на разработку. Да, сегодня Python и JavaScript действительно выигрывают за счёт того, что на них проще и быстрее генерировать код с помощью AI-инструментов. Но это не означает, что весь новый софт будет писаться только на них. Языки по-прежнему выбирают под требования к производительности, безопасности, модели исполнения и жизненному циклу продукта — и эти требования никуда не исчезли.

Поэтому подборка языков в этом материале — не попытка назвать «лучшие языки 2026 года», а способ показать набор устойчивых стеков, которые логично рассматривать при обновлении навыков. Рейтинги здесь — отправная точка для разговора, а не истина в последней инстанции. В реальности язык почти всегда выбирается не по позиции в индексе, а по домену, типу задач и карьерной стратегии разработчика.

Как выбрать язык для перехода: дорожная карта

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

Основой выбора остаются три фактора: текущий стек; домен, в котором вы уже сильны; рынок, куда хотите сместиться (корпорации, международные компании или продуктовые команды).

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

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

– backend → backend на другом языке;

– data → data с расширением инструментов;

– frontend → fullstack как способ увеличить гибкость и ценность в команде.

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

Ну и напоследок даем совет от Игоря Алентьева, продуктового разработчика и создателя агрегатора IT-вакансий hirify.me.

Нет никакого смысла учить в 2026 что то кроме питона и js/ts: весь новый софт пишется на них (не в последнюю очередь, потому что на них отлично пишет AI), поэтому если нет исключительной любви к легаси или какому-то определенному языку, просто берите их и не ошибетесь.
Если есть любовь к энтерпрайзному софту, всяким банкам/телекомам, то подойти могут java/kotlin/c#. Но это нисходящий тренд на горизонте 5-10 лет.
В целом, нужно учиться работать с AI, ведь через какое-то количество лет код не будут писать руками, только проектировать.

Желаем удачи в переходе на новый язык!

Она затрагивает практически все версии MongoDB, выпущенные с 2017 года. С ее помощью удаленный атакующий может читать произвольные участки памяти сервера.

Проблема скрывалась в обработке сжатых сообщений zlib на сетевом уровне. Уязвимость уже исправлена в актуальных версиях, но старые релизы — 3.6, 4.0 и 4.2 — патчей не получат. Все потому что они находятся в статусе EOL.

На первый взгляд это выглядит как очередной баг в низкоуровневом коде. На деле — одна из самых опасных уязвимостей для публично доступных баз данных.

В чем суть бага

MongoDB использует собственный бинарный протокол и формат BSON. Сообщения могут передаваться в сжатом виде — в таком случае клиент сам указывает размер данных после распаковки.

Ошибка заключалась в том, что сервер без проверки доверял этому значению. Атакующий мог указать, что сообщение после распаковки весит, например, 1 МБ, хотя реально там был 1 КБ.

MongoDB выделяла в памяти большой буфер, распаковывала туда данные и оставляла остальное пространство заполненным «мусором» из неинициализированной памяти.

Почему это приводит к утечке данных

MongoDB написана на C++, а значит память после malloc не очищается автоматически.

И в том «мусоре», который заполнил излишек памяти, могут оказаться фрагменты предыдущих операций: пароли, токены, ключи API, пользовательские данные, IP-адреса и конфигурация системы.

Дальше вступает в игру BSON. Поля в нем хранятся как C-строки с \0 в конце. Если отправить специально сформированное сообщение без нулевого байта, сервер будет читать память дальше — пока не наткнется на первый \0. А затем вернет эту строку в сообщении об ошибке клиенту.

В итоге сервер сам отдает атакующему куски своей памяти.

Эксплуатация без логина и пароля

Самое неприятное — уязвимость срабатывает до аутентификации. Разбор входящего сообщения происходит раньше, чем проверка прав доступа. Это значит, что для атаки достаточно сетевого доступа к MongoDB. Логин, пароль и любые учетные данные не нужны.

С учетом того, что поисковики вроде Shodan находят более 200 000 MongoDB-инстансов, доступных из интернета, масштаб проблемы становится очевиден.

Почему 8 лет — это катастрофа

По данным исследователей, баг появился еще в 2017 году, начиная с MongoDB 3.6. Он существовал почти 8 лет. Насколько активно его использовали — неизвестно, но с учетом простоты эксплуатации трудно поверить, что им никто не воспользовался.

Исправление оказалось размером буквально в одну строку. Тем не менее, публичная коммуникация со стороны MongoDB выглядела сдержанной.

Сначала вышел CVE, затем — патч, а полноценное объяснение появилось позже. В компании заявили, что не нашли признаков эксплуатации, но подтвердить это задним числом практически невозможно.

Почему MongoBleed — тревожный сигнал

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

Его формулировка предельно прямолинейна: цель — убрать каждую строку C и C++ к 2030 году и заменить их кодом на Rust.

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

Ставка на ИИ и автоматическую переработку кода

Ключевым инструментом в этом процессе станет ИИ. По словам Ханта, Microsoft уже выстроила инфраструктуру, которая объединяет алгоритмы анализа кода и ИИ-агентов.

Система строит графы зависимостей на уровне миллионов строк исходников, после чего ИИ применяет изменения автоматически и в промышленных масштабах.

Внутренняя цель проекта звучит амбициозно: «1 инженер, 1 месяц, 1 миллион строк кода». По утверждению Microsoft, базовая часть этой инфраструктуры уже работает — как минимум для задач на понимание и анализа кода.

Почему именно Rust

Переход на Rust не стал сюрпризом. Еще в 2023 году Microsoft объявила, что новые компоненты ядра Windows больше нельзя писать на C и C++. Тогда же Марк Русинович, CTO Azure, прямо заявил: компания «полностью делает ставку на Rust».

Причина банальна — Rust обеспечивает безопасность памяти по умолчанию. Для Microsoft, которая десятилетиями сталкивается с уязвимостями классов use-after-free и buffer overflow, это банально стратегический выбор.

Кто будет переписывать код Microsoft

Хант уже ищет Principal Software Engineer, который поможет развивать инфраструктуру автоматического перевода C и C++ в Rust.

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

Команда входит в группу Future of Scalable Software Engineering внутри Microsoft CoreAI. Ее задача — не только переписать код компании, но и создать инструменты, которые позволят устранять технический долг «в промышленных масштабах».

Два патча с этой функцией уже добавлены в ветку kbuild-next, которая отвечает за сборочную систему ядра. И, по всей видимости, они попадут в окно слияния Linux 6.19.

Что изменится

Патчи включают глобальный флаг компиляции -fms-extensions для GCC и Clang.

Эта опция активирует нестандартные расширения C, поддерживаемые компилятором Microsoft Visual C/C++. Например, возможность анонимно встраивать структуры и объединения (struct/union) друг в друга.

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

Почему это важно

Ранее предложения включить -fms-extensions всплывали в рассылках разработчиков ядра не раз. Первые упоминания датируются еще 2007 годом. Но все это время они так и не доходили до релиза.

Теперь же, когда патчи уже в kbuild-next, их шансы попасть в мейнлайн выше, чем когда-либо.

Разработчик Расмус Виллемоэс, предложивший изменение, объясняет:

«Каждый раз, когда обсуждается включение -fms-extensions, выясняется, что код можно написать и без него. И получается «не слишком ужасно». Но если, как говорит Линус, просто стиснуть зубы и включить этот флаг раз и навсегда, он будет доступен всякий раз, когда ему найдется применение. И отдельным примерам не придется оправдывать его использование».

Что думает Линус Торвальдс

Сам Торвальдс, судя по его последним комментариям в рассылке, не возражает против включения Microsoft C Extensions в Linux 6.19.

Это довольно символично: ядро, десятилетиями противопоставлявшее себя экосистеме Microsoft, теперь официально допускает поведение компилятора из Visual Studio.

Что это даст разработчикам

• возможность использовать вложенные структуры без явных имен;
• немного чище и компактнее код в ряде подсистем;
• унификацию сборки под GCC и Clang;
• потенциальное упрощение кроссплатформенных драйверов и библиотек.

Не всем идея нравится — часть разработчиков считает неправильным позволять «поведение Microsoft» в коде ядра Linux.

Но если патчи пройдут ревью, то начиная с Linux 6.19 в ядре впервые официально появится поддержка расширений языка C из Visual Studio — шаг, о котором 15 лет назад в рассылке ядра даже не мечтали.

Об этом рассказал Логан Килпатрик, продакт-лид Google AI Studio, в посте на X.

Что такое вайб-кодинг

Термин vibe coding (от англ. vibe — «ощущение», «настроение») появился в 2024 году и описывает подход к программированию, где разработчик не пишет код вручную, а общается с ИИ в свободной форме, задавая лишь общие направления: «сделай RPG про кота-самурая», «добавь погодные эффекты», «пусть враги становятся умнее».

Пока этот подход работал только с простыми проектами вроде сайтов и мобильных приложений, но Google обещает вывести его на новый уровень.

Что умеет новый AI Studio

По словам компании, обновленный Google AI Studio «понимает задачу и автоматически подбирает нужные модели, API и инструменты».

Например, если пользователь захочет сделать приложение, генерирующее изображения по промтам, AI Studio сам подключит соответствующий API (в данном случае — Nano Banana API) и настроит всю инфраструктуру.

«Мы сделали процесс создания мощных, функциональных и ИИ-дополненных приложений максимально простым», — говорится в блоге Google.

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

Теперь и для игр

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

«Это откроет путь для новых 100 млн разработчиков. Многие мечтают сделать игру, но спотыкаются о C++, C# и Unreal Engine. Теперь они смогут создавать истории, персонажей и геймплей — без единой строчки кода», — написал он.

Разумеется, до уровня Civilization или Baldur’s Gate дело не дойдет. По словам Килпатрика, речь идет о «небольших проектах для друзей», где игроки сами управляют сюжетом и механикой.

Скепсис и ожидания

Пока даже самые продвинутые ИИ-инструменты едва справляются с генерацией простых 2D-игр вроде Wordle или Flappy Bird.

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

Тем не менее, Google, по слухам, готовит к релизу Gemini 3.0, который может радикально улучшить креативные и кодогенерационные возможности.

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

«Сделай мне космический шутер, где коты сражаются против пылесосов».

Реализация обработки нажатий клавиш в GLFW

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

Callback-функция должна иметь следующую сигнатуру:

и устанавливается с помощью функции GLFW glfwSetKeyCallback.

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

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

Мы устанавливаем для неё значение true перед запуском основного игрового цикла. Дополнительно, внутри главного цикла мы проверяем, остаётся ли эта переменная равной true.

Если она изменится (например, после нажатия клавиши Esc), это будет сигналом к завершению работы программы.

если нет — цикл завершается, происходит корректный выход из игры.

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

Здесь параметр mods указывает, были ли нажаты какие-либо модификаторы клавиш — например, Shift, Ctrl и другие. Scancode — это системный код клавиши, который в данном случае мы не используем.

И наконец, при инициализации окна мы устанавливаем callback-функцию GLFW, чтобы она вызывалась при каждом событии клавиатуры.

Если всё сделано правильно, вы сможете выйти из игры, нажав клавишу Esc.

Добавляем движение игрока

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

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

Мы делаем это, присваивая значение +1 для стрелки вправо и –1 для стрелки влево.

Если одна из клавиш нажата, её значение добавляется к move_dir; если отпущена — вычитается. Например, если обе клавиши нажаты одновременно, то move_dir = 0.

Эту логику реализуем, добавив два дополнительных случая (case) в наш callback функции обработки клавиш.

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

Это делается просто: в каждой итерации игрового цикла мы проверяем значение move_dir и изменяем координату player.x в соответствии с направлением движения — например, уменьшая её при движении влево и увеличивая при движении вправо.

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

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

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

Добавим стрельбу

Добавление стрельбы снарядами (пулями) немного сложнее. Как и в предыдущем разделе, мы добавляем глобальную переменную, которая будет указывать, нажата ли кнопка выстрела.

Привязываем выстрел к клавише пробела (Space), добавив ещё один блок switch case в функцию обработки нажатий клавиш (key callback).

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

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

Затем мы добавляем новую структуру для снарядов (projectiles) — аналогично тому, как ранее создавались структуры для игрока (Player), пришельцев (Aliens) и других игровых объектов.

Переменная dir указывает направление движения снаряда — вверх (в сторону пришельцев, значение +) или вниз (в сторону игрока, значение -).

Прошу прощения за то, что в коде я называю снаряды «Bullets» (пули) — это связано с тем, что изначально я использовал именно это обозначение.

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

При инициализации игры мы задаём количество пуль:

game.num_bullets = 0,

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

Как вы можете видеть, сейчас снаряд отображается в виде небольшой вертикальной линии.

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

После отрисовки мы обновляем позиции снарядов, добавляя значение dir (направление движения).

Если какой-то снаряд выходит за пределы игрового поля, мы удаляем его из массива активных объектов. Для этого используется распространённый приём: вместо сдвига всех элементов массива, удаляемый элемент перезаписывается последним элементом массива, а общее количество снарядов (num_bullets) уменьшается на единицу.

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

Наконец, обработка выстрелов игрока выполняется в конце основного игрового цикла (main loop).

На этом этапе программа проверяет, нажата ли клавиша стрельбы (в нашем случае — пробел) и есть ли место для добавления нового снаряда в массив пуль. Если оба условия выполнены, создаётся новый объект снаряда: ему присваиваются начальные координаты (позиция игрока), направление движения вверх (dir = +1) и он добавляется в список активных снарядов.

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

Так мы задаём направление движения снаряда dir = +2.

Нам нужно больше пришельцев для вторжения

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

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

В коде это удобно реализовать при помощи перечисления (enum), где каждый элемент будет представлять тип пришельца — например, ALIEN_TYPE1, ALIEN_TYPE2, ALIEN_TYPE3 и ALIEN_DEAD.

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

Добавляем флаг в структуру Alien, который указывает тип пришельца.

Затем мы сохраняем спрайты пришельцев в виде массива, индексируемого по типу пришельца и индексу кадра анимации. Таким образом, каждый тип врага (например, обычный, продвинутый или «мертвый») может иметь собственный набор спрайтов, а также отдельные кадры для анимации движения.

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

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

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

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

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

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

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

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

Счётчики смерти (death counters) обновляются в отдельном цикле, который выполняется до обновления снарядов.

Взрывы

Теперь у нас наконец-то есть всё необходимое, чтобы реализовать самый зрелищный элемент Space Invaders — взрывы пришельцев!

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

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

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

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

Обратите внимание: мы используем упрощённый способ выравнивания спрайта смерти, поскольку в игре пока не реализована корректная обработка центрирования спрайтов.

Если вы скомпилируете код, представленный в этом разделе, вы сможете взорвать парочку пришельцев!

Заключение

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

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

Мы увидели, что можно создать прототип игры на низкоуровневом языке программирования с минимальными усилиями. Более того, этот код легко переиспользовать для других 2D-проектов.

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

В этой части мы сделаем несколько ключевых шагов:

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

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

Добавление игрока и роя пришельцев

Прежде чем добавить игрока и рой пришельцев, создадим два агрегата данных — то есть структуры (struct):

И у структуры игрока, и у структуры пришельца есть координаты позиции x и y, заданные в пикселях относительно нижнего левого угла окна. В структуру Player также добавляется поле с количеством жизней игрока.

В классических аркадных играх Space Invaders существует три типа пришельцев, которые отличаются только своими спрайтами. Этот параметр мы кодируем в поле type.

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

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

Как и ранее, мы добавляем спрайт для игрока, закодированный в виде растрового изображения (bitmap).

Затем мы создаём и инициализируем структуру Game.

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

Наконец, в основном игровом цикле мы отрисовываем игрока и всех пришельцев.

Получаем вот такой результат:

Это уже начинает напоминать Space Invaders, но пока всё довольно статично!

Анимация спрайтов

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

Структура SpriteAnimation по сути представляет собой массив Sprite. Здесь мы используем тип «указатель на указатель» для хранения спрайтов, чтобы их можно было шарить (совместно использовать). Если хочется повысить эффективность, спрайты можно упаковать в атласы (spritesheets). Кроме того, мы добавляем флаг, указывающий, нужно ли зацикливать анимацию или воспроизводить её лишь один раз, интервал между последовательными кадрами и время, проведённое в текущем экземпляре анимации. Зная число кадров и желаемую длительность анимации, интервал между кадрами легко вычислить. Ниже мы вводим дополнительный спрайт для нашего инопланетянина…

…и создаём двухкадровую анимацию, используя два спрайта пришельца.

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

Большинство современных мониторов имеют частоту обновления 60 Гц, что означает обновление экрана 60 раз в секунду. Включив V-sync, мы получим частоту кадров 60 FPS или кратное значение, синхронизированное с частотой дисплея.

Однако есть и недостаток: на мониторах с более высокой частотой обновления, например, 120 Гц или 240 Гц, игра будет работать быстрее. Чтобы включить V-sync, вызывается функция GLFW:

В конце каждого кадра мы обновляем все анимации, увеличивая значение времени.

Если анимация дошла до конца, мы либо удаляем её, либо сбрасываем время обратно в 0, если это зацикленная анимация.

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

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

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

Чтобы сделать процесс более интересным, мы также добавляем простое движение игрока, введя переменную, которая управляет направлением его движения…

…и обновляем положение игрока в конце каждого кадра в зависимости от значения этой переменной.

Условия if выполняют простую проверку столкновений спрайта игрока с границами игрового поля, гарантируя, что игрок остаётся внутри этих границ.

Выше вы можете видеть анимированный GIF с результатом.

Заключение

В этом посте мы создали несколько структур (struct), чтобы логически сгруппировать данные для игры, игрока и пришельцев. Ещё важнее то, что мы заложили основу для анимации спрайтов. Для этой простой версии Space Invaders мы используем фиксированные игровые циклы, задав постоянную частоту кадров с помощью включения вертикальной синхронизации (V-sync). Это позволяет нам выполнять анимацию спрайтов в игровых циклах, а не в реальном времени.

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

Рендеринг на стороне CPU

GPU отлично справляется с обработкой больших объёмов данных, но программировать графический процессор сложнее, чем CPU. Для простого клона Space Invaders, который я создаю здесь, проще выполнять всю отрисовку на центральном процессоре (CPU), используя буфер — участок памяти, представляющий собой пиксели игрового экрана. Затем этот буфер можно передать на GPU в виде текстуры и вывести на экран компьютера.

Буфер имеет определённую ширину и высоту. Мы представляем каждый пиксель в виде значения типа uint32_t, что позволяет хранить четыре 8-битных компонента цвета для каждого пикселя. В нашем случае мы будем использовать только 24 бита — по 8 бит для красного (red), зелёного (green) и синего (blue) каналов. Можно возразить, что логичнее было бы использовать uint8_t, но я применяю 32-битное значение, потому что так проще работать с индексами при обращении к элементам массива. Чтобы использовать эти типы целых чисел с фиксированной разрядностью, необходимо подключить стандартный заголовочный файл:

Чтобы упростить определение цветов в виде значений типа uint32_t, мы создадим следующую функцию:

Эта функция устанавливает три старших байта (24 бита) в значения r, g и b соответственно.

Оставшиеся 8 младших битов заполняются значением 255 — хотя, как упоминалось ранее, альфа-канал (прозрачность) в нашем случае не используется. Далее мы создаём функцию, которая очищает буфер, заполняя его указанным цветом.

Эта функция проходит по всем пикселям буфера и устанавливает для каждого заданный цвет.

Теперь, в главной функции (main), мы инициализируем буфер — то есть создаём область памяти, где будут храниться все пиксели экрана:

Этот код создаст буфер с шириной buffer_width и высотой buffer_height, а также заполнит его цветом clear_color, то есть зелёным.

Шейдеры OpenGL

После того как мы создали буфер, нам нужно настроить OpenGL, чтобы иметь возможность вывести его содержимое на экран. В современном OpenGL большая часть обязанностей, которые раньше выполнял драйвер, теперь ложится на разработчика. Он должен сам писать небольшие программы, которые выполняются на видеокарте (GPU) — такие программы называются шейдерами (shaders).

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

Старый OpenGL иногда называют fixed pipeline — «фиксированный конвейер», поскольку его этапы были заранее определены и не могли быть изменены программистом.

В современном OpenGL почти все этапы программируемы, и основные среди них два:

• Vertex Shader (вершинный шейдер) — обрабатывает данные вершин, обычно выполняет трансформацию объектов в координаты экрана.
• Fragment Shader (фрагментный шейдер) — работает с пикселями, полученными после растеризации. Он определяет их цвет, глубину и, при необходимости, трафаретные значения (stencil).

Эти два шейдера — минимально необходимые для работы любого рендеринга в OpenGL.

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

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

Для фрагментного шейдера нам просто нужно считать значение из текстуры буфера и вывести результат этого выборочного чтения.

Обратите внимание, что выходное значение вершинного шейдера TexCoord теперь используется как вход для фрагментного шейдера. Хотя вершинному шейдеру не требуется передавать какие-либо данные о вершинах, мы всё же должны указать, что будем рисовать три вершины. Для этого создаётся объект вершинного массива (VAO).

Если упростить, VAO (Vertex Array Object) — это структура в OpenGL, которая хранит формат вершинных данных вместе с самими данными вершин. Наконец, оба шейдера нужно скомпилировать в код, понятный GPU, а затем связать их в единый шейдерный программный объект.

В приведённом выше фрагменте кода шейдерная программа сначала создаётся с помощью функции glCreateProgram. Отдельные шейдеры создаются функцией glCreateShader и компилируются с помощью glCompileShader. После этого они присоединяются к программе через glAttachShader, после чего сами объекты шейдеров можно удалить.

Программа связывается вызовом glLinkProgram. Во время компиляции OpenGL выводит различную информацию — аналогично тому, как это делает компилятор C++. Однако, чтобы получить эти сообщения, их нужно перехватывать вручную. Для этого созданы две простые функции: validate_shader и validate_program.

Текстура буфера

Для передачи данных изображения на GPU используется текстура OpenGL. Как и в случае с VAO, текстура также объект, который вместе с данными изображения содержит информацию о формате этих данных. Сначала текстура создаётся с помощью функции glGenTextures.

Затем задаём формат изображения, а также некоторые стандартные параметры, определяющие поведение выборки текстуры.

Здесь мы указываем, что изображение должно использовать 8-битный RGB-формат для внутреннего представления текстуры. Последние три параметра вызова glTexImage2D определяют формат пикселей данных, которые мы передаём в текстуру: каждый пиксель находится в формате RGBA и представлен четырьмя беззнаковыми 8-битными целыми числами.

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

Теперь нам нужно привязать текстуру к uniform-переменной sampler2D во фрагментном шейдере. В OpenGL существует несколько текстурных единиц, к которым может быть привязан uniform. Мы получаем расположение uniform-переменной в шейдере (его можно рассматривать как своего рода «указатель») с помощью glGetUniformLocation и устанавливаем её на текстурную единицу 0 с помощью вызова glUniform1i.

Отображение буфера

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

Если теперь вызвать:

То содержимое созданного окна должно отобразиться зелёным цветом.

Отрисовка спрайта

В предыдущем посте мы уже создали окно и вывели на экран цвет. Заканчивать эту часть на том же этапе было бы скучно — так что теперь давайте что-нибудь нарисуем.

Сначала я определяю простой спрайт:

Это просто участок данных, размещённых в куче, вместе с указанием ширины и высоты спрайта. Сам спрайт представлен в виде битовой карты (bitmap) — то есть каждый пиксель кодируется одним битом, где значение 1 означает, что пиксель спрайта включён (“on”).

Далее мы создаём функцию, которая отрисовывает спрайт в буфере с заданным цветом.

Функция просто проходит по пикселям спрайта и рисует активные (“on”) пиксели по указанным координатам, если они находятся в пределах границ буфера.

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

В главной функции (main) мы создаём спрайт пришельца (alien sprite).

Чтобы нарисовать красный спрайт в позиции (112, 128), вызываем:

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

Если скомпилировать и запустить финальный код из этого поста, то вы увидите красную текстуру в центре зелёного фона.

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

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

Автор написал клон классической аркады Space Invaders на C++, опираясь всего на пару зависимостей. В этой части мы подготовим окно и контекст OpenGL 3.3, используя GLFW и GLEW — это единственные внешние библиотеки, которые понадобятся на старте.

Что такое Space Invaders

Space Invaders — аркадная игра 1978 года. Это 2D-шутер с горизонтальным управлением: игрок двигает пушку вдоль нижней границы экрана и стреляет по строю инопланетян. За каждого сбитого врага начисляются очки. Периодически по верхней части экрана пролетает НЛО — если сбить, получите бонусные очки. По мере уничтожения инопланетян игра ускоряется. Враги тоже стреляют случайно, приближаясь к низу экрана; попадание по игроку отнимает жизнь. Пушку частично прикрывают бункеры, но они постепенно разрушаются как под выстрелами врагов, так и самим игроком. После зачистки волны появляется новая, а бункеры восстанавливаются. Игра заканчивается, если бункеры полностью разрушены, инопланетяне достигли низа экрана или у игрока закончились жизни.

Постановка целей

Важно определить цели до начала проекта. Мы не собираемся дотошно воссоздавать оригинал — сделаем «space-invaders-like» прототип с базовыми элементами. В геймдеве обычно сначала собирают «грубый» прототип, чтобы проверить ядро механик, а «полировать» будем позже.

В прототипе нужны:

• управляемая игроком пушка;
• волны инопланетян, которые постепенно движутся к пушке;
• стрельба у обеих сторон.

НЛО и бункеры на первом этапе опустим (их несложно добавить потом).

Почти любую игру можно разложить на базовые элементы (очень советую доклад Raph Koster). В Space Invaders это движение и стрельба (а значит — детекция столкновений). Даже простой клон поможет прокачать понимание геймлупа, коллизий и правил игры.

Поехали!

Hello Window

Окно можно создать по-разному: нативные API (Cocoa/X11/WinAPI) или кроссплатформенные библиотеки (Qt, GLFW). Нативный путь даёт полный контроль, но ради простоты и кроссплатформенности возьмём GLFW: лёгкая, простая C-API.

Подключим заголовки (стандартный ввод/вывод и GLFW):

Это откроет окно 640×480 с заголовком Space Invaders и контекстом OpenGL. Два последних параметра glfwCreateWindow — монитор для фуллскрина и «шаринг» контекста между окнами. При неудаче вызываем glfwTerminate(). Важно: нужно «привязать» контекст текущему потоку (glfwMakeContextCurrent), чтобы последующие вызовы OpenGL применялись к нему.

По умолчанию версия контекста не гарантируется — попросим минимум 3.3 Core (задать до создания окна):

Почему нужен загрузчик функций OpenGL. OpenGL — это спецификация; реализация зависит от GPU/драйвера/ОС. Множество функций нужно загружать в рантайме. Делать это вручную неудобно, поэтому используют лоадеры. Здесь — GLEW (можно и GLAD, но в статье выбран GLEW).

Важно: подключаем GLEW до glfw3.h:

Игровой цикл (Game loop)

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

• Буферы. Современный OpenGL рисует в «задний» буфер, а «передний» отображается на экране. glfwSwapBuffers() меняет их местами.
• События. glfwPollEvents() вынимает накопившиеся события (клавиатура, мышь, закрытие окна).
• Выход. glfwWindowShouldClose() станет true, если пользователь нажал «крестик».

В конце корректно освобождаем ресурсы:

Компиляция

Ниже — команды из оригинала (C++11), плюс современные примечания.

Обратите внимание, что позже мы будем использовать некоторые функции C++11, поэтому компилируем с помощью -std=c++11. В обоих случаях убедитесь, что у вас установлен GLFW 3. В Linux, в зависимости от вашего дистрибутива, вы можете использовать менеджер пакетов. Например, в Ubuntu GLFW можно установить с помощью следующей команды:

На Mac OS X автор предпочитает использовать Homebrew:

Возможно, эта статья поможет вам настроить проект GLFW в Visual Studio.

Если всё собрано успешно, вы увидите красное окно с заголовком Space Invaders.

Итоги

Даже просто «поднять окно» с контекстом OpenGL на C++ — задача не из быстрых, несмотря на помощь GLFW. Мы пока ничего не рисуем; настройка простейшего рендера в современном OpenGL тоже требует подготовки. Хорошая новость — делать это придётся один раз, а дальше вы переиспользуете базу в следующих частях (шейдеры, VBO/VAO, спрайты, коллизии и т. д.).

Вторая часть статьи — здесь

В этой статье будет много моих выводов, гипотез и идей. Это моя первая статья, поэтому буду рад услышать аргументированную критику. В статье часто используется псевдокод, чей синтаксис напоминает смесь C#, C++ и Python.

Немного о терминологии

Много времени я программирую на C#, и в этом языке существуют некоторые термины, которые могут ввести в заблуждение программистов на C++:

• Под словом коллекция я подразумеваю любой набор элементов: список, массив, стек, куча, итератор, множество и т.п.
• Говоря список, я подразумеваю динамический массив

Язык программирования – инструмент

Языки можно поделить на две большие группы: предметно-ориентированные языки (aka DSL) и языки общего назначения (ЯОП). DSLи точно можно назвать инструментами, так как они по определению решают конкретную задачу. С языками общего назначения все несколько сложнее. ЯОПы имеют техническую возможность реализовать любой алгоритм, то есть полны по Тьюрингу. Но это не значит, что для каждой задачи будет эффективно использовать язык X, ведь язык Y может подходить для решения каких-то задач лучше.

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

Рассмотрим банальный пример. C# лучше использовать для написания бекенда сайтов, чем Си. Используя C#, вы делаете вклад в возможность поддержки проекта, уменьшаете порог входа в проект, пишете платформо-независимый код. Си лучше использовать в задачах, где важна производительность или низкоуровневый доступ к ресурсам. Например при написании runtime библиотеки языка, игрового движка или кода под микроконтроллеры с небольшими ресурсами.

Также некоторые языки имеют хорошую поддержку сообщества в каких-то специфических областях. Например C# и C++ – доминируют в создании игр, Python и R – преобладают в data science, JavaScript и PHP – в создании сайтов и т.п. В силу своих реализаций не все ЯОП могут решать задачи друг друга эффективно. Интерпретируемый язык никак не может быть также быстр в исполнении, как статически компилируемый, но может выигрывать в скорости кодирования.

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

А в чем проблема?

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

Python не станет быстрым, C++ не будет хорошо подходить для написания скриптов, а Fortran не получит современный синтаксический сахар.

Если вы программировали на C# и Unity, возможно, вы писали какие-нибудь математические функции или методы-расширения. Я с разочарованием для себя обнаружил, что Unity использует C# 9-той версии, в которой нет обобщенной арифметики (ее введут в C# 11). Скорее всего, красиво и лаконично реализовать какой-нибудь метод SquareMagnitude не получится: придется писать одну и ту же реализацию для каждого типа по отдельности (дженерики не помогут: нет обобщающего интерфейса).

Помимо этих реализаций, было бы неплохо иметь реализацию с типами: byte, sbyte, ushort, uint, ulong, decimal. Хорошо, что метод SquareMagnitude достаточно маленький, но если бы это был большой метод, код стал бы еще хуже. Принцип DRY (don’t repeat yourself) плачет в сторонке.

Extensible Programming

Решением видится расширяемое программирование (Extensible Programming) – это парадигма программирования, когда расширяемость возводится в абсолют. Возможности языка не фиксированы, а могут быть расширены. Программист пишет не только расширяемые модульные программы, но и программирует на расширяемом языке. Программист имеет возможность изменять синтаксис языка, исполняемый движок (компилятор/интерпретатор/JIT’а и т.п.), среду исполнения (environment) – все то, что мы называем Toolchain’ом языка. Эта парадигма позволяет кастомизировать язык программирования, добавлять eDSL (embedded DSL, встроенные в язык. Как пример: LINQ в C#). Зачастую кастомизация даже представляется как одно из основных средств программирования. Например, на расширяемом языке есть возможность добавлять новые синтаксические конструкции, изменять AST, байткод, контролировать процесс компиляции, изменять среду исполнения и т.п. Самые известные из расширяемых языков: Ruby, Lisp, Lua.

Предлагаю посмотреть эту статью на хабре, в которой демонстрируется пример написания простенького генератора кода для элегантных лямбд на Lua. Это пример расширяемого синтаксиса языка. Ruby тоже имеет расширяемый синтаксис, например для него написана библиотека superators19, позволяющая добавлять новые операторы в язык.

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

Моя модель идеального языка программирования

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

Например, представим что JavaScript сделан по данной идее, и хочется добавить в язык рантайм-проверку типов (на минуту забудем про существование TypeScript). Можно было бы написать модуль, который добавляет немного нового синтаксиса в объявление переменных, обрабатывает AST (т.е. использует модуль парсера) и добавляет в каждое использование переменной/поля/т.п. проверку на ее тип.

Псевдо-код реализации модуля мог бы выглядеть как-то так:

Абстрактные детали реализации

Итак, какие задачи языка мы имеем на данный момент? ЯП должен:

• иметь возможность расширять свои frontend, middle-end, backend
• иметь простой API для расширения
• поддерживать большинство парадигм (функциональное, декларативное программирование)

Сначала разберемся с первыми двумя задачами. Как уже было сказано ранее, архитектура языка будет модульной. Значит нужно просто для каждого модуля предусмотреть возможность интеграции с другими модулями. При этом желательно предоставить интуитивный API для доступа к различным частям модуля. Кроме того, каждому модулю не плохо иметь свое краткое описание работы, ведь для написания своих модулей придется иметь понимание всех модулей, которые должны использоваться.

Рассмотрим пример с созданием простейшего фронтенда. Простой фронтенд может быть разделен на небольших модуля: лексер и парсер. Допустим, программист захотел добавить препроцессор перед лексером. Какой удобный API можно предоставить? По моему мнению, хорошо подходят события. Пусть лексер и парсер имеют события OnPreprocess и OnPostprocess. Таким образом, например, программист будет иметь возможность обработки последовательности лексем уже после ее генерации. Также программист сможет изменять AST уже после его генерации.

Но как добавлять новые правила построения дерева или лексемизации текста? Можно создать методы по типу AddLexerRule, AddParserRule, которые будут принимать в себя экземпляры классов, имплементирующих интерфейсы ILexerNodeBuilder и IParserNodeBuilder. Но стоит учесть, что в большинстве языков грамматика не самая простая, а значит, что парсер желательно делать по мощности LR(k), LALR(k) или ALL(*). Возможно стоит сделать небольшой DSL для этих модулей, так как это сильно упростит поддержку языка в дальнейшем (или использовать уже готовый, такой как ANTLR). DSL поможет программистам не погружаться в технические подробности реализации и достаточно просто добавлять изменения в грамматику.

Но как же коллизии имен? Конечно, они будут возникать гораздо чаще, поэтому стоит предусмотреть некое подобие namespace’ов. Например, если в начале файла написано use parser.math, то парсер активирует дополнение к текущей грамматике, добавляющее математические операторы.

Модули

Что, если язык окажется сложным? Например, парсер будет очень тяжелым, язык будет использовать супероптимизаторы или просто модуль окажется проприетарным. В таком случае желательно иметь возможность разбросать модули по разным физическим местам. Например, чтобы разместить супероптимизатор в облаке, парсер поставить на компьютер с бОльшим количеством оперативной памяти, а доступ к проприетарному модулю давать только через web-request’ы (чтобы нельзя было получить исходный код).

Хорошим решением оказывается представлять модули как web-сервисы. Это делает модули гораздо более гибкими. Плюсы модулей как веб-сервисов:

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

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

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

Парадигмы

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

Рассмотрим поддержку функционального программирования. Как известно, сердце функциональной парадигмы – это лямбда-исчисления. Думаю, что как ядро языка – отлично подойдут чистые нетипизированные лямбда-исчисления. Уже с помощью модулей можно дополнять λ-исчисления до system F, λ-исчислений с зависимыми типами или других исчислений. То есть достраивать ядро до нужной мощности и уже на имеющейся основе строить язык. Также фишка такого подхода в том, что, используя синтаксический сахар и монады, в язык можно добавить лаконичное императивное программирование. Но стоит быть аккуратным с чистыми функциями. Нужно учесть, что функция не будет чистой, если внутри себя она использует платформозависимые функции или вызывает внешние нечистые функции.

Но язык, ядром которого будут лямбда-исчисления, скорее всего, не будет иметь возможности быть оптимально скомпилирован под популярные архитектуры (x86-64, ARM, RISC-V). Для языков, которым важна производительность, размер программы, потребление памяти и т.п., предлагаю ввести иное ядро. Это ядро должно быть универсальным для любого императивного языка программирования, а также должно иметь возможность глубоких оптимизаций.

У ядра на лямбда-исчислениях есть еще некоторые проблемы: я не придумал, как устранить зависимости между модулями в такой реализации, поэтому, возможно, будет хорошо эмулировать работу исчислений на байткоде императивного языка. Будет написан еще один модуль, превращающий промежуточное представление лямбда-исчислений в байткод (не скупимся на количество IR’ов ради гибкости и удобства).

Байткод императивного языка

Итак, ядро императивного языка программирования, конечно, будет представлять собой байткод. Сначала я думал использовать какую-нибудь видоизмененную машину Тьюринга, но решил, что она слишком сильно оторвана от текущих процессоров и нет смысла даже пытаться адаптировать ее под современные системы. Самая сложная задача проектирования байткода – он должен подходить под любой императивный язык, но при этом иметь возможность оптимизировать выходной код настолько, насколько это возможно. Сразу же хочется добавить поддержку LLVM для статической компиляции, а также компиляцию в dotnet bytecode, java bytecode для поддержки JIT компиляции. Если тщательно формализовать байткод, то даже есть надежда написать супероптимизатор на middle-end уровне.

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

То есть кортеж из типа байткодовой инструкции и трех списков. Изначально байткод будет иметь только один тип инструкции: call. Массивы содержат только делегаты на функции (указатель + сигнатура + доп. информация). Байткод буквально представляет собой шитый код (threaded code) – массив вызовов функций (но не обязательно чистых). Массивы различаются лишь порядком применения операций. В массив [0] добавляются делегаты, которые должны быть исполнены перед делегатами массивов [1] и [2]. Грубо говоря получаем делегаты, которые обязательно должны быть исполнены перед или после исполнения других делегатов. Зачем это нужно, рассмотрим позже. Стоит отметить, что вместо таких массивов подошел бы также multiset<(float, delegate)> делегатов (отсортированный список по приоритету вызовов).

Существует несколько видов байткода: стековый, регистровый и в SSA форме. Для упрощения будем использовать стековый байткод, так как он легко переводится в регистровую и SSA форму. Да и сам по себе, гораздо более абстрактный. Регистровый байткод имеет привязку к количеству регистров, а байткод должен не зависеть от архитектурных особенностей. SSA форма – удобный вариант, но он более сложный. При разработке модулей он может сильно помешать, так как придется “жанглировать” передачами регистров, строить CFG.

Продолжение байткода

Представим ситуацию. Мы уже имеем минималистичный язык программирования: уже существуют локальные переменные, метки, вызовы внешних функций и другой примитивный функционал. Сейчас типизация динамическая, но хочется внедрить рантайм проверки типов, как в примере с JavaScript. Реализация примерно такая же: добавляем новое правило в лексер, обходим узлы AST с использованием переменной, внедряем assert как ноду перед использованием переменной. Но вдруг программист обнаруживает, что ему не хватает структур в языке. Обычных базовых структур, которые просто хранят значения, в которых нет даже методов (их можно добавить, но без методов проще). Итак, программист написал модуль с поддержкой подобного синтаксиса:

который превращается в подобный байткод:

Главная проблема в том, что ни на этапе AST, ни на этапе байткода инструкции LoadField и SetField не получается распознать, как использование переменной. Конечно, на уровне AST невозможно распознать такую конструкцию, так как создаются новые типы нод. А вот с байткодом есть возможность подружиться, если продумать типы инструкций. Можно сказать, что тип инструкции байткода – это ее тег. Первая мысль – делать строгие инструкции, например SetLocal, LoadGlobal, LoadMethodReference и другие. Но проблема таких типов в том, что они слишком конкретны.

Постараемся развить абстракции. Оставим только инструкции Set и Get, которые будут оперировать интерфейсами (точнее классами/структурами, имплементирующими их) ISettable и IGettable. Чтобы вызвать эти методы, нужны экземпляры классов. Для этого перед каждой установкой или чтением значения будем класть на стек ссылку-обертку на значение. Ссылка, в данном контексте, это не всегда указатель на ячейку памяти. Это абстрактный указатель на само значение. Класс, имплементирующий ISettable и IGettable. Ссылка может быть регистром, реальным указателем или быть ячейкой словаря (map’ы). Рассмотрим пример:

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

Инструкции байткода также могут возвращать значения. Первая мысль реализации: как и в обычных функциях, возвращаем значение через return. Но в байткоде встречаются такие инструкции, как swap. Они принимают два значения и возвращают два значения. Поэтому, для удобства, стоит возвращать значения через аргументы-ссылки, предназначенные только для записи (в C# – ключевое слово out). Например:

Возвращаясь к проблеме типизации и структур, теперь модуль типизации может вставлять проверки перед каждой инструкций типа Set/Get, а модуль структур будет генерировать код установки и получения значений именно через Set и Get. Тут нам и пригодятся три списка делегатов в инструкции. Проверка типов обязана исполнятся перед тем, как основная инструкция будет выполнена, поэтому проверку стоит поместить в нулевой список делегатов. Также плюсом будет то, что модули работают на уровне байткода, а не AST. Это позволит без боли менять фронтенд языка и не переписывать большинство модулей.

Теперь, понимая смысл трех списков, можем дать им названия: pre-ops, main-ops, post-ops – делегаты, исполняемые, соответственно, до, во время и после совершения основной операции.

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

Перфоманс байткода

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

Как видно, при достаточно глубоком инлайнинге (2-3 шага) можно сильно упростить код. Уже после инлайнинга, оптимизатор паттернов может сильно упростить некоторые под-коды. Например можно научить оптимизатор распознавать обращение к классу VariableWrapper

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

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

Обсуждаемый байткод легко перевести в байткод виртуальной машины dotnet или JVM. Также не сложно перевести в LLVM IR, чтобы уже этот фреймворк применял сильные оптимизации.

Рассматриваем узкие места

Дебаггинг

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

Зависимости между модулями

В худшем случае, количество зависимостей будет O(n^2), где n – количество модулей. Байткод специально был спроектирован так, чтобы зависимость между модулями была минимальной. Но даже с этим условием все еще стоит стараться делать модули абстрактными и подумать заранее о написании других модулях, которые смогут расширять его исходные возможности. Когда будет написан модуль с типизацией, нужно подумать, как улучшить имеющиеся абстракции для потенциальных будущих модулей с ее улучшением (вспомним лямбда-куб).

Общее API модулей

Также мне нравится идея с веб-сервисами тем, что модулям придется общаться через json’ы. Это сразу заставит продумать API создаваемого модуля. Мучаться с бинарной совместимостью не придется, так как обмен информацией достаточно высокоуровневый и многие проблемы решают такие протоколы как, например, http.

Заключение

Не думаю, что когда-нибудь будет создан один универсальный язык программирования, который подойдет для решения всех задач. Но, скорее всего, именно удобное окружение и продуманная архитектура поможет создавать языки как конструктор для нужных задач. Нельзя допустить роста множества DSL’ей, где один язык решает одну проблему, чтобы не пришлось каждый день учить новый инструмент, но база модулей помогла бы иметь гораздо более полезный эффект. Не хватает высокоуровневого программирования в системном языке? Подключите модуль с zero-cost абстракциями. Не хватает функционального программирования в ООП языке? Подключите модуль с синтаксическим сахаром, оператором |>, ленивыми вычислениями и unified calls.

Модель создана с нуля, обучена на реальных пулл-реквестах и задачах из практики. Она уже доступна в IDE.

Новая глава в «вайб-кодинге»

Модель grok-code-fast-1 от xAI позиционируется как конкурент решениям от OpenAI, Google и Anthropic. Она оптимизирована для разработки на TypeScript, Python, Java, Rust, C++ и Go, а значит покрывает большинство реальных кейсов в современной разработке.

Модель уже интегрирована в IDE и CLI вроде GitHub Copilot, Cursor, Cline, Roo Code, Kilo Code, OpenCode и Windsurf. В ближайшее (но ограниченное) время она будет доступна бесплатно.

Быстрая, дешевая и довольно-таки умная

xAI делает ставку на цену, скорость и удобство. Стоимость использования grok-code-fast-1:

• $0,20 за 1 млн входных токенов
• $1,50 за 1 млн выходных токенов
• $0,02 за 1 млн кэшированных входных токенов

Во внутреннем бенчмарке SWE-Bench-Verified, модель показала результат 70,8%, но независимых тестов пока нет — их ждут в ближайшие недели.

В xAI утверждают, что при создании модели основное внимание уделялось практическому использованию и удобству в реальных задачах. Якобы разработчики оценили grok-code-fast-1 как «быструю и надежную» при повседневной работе с кодом.

До 160 токенов в секунду и 90% кэш-хитов

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

Кроме того, реализовано кэширование подсказок, которое обеспечивает до 90% попаданий при работе с GitHub Copilot и другими интеграциями. Это позволяет существенно сократить задержки и стоимость использования.

Это позволяет вставлять работающий код Whitespace в пробелы любого другого кода — и таким образом делать полиглоты: один и тот же файл может одновременно быть, например, Python-скриптом и Whitespace-программой.

Как это работает

Whitespace — это стековый императивный язык. Он умеет:

• класть числа в стек,
• выполнять арифметику (сложение, вычитание, деление),
• обращаться к куче (heap),
• работать с вводом-выводом,
• прыгать по меткам и вызывать подпрограммы.

Каждая команда кодируется последовательностью из пробелов (S), табов (T) и переводов строки (L). Например, последовательность T S S (таб, пробел, пробел) складывает два числа из стека.

Числа кодируются в двоичном формате: S — это 0, T — 1, а знак задаётся первым символом: S — плюс, T — минус. Например, число 75 в Whitespace выглядит так:

Кто его придумал

Язык придумали Эдвин Брейди и Крис Моррис в 2002 году — те самые, кто позже создали языки Idris и Kaya. Презентовали Whitespace 1 апреля. И многие решили, что это шутка. Которая, по всей видимости, вышла из-под контроля.

Идея использовать только пробельные символы появилась ещё раньше: в 1997 году Бьёрн Страуструп, автор C++, предложил это также в шутку — как абсурдную эволюцию C++.

«Hello, world!» на Whitespace

Вот как выглядит программа, которая выводит Hello, world!:

В этой записи S — пробел, T — табуляция, L — перевод строки. Для людей такая программа полностью невидима: она выглядит как пустой файл, но её можно запустить через интерпретатор.

Зачем всё это

Whitespace — язык из категории эзотерических.

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

Кроме того, это отличный способ спрятать код в самом неожиданном месте.

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

Когда мы говорим об углеродном следе ПО, важно понимать: код не существует в вакууме. Каждая строка, каждый запрос и каждая операция требуют физических ресурсов — электричества, серверного оборудования, систем охлаждения. В 2025 году эта цепочка стала еще сложнее из-за взрывного роста облачных вычислений и ИИ.

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

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

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

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

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

Каждая лишняя операция в коде — это не только миллисекунды процессорного времени, но и реальные граммы CO₂. В 2025 году энергоэффективность кода перестала быть теоретической концепцией и превратилась в конкретный навык, который влияет на карьеру разработчика. Рассмотрим три ключевых направления оптимизации.

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

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

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

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

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

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

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

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

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

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

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

• множество библиотек и зависимостей;
• единый store, в котором живут состояние и данные;
• компоненты, которые нужно собрать, чтобы сделать из них приложение.

Собрать это все можно по-разному. Можно сложить в монолит, а можно попробовать модульный подход.

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

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

Масштабировать можно и монолиты, но у них всегда остается какая-то единая точка отказа — например, база данных. Особенно если это реляционная СУБД, завязанная на Oracle или PostgreSQL. Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.

Микросервисы — панацея? Не совсем

Тренд на микросервисный подход появился в начале 2010-х годов, вместе с проникновением интернета в широкие слои населения. Первый iPhone вышел в 2007 году, люди стали гораздо ближе к интернету, к данным, к информации. Бизнес захотел дотянуться до этой аудитории, и тогда началась диджитализация, сложность систем стала повышаться. Особенно остро это почувствовали крупные организации вроде банков: функциональность увеличивалась, и монолит начал «трещать» не только технически по инфраструктуре, но и по возможностям команд разработки, которые с ним работали.

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

Распространение DevOps-культуры и инструменты оркестрации

Раньше разработчик писал код, собирал артефакт и перекидывал его через забор в поддержку. Коллеги за забором его деплоили, запускали — и разработчику можно было больше не думать про плоды своей работы.

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

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

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

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

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

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

DDD: как правильно нарезать сервисы

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

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

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

DDD помогает выделить bounded context — согласованные по бизнесу участки. Они позволяют более или менее правильно нарезать большой бизнес-функционал на отдельные части.

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

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

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

Внедрение микросервисов: с чего начать?

С микросервисным подходом есть проблема — нет четкого ответа, куда идти и что делать, чтобы научиться его создавать. Это одна из главных сложностей микросервисной архитектуры, особенно когда только начинаешь с ней работать. Если хочется изучить Spring или Oracle, можно почитать официальную документацию. А к такой большой и необъятной теме, как микросервисы, даже и непонятно, с какой стороны подступиться. Туториала к ней нет, есть только куча статей, подходов и практик. Причем одни практики подойдут конкретной команде, а другие — нет.

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

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

Поддержка микросервисной архитектуры

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

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

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

Паттерны отказоустойчивости

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

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

Бывали случаи, когда из-за бага в мобильном приложении трафик внезапно удваивался, и системы не выдерживали такой нагрузки. Любая малейшая задержка в самом незначительном компоненте может привести к тому, что по цепочке пойдет отказ, — будут копиться потоки, соединения, и рано или поздно упадет вообще все. Чтобы подготовиться к таким ситуациям, важно изучить хотя бы четыре «золотых сигнала» мониторинга из SRE от Google.

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

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

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

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

Как эффективно работать с инцидентами

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

Первый уровень — это application-слой, сами сервисы, которые в подах крутятся в Kubernetes. Нужно проверить, все ли у них хорошо по точкам интеграции — нет ли тайм-аутов. Все ли в порядке у них по железу — по CPU, по памяти, по дискам.

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

Совет: если вы вдруг нашли что-то, что еще не мониторится, — это повод поскорее добавить эту метрику, начать ее мониторить и ретроспективно отслеживать.

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

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

Представим, что происходит инцидент — падают 15 микросервисов. Как должна быть устроена система, которая позволит оперативно справляться с авариями?

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

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

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

Однако эти организационные моменты еще не гарантируют быстрого решения проблемы. Ключевой фактор — культура компании. На людей часто нападает отстраненность — авария случилась, и все думают: «Кто-нибудь другой разрулит. Я разработчик, ну, что я там сделаю?»

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

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

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

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

Это то самое SRE, о котором пишет Google. Но людей нужно долго обучать такой культуре — это не дело одного месяца. Благодаря такому подходу инженеры, которые раньше были просто разработчиками или аналитиками, глубже осознают свою ответственность за стабильность продакшена. И это действительно правильное направление развития. Потому что и DevOps, и SRE — это в первую очередь культура, а уже во вторую — набор инструментов.

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

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

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

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

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

METEOR — мощный инструмент для автоматизации процессов, с триггерами, серверными функциями и ИИ-аналитикой. Он позволяет гибко настраивать сложные операции.

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

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

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

METEOR не просто помогает контролировать задачи — он становится частью операционного «ядра» команды, избавляя от хаоса, ускоряя работу и делая все немного спокойнее.

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

Помимо самого Gitlife, разработчики делают Gitlife AI, в котором есть доступ к топовым ИИ-моделям и инструментам, чтобы разрабатывать ИИ-решения.

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

Cerebro — профессиональная система для совместной работы и управления проектами. Она помогает ставить задачи, планировать этапы, следить за выполнением, обмениваться файлами и комментировать их прямо в системе. Особенно полезна для команд, которые делают VFX, 3D, анимацию или дизайн — но при этом легко адаптируется и под другие команды.

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

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

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

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

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

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

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

Ты уже программист, если читаешь это! Больше о кодинге тут.

Больше новостей — в нашем тг-канале «Представляешь»

Он отмечает, что многие советы кажутся логичными на бумаге, но в реальной работе теряют свою ценность.

Например, философия чистого кода, популяризированная дядей Бобом, действительно помогает писать понятный и поддерживаемый код, но её применение может быть сложным в старых, нагруженных легаси-системах. Многие из них были созданы задолго до появления современных принципов, и переписывать их просто ради красоты — не всегда оправданно.

Тренды не всегда важны

Ещё один миф — необходимость следовать последним технологическим трендам. Разработчик напоминает, что PHP, которому часто предрекают конец, всё ещё используется на большинстве сайтов, включая WordPress. А Java и C/C++ продолжают работать в критически важных системах и управляют миллиардами устройств:

«Новые технологии, такие как Rust или Next.js, действительно крутые, но это не значит, что работа с устаревшими системами делает вас менее ценным специалистом»

Производительность не главное

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

Например, банкоматы работают на старых финансовых системах, и никто не требует от них микросекундной реакции — главное, чтобы деньги выдавались исправно.

Масштабируемость — не всегда приоритет

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

ИИ не заменит программистов

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

Больше новостей — в нашем тг-канале «Представляешь»

Теперь студенты, авторы open-source проектов, создатели контента и хобби-разработчики смогут использовать CLion без оплаты, если их работа не приносит коммерческой выгоды.

Почему это важно

CLion — популярная среда разработки для C и C++, известных своей сложностью и строгими требованиями к качеству кода. По словам JetBrains, новое предложение поможет снизить барьер для изучения этих языков, которые остаются ключевыми для системного и встраиваемого программирования.

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

Условия использования

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

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

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

Сам Оскар за свою карьеру успел поработать с C#, Java, C++, Python, Ruby, JavaScript, Perl и прочими языками. Но не потому что стремился к полиглотству, а потому что так сложилось — проекты, клиенты, задачи.

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

Синтаксис — это не все

Проблема в том, что многие изучают новый язык на уровне «выучил синтаксис — значит, могу писать». Но это часто приводит к «Java-коду на Go» или «C#-архитектуре в TypeScript». Новички в языке переносят привычные паттерны, не понимая, как использовать сильные стороны новой платформы.

Чтобы писать идиоматично, нужно время. Неделя — чтобы освоить синтаксис. Пару месяцев — чтобы почувствовать экосистему. Год — чтобы писать как носитель языка.

Когда стоит добавлять новый язык в стек

Оскар выделяет три повода:

• Бизнес-задача. Например, для тяжелых расчетов стоит взять язык быстрее JavaScript.
• Кадровый вопрос. Иногда проще найти разработчиков под Node.js, чем под Java.
• Карьерный рост. Умение работать с востребованным стеком открывает больше возможностей.

Но главное — не делать выбор из любопытства. Однажды Оскару пришлось переписать модуль с F# на C#, потому что никто не хотел его поддерживать. В другом проекте Python-модуль оказался узким горлышком и потребовал переделки. Эти эксперименты дорого обошлись бизнесу.

Архитектору — особенно важно

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

Баланс между глубиной и гибкостью

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

Языки — это инструменты. Хороший разработчик остается таковым вне зависимости от того, на чем он пишет.

• Python vs C++: какой язык быстрее найдет все простые числа до миллиарда — сравниваем производительность Python и C++ на задаче поиска простых чисел и показываем код, графики и выводы. В качестве метода использовали решето Эратосфена. Если вы думаете, что ответ очевиден — вы заблуждаетесь.
• 10 бесплатных ресурсов по C++ для начинающих — подборка качественных и бесплатных ресурсов для изучения C++ — курсы, книги, сайты и видео. Среди рекомендаций — изучение STL, структур данных, многопоточности и написания эффективного кода с практикой чтения чужого.
• Электронные часы, мультимедийная библиотека SFML для разработки игр на C++ — это практический проект на C++ и SFML: создаем электронные часы с отрисовкой и анимацией. Внутри — базовые возможности SFML для разработки игр, например, работа с окнами и графикой и обработка событий.
• Исключения в C++: безопасность, спецификации, бенчмарки / Tproger — разбираем спецификации исключений, влияние на безопасность и производительность. Внутри — примеры и бенчмарки, которые показывают, как исключения могут замедлять код при неправильном использовании.
• Создаём программу для составления тестов на С++ — Создаем приложение для генерации тестов с вопросами и ответами, структура проекта и код на C++. Описываем работу с файлами (например, сохранение в TXT) и интерфейс командной строки — так можно легко освоить ввод-вывод и структурирование кода.
• Настройка многопоточной обработки сообщений в С++ — здесь рассказываем о пошаговой настройке многопоточной обработки данных в C++, используем библиотеку <thread>, мьютексы (std::mutex) и очереди (std::queue). Пример: клиент-серверное приложение с синхронизацией через std::condition_variable.
• Исключения в C++: типы, синтаксис и обработка / Tproger — рассказываем, что такое исключения в C++, как их использовать, какие типы бывают и как правильно обрабатывать.
• Интересные особенности указателя this — объясняем роль указателя this в C++: связь с текущим объектом, использование для разрешения конфликтов имен и возврата объекта (return *this). А еще внутри — про ограничения, например, недоступность this в статических методах.
• Как в С++ обрабатывать ошибки в конструкторах без исключений? — показываем альтернативные способы обработки ошибок в конструкторах C++ без исключений: возвращаемые коды ошибок, флаги состояния объекта или другие техники, чтобы обеспечить надежность и избежать накладных расходов.

Кстати, мы уже делали подобные гайды. Здесь можно почитать про Python, React и мобильную разработку.

А еще! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

ИИ уверенно занимает место в разработке

По словам Наделлы, доля ИИ-сгенерированного кода различается в зависимости от языка: наибольший прогресс достигнут в Python, меньше — в C++.

Тем не менее, Microsoft уже уверена в направлении развития: технический директор компании Кевин Скотт ожидает, что к 2030 году 95% всего кода будет генерироваться ИИ.

Не только Microsoft

Цифры Microsoft — не единственные на рынке.

На прошлой неделе Сундар Пичаи, CEO Google, сообщил, что более 30% кода в компании тоже создается ИИ. Но как именно измеряется эта доля — ни Microsoft, ни Google не раскрывают.

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

Пока все обсуждают новости, мы сделали то, что реально экономит часы: гайд по 70+ ИИ-инструментам

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

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

Основные особенности языка Julia

Язык программирования с романтическим женским именем был создан в 2012 году профессором Массачусетского технологического института Аланом Эдельманом в сотрудничестве с группой студентов. Инструмент изначально разрабатывался с прицелом на использование в научных вычислениях. По замыслу команды, язык должен был занять нишу, в которой находились MATLAB с его многочисленными клонами и R, а также совместить удобство и простоту Python с производительностью С++ и Fortran.

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

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

Рассмотрим более подробно главные плюсы Julia.

Скорость и производительность

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

Как это реализуется на практике? Представьте, что вам нужно перемножить две огромные матрицы или промоделировать климат в Московской области на 50 лет вперед. На Python это может занять часы, на C — требует тонн низкоуровневого кода. Julia справляется с такими задачами почти так же быстро, как C, но с лаконичностью Python.

Julia не интерпретирует код построчно, как Python, а сразу компилирует его в эффективный машинный код, как это делает C. Это дает ускорение в 10–100 раз в сравнении с чисто интерпретируемыми языками.

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

Вот несколько фактов, чтобы вы не сомневались в производительности Julia:

• NASA использует Julia для моделирования полетов — код работает в 15 раз быстрее, чем предыдущая версия на Python + Cython.
• В тестах линейной алгебры Julia обгоняет Python (NumPy) в 2–3 раза, а с нативными типами — почти догоняет C.
• Пакет DifferentialEquations.jl решает сложные уравнения в 100 раз быстрее SciPy (Python).

• Обучение нейросетей (Flux.jl) ускоряется в 3–5 раз против Python + TensorFlow/PyTorch.
• Анализ геномов в биоинформатике занимает минуты вместо часов.

При этом скорость Julia не наносит ущерба удобству применения.

Гибкость

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

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

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

Мощная экосистема пакетов

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

Обратите внимание на эти инструменты:

• Flux, MLJ и Knet — написанные на Julia пакеты для глубокого обучения. Позволяют создавать многослойные нейросети и модели непосредственно на этом языке.
• DataFrames.jl — набор фреймворков для работы с данными. Выполняет те же задачи, что и Pandas для Python. Включает полезные и высокоэффективные инструменты для управления данными и их анализа.
• JuliaImages — пакет библиотек для работы с изображениями. Включает инструменты для загрузки, обработки и трансформации картинок.
• Jump.jl — специализированный язык моделирования, интегрированный в Julia. Предназначен для математической оптимизации с использованием линейного, нелинейного и комбинированного программирования.

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

Поддержка многопоточности и параллельных вычислений

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

В отличие от Python, где многопоточность требует сложных библиотек, в Julia она встроена в сам язык. Чтобы запустить этот процесс, достаточно одной строки:

Что дает языку многопоточность «из коробки»:

• Ускорение в N раз (где N — число ядер). Например, на 8-ядерном процессоре тяжелый цикл выполнится почти в 8 раз быстрее.
• Никаких заморочек с разделением памяти — Julia сама позаботится о корректности.

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

Благодаря параллелизму Джулия существенно опережает в скорости R/MATLAB. Даже в специализированных математических пакетах параллельные вычисления часто требуют сложной настройки. В Julia это 2–3 строки кода.

Развитое сообщество

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

Вот почему это важно:

• Быстрая помощь. На официальном форуме и в чатах вам ответят даже на базовые вопросы — без снисходительности, характерной для некоторых других языков.
• Готовые решения. В реестре пакетов уже есть 7 000+ библиотек для всего — от машинного обучения до астрофизики.
• Открытость. Создатели Julia сами участвуют в обсуждениях, а многие пакеты разрабатываются университетами (MIT, Stanford) и компаниями (NASA, IBM).

Пример: если вы застряли с дифференциальными уравнениями, просто спросите в чате — и с вероятностью 90% вам ответит либо автор пакета DifferentialEquations.jl, либо кто-то, кто уже решил такую же проблему.

Сообщество Julia — это редкий случай, когда «экспертность» не означает «закрытость». Здесь ценят и новичков, потому что каждый когда-то начинал с “Hello World”.

Почему Julia популярен в научных вычислениях

Представьте язык, который понимает ваши математические формулы буквально с полуслова. Julia родился именно таким — как универсальный инструмент для ученых, уставших выбирать между «понятно» и «быстро».

Вот что делает его особенным:

• пишете, почти как в тетради: 2x + 3y вместо 2*x + 3*y;
• получаете скорость как у Фортрана, без головной боли с компиляцией;
• матричные операции летают в разы быстрее, чем в Python;
• сложные дифференциальные уравнения решаются за пару секунд.

Секрет успеха — в продуманной начинке:

• встроенные суперспособности для математики;
• может растягивать вычисления на все ядра процессора;
• легко подключает библиотеки Python, R и даже C.

При этом Julia универсален: подходит биологам для анализа ДНК, физикам, моделирующим квантовые системы, архитекторам, вычисляющим прочностные параметры конструкций. Библиотека Flux.jl строит нейросети быстрее PyTorch, а DataFrames.jl обрабатывает гигабайты данных без тормозов.

Это не просто язык — это турбодвигатель для научных открытий. Хотите говорить с компьютером на языке математики? Julia станет вашим переводчиком.

Сравнение Julia с другими языками

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

Julia vs Python

Python по праву считается универсальным языком программирования — он прост в освоении, обладает огромным количеством библиотек и поддерживается многомиллионным сообществом разработчиков. Однако когда речь заходит о сложных численных расчетах и высокопроизводительных вычислениях, Julia предлагает ряд неоспоримых преимуществ.

Главное достоинство Julia — его фокусировка на научных задачах. Этот язык создавался специально для работы с большими объемами данных и сложными математическими операциями. Хотя комьюнити Julia пока меньше python-сообщества, оно состоит преимущественно из специалистов в области Data science, физики и математического моделирования.

При этом Julia не исключает использование Python. Напротив, благодаря встроенным инструментам взаимодействия — таким как PyCall, разработчики могут комбинировать сильные стороны обоих языков. Использовать Julia для ресурсоемких вычислений, а Python — для других компонентов системы. Такой симбиоз позволяет достичь максимальной эффективности в научных проектах.

При этом Julia превосходит Python в скорости, имеет более удобный для математиков синтаксис. Параллелизм в Джулия встроенный — для Питона придется использовать сторонние библиотеки.

Julia vs R

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

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

Что действительно выделяет Julia:

• Это не просто язык для статистики, а полноценная платформа для научных вычислений.
• Можно работать с искусственным интеллектом, физическими моделями и даже квантовыми вычислениями.
• При этом сохраняется доступ ко всем привычным R-библиотекам.

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

Julia vs MATLAB

MATLAB долгие годы был как дорогой швейцарский нож для ученых и инженеров — удобный, но привязанный к лицензии. А теперь представьте, что появился инструмент с теми же возможностями, но бесплатный и который можно модифицировать под свои нужды. Это Julia.

Скорость работы — первое, что замечают при переходе. Типичные расчеты в Julia идут на пятую-треть быстрее. А когда дело доходит до сложных проектов, разница становится еще заметнее.

Но главная магия — в экосистеме:

• 7000+ бесплатных пакетов вместо платных тулбоксов;
• возможность заглянуть «под капот» любого алгоритма;
• сообщество, которое постоянно добавляет что-то новое.

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

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

Julia vs C++

Если снова воспользоваться сравнением из автомобильной тематики, то C++ — это ручная коробка передач в мире программирования. Можно выжать максимум скорости, но каждая строчка кода требует ювелирной работы с памятью и указателями. Julia предлагает другой подход — это автоматическая трансмиссия, которая разгоняется почти так же быстро, но без головной боли.

Секрет Julia — умный переводчик (JIT-компилятор), который:

• в реальном времени превращает ваш код в машинные инструкции;
• сам решает, как оптимально использовать память;
• не заставляет вас ковыряться в низкоуровневых деталях.

Разница особенно заметна в математических задачах. В Джулии не нужно приписывать все детали реализации в отличие от C++.

Примеры кода на Julia

Эти примеры демонстрируют все преимущества Julia в сфере математических вычислений.

Вычисление факториала

Это действительно просто:

Для больших чисел (n > 20) стоит использовать factorial(big(n)), что автоматически переключает вычисления на длинную арифметику.

Матричные операции

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

Базовые операции с матрицами:

Решение системы линейных уравнений:

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

Где применяется Julia

Сферы использования Julia в науке, бизнесе, ИТ и других отраслях практически не ограничены. Рассмотрим наиболее актуальные направления.

Научные исследования

Julia активно используется в фундаментальных и прикладных науках благодаря своей скорости и удобству для математических расчетов:

• В физике с его помощью моделируют квантовые системы (например, в пакете QuantumOptics.jl) и решают дифференциальные уравнения (DifferentialEquations.jl).
• В биоинформатике Julia применяют для анализа ДНК и белковых структур.
• В астрономии — для обработки данных телескопов и симуляции галактик. Например, NASA использует Julia для расчета траекторий космических аппаратов.

Финансовые вычисления

В финансах Julia ценят за высокую производительность при работе с большими массивами данных. Банки и брокеры применяют его для:

• Алгоритмического трейдинга — быстрого тестирования стратегий.
• Риск-анализа — моделирования кризисных сценариев.
• Оптимизации портфелей — решения задач линейной алгебры с миллионами переменных.

Пакеты вроде JuliaQuant и Temporal.jl делают его отличной альтернативой Python (Pandas) и R.

Искусственный интеллект и машинное обучение

Хотя Python все еще доминирует в ML, Julia набирает популярность в этой сфере благодаря:

• скорости — обучение моделей в Flux.jl (аналог PyTorch) иногда в 2–3 раза быстрее;
• гибкости — можно легко комбинировать нейросети с численными методами.

Например, Julia используют для обработки изображений в реальном времени. Пакет MLJ объединяет сотни алгоритмов в едином интерфейсе.

Анализ данных и обработка больших массивов информации

Julia идеален для работы с Big Data:

• DataFrames.jl предоставляет инструменты, знакомые пользователям Pandas/R, но работает быстрее.
• Поддержка многопоточности и распределенных вычислений (через интерфейс DistributedArrays.jl) позволяет обрабатывать терабайты данных.

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

Итоги

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

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

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

А вот несколько статей про C++:

• Модель памяти в языках программирования
• Электронные часы, мультимедийная библиотека SFML для разработки игр на C++
  
• Инструкция к погружению в С++ и более 10 бесплатных ресурсов для начинающих
  

В рейтинге языков программирования TIOBE Rust занимает 14 место. Для сравнения — в прошлом марте он был на 17 позиции. Вместе с экспертами Solvery Василием Кузенковым, full-stack разработчиком в Web3 стартапе, и Дмитрием Беляевым, Rust developer в Wildberries, разбираемся, как стать разрабом на Расте в 2025 году.

Немного об особенностях

Если вы до этого программировали на ООП языках, то вам, возможно, бросалось в глаза отсутствие привычных классов. Вместо них здесь алгебраические типы данных и трейты для решения expression problem. Их механизм куда больше похож на typeclasses из Haskell, что также будет для вас новой концепцией при построении крупных приложений, и нужно будет перестраивать мышление.

Также когда стартуешь, немного непривычно работать с move-семантикой, RAII, borrow checker’ом и лайф-таймами. Но компилятор сыпет довольно подробными ошибками, которые можно легко поправить, если разобраться.

А еще у Rust очень строгая типизация и очень мощная система типов, а сами типы построены так, чтобы предоставлять некоторые гарантии программисту. Например, ссылки в Rust всегда ссылаются на объект, гарантировано существующий в памяти, а стандартные строки содержат только валидный UTF-8. При этом в подавляющем большинстве случаев тип необязательно указывать явно, компилятор способен выводить типы, анализируя контекст функции целиком. Кроме того, Rust следует идеологии «компилируется, значит, работает». От логических ошибок, конечно, Раст не спасёт, но тем не менее очень большой пласт багов можно отловить на этапе кодинга. Да, это сложно, но лучше помучиться при разработке, чем потом разбираться почему упал прод.

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

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

Сложно ли переходить на Rust

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

На рынке фактически все вакансии требуют уже какого-то опыта в разработке. И сложность перехода сильно разнится от вашего текущего стека. Для Go-программиста переход будет средне-сложным, а язык, возможно, покажется перегруженным. Для С++ — менее сложным, но язык покажется местами ограничивающим. Я переходил на него с JS/TS’а и столкнулся со множеством низкоуровневых концепций, о которых раньше мог не задумываться. Но если у вас есть опыт в системном программировании — переходить будет в разы проще.

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

В моей практике менторства много успешных кейсов перехода на Rust с самых разных языков, но проще всего он даётся тем, кто раньше писал на современном C++ и уже понимает такие концепции, как move-семантика и RAII. Много привычного здесь обнаружат и те, кто писал на функциональных языках (Haskell или OCaml). Но в целом, для остальных тоже нет никаких проблем, даже если вы совсем новичок.

С чего начать изучать Rust

Вместе со стартом в изучении языка с The Rust Book — бесплатной официальной книгой по Rust’у — стоит углубить свои знания в более низкоуровневых вещах: в чем разница стека и кучи, что такое разметка памяти и адресация в памяти, как работает процессор, подходы и проблемы многопоточного программирования, плюс почитать про операционные системы и сети. Если вы решили осознанно применять Rust, оно вам пригодится.

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

Вот примерный список того, что нужно учить на старте:

• Переменные. Они по умолчанию неизменяемые (let x). Чтобы x стал изменяемым, нужно указать это явно через let mut. Константы (const) и статические переменные (static) вам будут нужны редко, они имеют свои особенности.
• Типы. Стоит разобраться с составными типами, такими как массивы и кортежи, а также с пользовательскими объявляемыми конструкциями struct (тип-произведение) и enum (тип-сумма). Также типы данных в Расте есть стандартные: bool, i32, u64 и прочие числовые, но строки могут удивить, так как их видов сильно больше.
• Match. Нужно понять такую вещь, как pattern-matching, познакомиться с оператором match, а также осознать, что pattern-matching применяется не только в нём, а везде, где возможно объявление переменных.

Таким образом, вы можете сразу проверить что-то и присвоить результат в переменную:

Здесь мы сразу проверили и присвоили:

Тут нам потребовалась дополнительная изменяемая переменная.

Что такое Cargo

Cargo — это консольная утилита, которая устанавливается вместе с компилятором языка. Она служит одновременно для управления зависимостями, сборки проекта и запуска тестов. Плюс для Cargo есть расширения, например, в поставке по умолчанию уже есть форматтер и линтер clippy.

Cargo рассчитан на то, что вы будете запускать его через терминал, самые полезные команды это:

• cargo new — создаёт новый шаблонный проект в указанной папке;
• cargo build — собирает проект;
• cargo run — собирает проект и запускает получившийся исполняемый файл;
• cargo check — dry-run сборки, делает все проверки компилятора, но ничего не собирает, что заметно быстрее полноценной сборки;
• cargo test — собирает проект со всеми тестами и запускает их;
• cargo fmt — форматирует проект в общепринятый стиль кода;
• cargo clippy — запускает линтер, очень полезно, можно подсказать более оптимальные варианты кода, найти некоторые потенциальные логические ошибки;
• cargo install — устанавливает пакет, содержащий исполняемые файлы;
• cargo clean — очищает все артефакты сборки.

Cargo позволяет описать структуру, настройки (профили сборки, описание крейта) и зависимости вашего крейта или даже монорепозитория (с помощью workspace). Кроме непосредственного запуска через терминал, многие вещи могут запускаться через средства интеграции в IDE, такие как rust-analyzer для VSCode.

Как работать с ownership, borrowing и lifetimes?

Для многих новичков системы владения (ownership), заимствования (borrowing) и времен жизни (lifetimes) выливаются в борьбу с компилятором раста. Эти механизмы нужны в первую очередь для безопасности памяти без сборщика мусора. Общее правило владения такое:

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

Когда значение перемещается (передается другой переменной или функции), владение переходит, и исходная переменная становится недействительной.

Для типов, реализующих трейт Copy (например, целые числа, булевы значения), значения копируются автоматически:

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

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

Заимствование позволяет использовать значение без получения владения через ссылки (& и &mut). Для мутабельных ссылок `&mut` есть дополнительные ограничения: в каждый момент времени может существовать только одна изменяемая ссылка на значение.

Нельзя иметь изменяемую ссылку, если уже есть неизменяемая ссылка на то же значение.

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

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

Общие советы по заимствованию здесь такие:

• Используйте ссылки, когда не нужно владение.
• Возвращайте значения из функций для передачи владения обратно.
• Используйте клонирование для создания новых экземпляров (с пониманием стоимости).
• Используйте типы с трейтом Copy, когда это возможно.
• Еще полезно не забывать о контейнерах. Rc<T> позволяет иметь несколько владельцев одного значения через счетчик ссылок, а RefCell<T> обеспечивает проверку правил заимствования в рантайме.

О структурах, перечислениях, модулях и функциях, замыканиях, итераторах

Структуры (structs) в Rust позволяют создавать пользовательские типы данных, объединяющие связанные значения и выступающие типом произведения.

Перечисления (enum) позволяют определить тип, перечисляя все возможные варианты значений.

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

Тип Shape представляет объединение (сумму) всех возможных вариантов. И к этому есть мощное сопоставление с образцом для работы с ADT:

Модули позволяют организовать код и контролировать видимость элементов. Определяются они через синтаксис mod <name> {} и могут быть вложенны друг в друга:

Также модули могут быть организованы в различных файлах (имя файла в таком случае будет именем модуля):

Импорт модуля осуществляется через ключевое слово use:

Функции в Rust определяются через ключевое слово fn:

Можно делать функции высшего порядка и передавать в них, как обычные, так и анонимные функции:

Еще одним элементом функционального программирования в Rust выступает итератор:

Здесь мы создаем собственный итератор Counter, реализуя стандартный трейт Iterator. Он используется для многих встроенных коллекций, таких как Vec или HashMap. Этот трейт особенно удобен из-за различных функциональных комбинаторов из стандартной библиотеки:

Трейт Iterator предоставляет множество методов адаптеров, таких как enumerate, filter или map, которые возвращают новый итератор. Методы адаптеров ленивые, они не запускают итерацию. Также есть методы исполнители, которые итерируют пока не закончатся значения, например, collect, fold или count.

Большинство коллекций (и ссылки на них) реализуют трейт IntoIterator (способность кастоваться в Iterator). Также IntoIterator автоматически реализуется для любого Iterator (ничего не стоящий каст сам в себя). Цикл for в Rust работает только с объектами, реализующими IntoIterator.

Как обрабатывать ошибки в Rust

В Rust принято разделять ошибки на 2 вида: паники и результаты операций:

• Паники используются для непредвиденных ситуаций и ошибок программиста, например, деление целочисленного типа на 0 или выход за границу массива. И хотя паники можно отловить, стандартное и рекомендуемое поведение при них — программа упадёт, будет напечатан стектрейс.
• Результаты операций выражаются типом Result<T, E>, который является перечислением из двух вариантов — Ok(T) и Err(E). Такой подход гарантирует, что все ошибки строго типизированы, а без обработки ошибки невозможно извлечь результат операции.

Option<T> используется для представления значения, которое может отсутствовать:

Result<T, E> используется для операций, которые могут завершиться ошибкой:

Для удобства проброса ошибок наверх существует оператор ?, который пишется после любого выражения, возвращающего Result, и возвращает Ok вариант. В случае Err варианта будет выход из функции с возвращением ошибки.

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

Про асинхронное программирование

Асинхронное программирование в Rust строится вокруг трейта Future— его реализуют для типов, представляющих значение, которое будет доступно в будущем.

Также в Rust есть синтаксис async/await. Ключевым словом async могут быть отмечены функции и блоки кода — они будут возвращать анонимный тип, реализующий Future. Async-блоки также могут захватывать окружение подобно замыканиям. Внутри async-блоков и функций возможно использовать ключевое слово await на любом выражении, возвращающем Future или IntoFuture (способность кастоваться к Future). В отличие от других языков с подобным синтаксисом, await записывается через точку после выражения, что очень удобно для построения цепочек вычислений.

Для исполнения асинхронного кода необходим рантайм, но стандартная библиотека такого рантайма не предоставляет, поэтому приходится использовать сторонние библиотеки. Самым популярным рантаймом является библиотека tokio.

В асинхронное программирование на Rust я рекомендую приходить уже после углубленного изучения языка, первых пет-проектов и небольшой работы с многопоточным кодом. Хотя синтаксис и общие правила работы с асинхронным кодом покажутся знакомыми тем, кто знает JS или C#, из-за более низкоуровневой природы языка работать с ним немного сложнее.

Что еще должен знать новичок в Rust

Вот примерный список:

• Очень желательно погрузиться в устройство памяти процесса, узнать, что помимо стека и кучи существуют и другие области (например, исполняемый машинный код так же отражён на память, а static-переменные хранятся не в стеке и не в куче, а в своей собственной области). Неплохо было бы и разобраться с тем, что у типов помимо размера есть выравнивание. Что в Rust бывают ZST (zero size type) — типы, размер которых честный 0, и DST (dynamic size type) — типы, размер которых неизвестен во время компиляции.
• Обязательно разобраться, как Rust освобождает память, не используя сборщик мусора. Почитать, что такое RAII. Понять, как работает трейт Drop.
• Избавится от стереотипов о Rust. Rust — не самый сложный язык, как только вы поймёте, как он работает. Плюс платят за Rust, как правило, больше, чем на аналогичных позициях на других языках.
• Оставить свои привычки из других языков (за исключением разве что Haskell/OCaml). Здесь не получится писать, как на C++/Java/Go и т.д. Привыкайте к хорошему и станете лучше, чем были до освоения Rust.

Что изучать, если есть вся база: чек-лист

• Макросы и метапрограммирование
• Unsafe Rust для низкоуровневого контроля
• Интеграция с C/C++ через FFI
• Разработка встраиваемых систем
• WebAssembly
• rustnomicon
• Undefined Behavior
• unsafe-код

Тренды на 2025 год

На Rust’е пишут все. Более полный список можно посмотреть тут: https://github.com/rust-unofficial/awesome-rust

Вот несколько топовых фреймворков и библиотек:

• serde — фреймворк для сериализации/десериализации
• tokio, futures — для асинхронного программирования
• clap — парсер аргументов командной строки
• anyhow, thiserror — удобная работа с ошибками
• chrono — работа с датой и временем
• dashmap — многопоточная hashmap
• bytes — эффективная работа с сырыми байтами
• log, tracing — для логирования
• reqwest — для http запросов
• axum — для http сервера и REST api
• mockall, test-case — упростит написание тестов
• bevy — игры
• clippy — линтер

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

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

Чем реже язык — тем выше шансы обойти защиту

Классика вроде C и C++ всё ещё в ходу, но всё чаще встречаются варианты: Python, Go, Delphi, Rust. Например, группировка APT29 использовала Python, Go и даже смесь из Delphi и C#. Hive и Akira перешли на Rust, а BlackByte — на Go.

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

Не только язык, но и компилятор играет роль

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

Инструменты вроде Delphi или Tiny C создают такой код, который антивирусы практически не узнают. Причина простая — слишком мало обучающих примеров, чтобы построить надёжные сигнатуры.

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

Вредоносы становятся всё разнообразнее

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

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

Дисклеймер! Перед прочтением настоятельно рекомендую ознакомиться с первой частью статьи.

Если вы знакомы с FreeBSD, вы уже знаете её достоинства и недостатки по сравнению с Linux. Просуммирую некоторые отличия, важные для выбора облачной ВМ.

• FreeBSD не поддерживает контейнеры в привычном понимании — ни docker, ни podman пока не портированы.
• FreeBSD использует свою собственную лицензию The FreeBSD Copyright, позволяющую не раскрывать derivative work. Оценить распространённость FreeBSD иногда затруднительно, возможно, часть её кода используется и в Windows(C), и в MacOS(C). Только иногда разработчики сами признают её использование, например, Евгений Гаврилов, руководитель проекта vStack.
• Метод разработки FreeBSD ближе к академическому стилю. Есть базовый набор пакетов base, включающий не только ядро, но и достаточно инструментов для сборки остальной системы, именуемой ports. Развитие системы управляется elected Core Team — сейчас в команде 9 человек.
• Во FreeBSD давно используется система snapshots/rollback, позволяющая откатить изменения, если что-то сломалось.

Существует дистрибутив Linux, у которого есть некоторые из перечисленных особенностей — это Fedora Core.

Что такое Fedora Core и как с ней работать

Изначально эти идеи возникли в другом дистрибутиве — RedHat CoreOS.

Во-первых, система ориентирована на использование в облаках: в ней предоставляются образы для всех возможных систем виртуализации и форматов дисков. Во-вторых, она разделена на базовую систему, часть из которой монтируется только в режиме чтения (ro:read only), и остальное, доступное через контейнеры.

Обновление системы возможно автоматически, появилась особая утилита rpm-ostree, и можно откатить на предыдущую версию, если что-то не так. Таким образом, CoreOS становится иммутабельной, изменения базовой части системы невозможны в обход коммитов rpm-ostree.

Я как-то провел эксперимент: установил в Yandex Cloud версию FedoraCore 35, выпущенную в конце 2021 года, с включённым по умолчанию сервисом zincati, который автоматически обновляет базовую систему (у него стабильные релизы). Посчитал, сколько коммитов сделано с тех пор: да, как и в git, здесь используется CAS (content-addressable storage), уже привычные нам хэши. ВМ обновилась и рестартанула 8 раз, если я не пропустил какой-либо рестарт:

Теперь можно сравнить с этой же системой, установленной из свежего имиджа — как и ожидалось, системы не отличались, хэши коммитов одинаковы. Это то, что имеется ввиду под иммутабельностью ОС. Кроме иммутабельности и смонтированных только по чтению некоторых каталогов, есть и другие меры безопасности. Используется версия Security-Enhanced Linux, никаких логинов по умолчанию, настройки пользователя либо через утилиту cloud-init, либо специальная утилита butane и так называемый ignition file.

У проекта Fedora есть подробнейшая документация — в ней лежит самое авторитетное руководство по установке. Тем не менее у меня возникла пара вопросов:

• Во-первых, для преобразования .yaml файла в ignition, который по сути обычный .json файл, используется особый инструмент butane, написанный на языке Go. Судя по размеру образа 130M, он довольно увесистый, но никак не упоминаются другие утилиты для конвертациии .yaml в .json.
• Во-вторых, в простейшем случае для первого логина вообще не нужны ни butane, ни .yaml. Вот пример минимального ignition.json файла, который создаётся руками:

Скопируем этот файл в каталог /tmp, он нужен один раз для первого входа, не содержит секретов, к нему нужно будет указать полный путь. Как и ранее, скачиваем свежий образ для libvirt/qemu: выбираем нужную архитектуру и формат диска, проверяем контрольные суммы и цифровые подписи. Команды для создания ВМ будут немного отличаться от уже опробованных из прошлой статьи — сначала сделаем для нашего ignition.json опцию, которую понимает virt-install:

Затем распаковываем образ в стандартный каталог и создаём ВМ:

Созданная заранее переменная шелл использована как "${IGN[@]}". virt-install выдаст интереснейший лог процесса инсталяции, а в самом конце — перед приглашением — покажет IP-адрес вновь созданной ВМ. Переходим в другую консоль и проверяем наш ssh-ключ: ssh -v core@192.168.100.2 в моём случае. После успешного логина выполняем первоочерёдные проверки и настройки:

Теперь ВМ можно остановить и сделать финальные настройки нашего персонального облака для этой ВМ. Добавим MAC- и статический IP-адреса в dnsmasq.conf и зададим имя новой ВМ в сети (пример есть в прошлой статье). Откроем в virt-manager окно overview, затем откроем вкладку XML и в самом конце удалим конфиг для qemu — целиком вот этот фрагмент:

Далее кнопка Apply. Возможно, virt-manager попросит сначала установить Edit → Preferences → General → Enable XML editing. То же самое можно сделать из командной строки: sudo virsh edit fc41stab. Ignition-файл нужен только для установки, далее эту ВМ можно донастраивать, клонировать, копировать её образ куда угодно, в том числе в большие облака.

А мы продолжим знакомство с этой необычной системой, как её рекламирует проект Федора:

Fedora CoreOS — это автоматически обновляемая, минимальная, монолитная, ориентированная на контейнеры операционная система, разработанная для кластеров, работоспособная автономно, оптимизированная для Kubernetes.

Проверим, что dnsmasq обновился, и начнём по порядку.

Далее выполняем команды внутри ВМ. Основное, к чему придётся привыкнуть, — что часть каталогов смонтированы readonly, запись в них в обход утилиты rpm-ostree невозможна даже судоерам:

Я специально грепнул только реальные устройства, потому что кроме них смонтированы ещё 19 виртуальных — пока углубляться не будем. Как видно, в режиме rw смонтированы /etc и /var. Даже стандартый home — это линк /home → var/home.

За автоматические обновления отвечает сервис zincati. Если его отключить, обновления можно запускать вручную: rpm-ostree --bypass-driver upgrade. После рестарта проверяем новое состояние системы:

rpm-ostree rollback позволяет откатить обновления к предыдущему комиту. Другие полезные команды:

1. rpm-ostree db diff — список обновлённых пакетов между комитами
2. rpm-ostree db list — список и версии пакетов в комитах

А как же устанавливать пакеты привычным dnf? Это своевременный вопрос. Посмотрим сначала что уже стоит:

Это напоминает FreeBSD base, но важно, что набор включает podman, docker, git — для остального есть утилита toolbox. Она делает доступными все пакеты федоры, упакованные в контейнер. Заглянем в toolbox:

Мы оказались внутри контейнера — об этом говорит изменившееся приглашение $PS1. Если снова посмотреть mount, увидим ещё больше хитро подмонтированных каталогов — этакий оверлей из базовой и контейнерной ФС. Но зато работает dnf, поэтому можно устанавливать любые пакеты. Добавим привычные, без них неуютно в новой системе:

Как видим, пакеты доступны, но желательно иметь их вне контейнера. Нет проблем: скопируем их в свой ~/bin каталог, он одинаков и внутри, и снаружи контейнера:

Выйдем из контейнера и проверим:

А теперь серьезно: настраиваем Fedora Core сервер для команды разрабов

Для начала настроим полноценный dev env: репозиторий кода, образы контейнеров, инструменты для сборки и сервер приложений.

Обычно в команде есть один админ или несколько. Уже созданный пользователь core — это админ, у него есть права sudo, плюс ему доступен контейнер tbox. В нашей Федоре каталог с секретами устроен особым образом:

Первоначально обычный файл authorized_keys назывался ignition и располагался в каталоге ~/.ssh/authorized_keys.d, что подразумевает, что можно ещё добавить ключей, назвав их никами других админов. Так же можно поступить с разрабами — настроить для всех один dev env.

Создадим нового пользователя без прав sudo:

Как мы уже знаем, мелкие утилиты можно просто скопировать из тулбокса в ~/bin или /usr/local/bin. Для языков программирования и прочих инструментов есть замечательная программа mise. Сейчас мы её установим для dev и немного познакомимся. Свой ключ я уже добавил в ~dev/.ssh/authorized_keys.d/, так что логинимся и настраиваем инструменты для команды разрабов.

mise позволяет устанавливать и использовать различные версии языков программирования, инструментов и библиотек. Другие менеджеры версий, например, aqua, asdf, ubi — собрали репозитории таких инструментов, и mise их использует в качестве бэкендов. Огласим весь список:

Да, список великоват: сохранил в файл — 883 штук, и он постоянно растёт. Это только названия пакетов, поиск версий, а команда mise ls-remote python выдала 911 вариантов для python.

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

Но как устроена эта мощная структура данных? Почему программисты так активно используют её в Python, Java и C++? И какие нюансы нужно учитывать при работе с хэш-таблицами, чтобы избежать коллизий и потерь производительности?

В этом материале разберем, как работает хеш-таблица, какие у неё преимущества и недостатки, и как её эффективно использовать в своих проектах.

Как работают хэш-таблицы?

Принцип хэширования: что такое хэш-функция и как она работает

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

Хэш-функция — алгоритм, который берет входные данные (например, строку) и преобразует их в числовое значение фиксированной длины. Это значение называется хэш.

Пример работы хэш-функции:

В этом коде мы берем сумму ASCII-кодов символов ключа, а затем берем остаток от деления на размер таблицы:

1. Ключ (например, строка “Python”) передается в хэш-функцию.
2. Функция вычисляет индекс (например, 6), куда будет помещено значение.
3. Если нужно найти значение по ключу, хэш-функция снова вычислит индекс и возвратит нужные данные.

Такой подход позволяет избежать перебора всех элементов, как это происходит в списках, и сразу обращаться к нужному индексу.

Структура: массив и связка ключ-значение

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

• Ключ — уникальный идентификатор элемента, который передается в хэш-функцию.

• Значение — информация, привязанная к ключу (например, число, строка или объект).

• Хэш-функция — преобразует ключ в индекс массива, по которому будет храниться значение.

Представим, что у нас есть хэш-таблица на 5 ячеек:

Если мы захотим получить имя "user15", хэш-функция найдет индекс 2, и поиск займет O(1).

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

Но если происходит коллизия (два ключа получают один индекс), приходится использовать дополнительные структуры, например, связные списки.

Основные операции с хэш-таблицами

Хэш-таблицы используют три основные операции:

• Вставка элемента (Insert). Добавление новой пары ключ-значение.

• Поиск элемента (Search). Быстрый доступ к значению по ключу.

• Удаление элемента (Delete). Удаление пары ключ-значение.

Рассмотрим, как работает каждая из них.

Вставка элемента (Insert)

Когда мы создаем новую запись в хэш-таблице, происходит следующее:

1. Хэш-функция вычисляет индекс для ключа;
2. Если ячейка свободна, значение записывается в массив;
3. Если ячейка занята (коллизия), используется стратегия разрешения коллизий.

В Python использовать хэш-таблицы просто: достаточно добавить элемент в dict:

Здесь “user42” — ключ, а “Алексей” — значение. Python автоматически рассчитывает индекс и записывает значение.

Поиск элемента (Search)

Поиск — одна из главных причин использовать хэш-таблицы. В отличие от списков, где поиск требует O(n), в хэш-таблицах он занимает O(1).

Как работает поиск:

1. Хэш-функция вычисляет индекс для ключа;
2. По индексу извлекается значение;
3. Если индекс занят другим ключом (из-за коллизии), выполняется проверка (например, в связанном списке).

Пример:

Использование get() позволяет избежать ошибки, если ключ отсутствует.

Удаление элемента (Delete)

При удалении элемента:

1. Находится индекс по хэш-функции;
2. Элемент удаляется, а ячейка либо помечается как пустая, либо применяется специальная стратегия (например, сдвиг элементов).

Пример:

Если ключа нет, del вызовет ошибку. Поэтому можно использовать pop():

Преимущества и недостатки хэш-таблиц

Хэш-таблицы — мощная структура данных, но у нее есть как сильные, так и слабые стороны.

Быстрые операции (в среднем O(1))

Главное преимущество хэш-таблиц — быстродействие. Вставка, поиск и удаление элементов происходят в среднем за O(1). Это означает, что независимо от количества элементов, доступ к данным остается мгновенным.

Например, если в обычном списке для поиска элемента придется перебрать все элементы (O(n)), то в хэш-таблице достаточно вычислить хэш и сразу найти нужное значение.

Простота использования

В Python использовать хэш-таблицы легко: стандартный dict уже реализует все основные операции:

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

Возможные коллизии

Несмотря на эффективность, у хэш-таблиц есть слабое место — коллизии.

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

Из-за плохой хэш-функции “cat” и “dog” получили одинаковый хэш, и одно значение затерло другое. Чтобы избежать коллизий, используют методы вроде цепочек (связных списков) или открытой адресации.

Необходимость в эффективной хэш-функции

Чем лучше хэш-функция, тем меньше вероятность коллизий.

Хорошая хэш-функция должна:

• Распределять данные равномерно по таблице;
• Быть быстрой в вычислениях;
• Минимизировать число одинаковых хэшей для разных ключей.

Затраты на память

Хэш-таблицы требуют больше памяти, чем массивы или списки.

Чтобы избежать коллизий и обеспечивать O(1)-доступ, хэш-таблицы используют больше места, чем реально хранят данных. Например, если таблица заполнена на 70-80%, скорость работы снижается, и приходится увеличивать размер массива (ресайзинг).

Примеры использования хэш-таблиц

Хэш-таблицы широко применяются в программировании благодаря их скорости и удобству. Рассмотрим несколько популярных сценариев их использования в реальных задачах.

Кеширование данных (Memoization)

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

Пример — ускоренное вычисление чисел Фибоначчи:

Подсчет частоты слов в тексте

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

Пример — частотный словарь:

В хеш таблицу сразу записываются все слова с их количеством — никакие циклы в массиве не нужны.

Уникальные элементы в списке

Хэш-таблицы можно использовать для удаления дубликатов в массиве.

Пример:

Проверка наличия элементов (поиск в больших массивах)

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

Пример — проверка наличия логина:

Хэш-таблицы в популярных языках программирования

Хэш-таблицы — неотъемлемая часть многих языков программирования, и реализация может отличаться в зависимости от выбранного инструмента. Рассмотрим, как таблицы устроены в Python, Java и C++, а также сравним особенности.

Python: dict

В Python стандартная хэш-таблица реализована через встроенный тип dict. Это одна из самых оптимизированных структур данных в языке, обеспечивающая O(1) доступ к элементам в среднем случае.

Пример использования:

Особенности dict в Python:

• Основан на открытой адресации для разрешения коллизий;
• Гарантирует порядок вставки (с версии Python 3.7+);
• Автоматически увеличивает размер при заполнении;
• Поддерживает defaultdict из collections для значений по умолчанию.

Java: HashMap

В Java для реализации хэш-таблицы чаще всего используют класс HashMap. Он не гарантирует порядок элементов, но обеспечивает быструю вставку и поиск.

Пример использования:

Особенности HashMap в Java:

• Использует цепочечное хэширование (chaining) для обработки коллизий;
• Не сохраняет порядок элементов (используйте LinkedHashMap, если порядок важен);
• Может хранить null в качестве ключа;
• В Java 8+ при большом числе коллизий список заменяется на дерево, что улучшает производительность.

C++: unordered_map

В C++ стандартная хэш-таблица представлена контейнером unordered_map, который входит в STL (Standard Template Library).

Пример использования:

Особенности unordered_map в C++:

• Использует цепочечное хэширование (chaining) для обработки коллизий;
• Не сохраняет порядок элементов;
• Позволяет определять собственные хэш-функции;
• В среднем обеспечивает O(1) на поиск, вставку и удаление.

Если сравнивать особенности реализации, то:

• Когда нужен порядок вставки → Python dict или Java LinkedHashMap.
• Когда важна скорость без дополнительных затрат → unordered_map в C++.

• Когда нужна безопасность при большом числе коллизий → Java HashMap (начиная с Java 8+ использует деревья для баланса).

Советы по использованию хэш-таблиц

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

Когда стоит использовать хэш-таблицы?

Использование хэш-таблиц оправдано в ситуациях, где важны:

• Быстрый поиск — доступ к элементу в O(1) (в среднем).
• Частая модификация — вставка и удаление быстрее, чем в массивах и сбалансированных деревьях.
• Ассоциативные отношения — когда данные хранятся в формате «ключ-значение».

Но когда НЕ стоит использовать хэш-таблицы:

• Если важен порядок элементов (лучше использовать TreeMap в Java или OrderedDict в Python).
• Если хеш-таблица будет сильно заполнена (может возникнуть деградация до O(n) при поиске).
• Если требуется эффективный диапазонный поиск (лучше использовать деревья, например, std::map в C++).

Как выбрать или написать свою хэш-функцию?

Хорошая хэш-функция должна обладать следующими свойствами:

• Равномерное распределение — минимизация коллизий;
• Быстродействие — должна вычисляться за O(1);
• Детерминированность — один и тот же ключ всегда дает один и тот же хэш.

Оптимальным вариантом здесь будет:

• Если используете таблицы в Python — стандартная хэш-функция hash() в сочетании с dict.
• В Java можно переопределить метод hashCode() в классах.
• В C++ можно задать свою std::hash<> или использовать криптографические методы (SHA-256, MD5).

Учет размера хэш-таблицы и предотвращение избыточного заполнения

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

Основные правила:

Коэффициент загрузки (Load Factor) — отношение заполненных ячеек к общему размеру таблицы.

• В Python dict увеличение происходит при заполнении на 2/3.
• В Java HashMap по умолчанию увеличение происходит при загрузке более 75%.
• В C++ unordered_map поведение зависит от конкретной реализации.

Также используйте простые числа для размеров таблицы — это снижает количество коллизий.

Если таблица работает медленно, проверьте коллизии:

• Возможно, стоит заменить хэш-функцию.
• Или использовать TreeMap (Java) или std::map (C++) при частых коллизиях.

Если следовать этим рекомендациям, хэш-таблицы станут мощным инструментом в вашем арсенале!

Однако на практике многие компании сталкиваются с лавинообразным ростом сложности, перегруженными бюджетами на инфраструктуру и постоянными сбоями в продакшене.

Эксперт с 25-летним опытом в IT разобрался, почему микросервисы часто становятся проблемой, когда они действительно оправданы и как можно избежать ненужных усложнений.

Почему микросервисы приводят к хаосу

Рост сложности

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

Отладка становится настоящим испытанием: теперь поиск одной ошибки требует глубокого погружения в распределённые логи и сложные инструменты мониторинга.

Высокие затраты на инфраструктуру

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

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

Пример: стартап из 12 человек использовал 87 микросервисов. В результате 60% бюджета уходило на AWS для поддержки этой сложной архитектуры.

Низкая предсказуемость работы

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

Когда микросервисы действительно оправданы

1. Глобальные сервисы – Netflix, Amazon, Google используют микросервисы из-за огромного количества пользователей и высоких требований к масштабируемости.
2. Разные технологии в одной системе – если одна часть системы требует Python, другая – C++, третья – Java, разделение на микросервисы может быть оправдано.
3. Сильная изоляция сервисов – если разные команды разрабатывают независимые части продукта, микросервисы помогают снизить конфликты в коде.

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

Как избавиться от избыточных микросервисов

1. Аудит архитектуры – если сервис не изменялся 6 месяцев, возможно, он не нужен.
2. Оценка альтернатив – вместо нового микросервиса можно реализовать модуль, библиотеку или просто улучшить код монолита.
3. Оптимизация инфраструктуры – сокращение количества сервисов снижает нагрузку на DevOps и упрощает отладку.

Вывод

Микросервисная архитектура не является универсальным решением.

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

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

Напоминание: простые числа — те, которые имеют два различных делителя. Простыми словами, они делятся только сами на себя и на единицу. Например: 2, 3, 5, 7 и так далее.

Для начала: быстро окунемся в математику

Есть несколько алгоритмов, которые помогут найти все простые числа до N. Это материал для отдельной статьи, поэтому пробежимся по основным.

Решето Эратосфена

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

1. Создается список чисел от 2 до N.
2. Все кратные числа кратные 2 (4, 6, 8, ...) помечаются как составные.
3. Переходим к 3 и вычеркиваем все числа, кратные ему.
4. То же самое повторяем со всеми числами из списка до N
5. Так до тех пор, пока не проверятся все числа до N.

Решето Сундарама

Этот алгоритм работает немного по другой логике:

1. Создается список чисел от 1 до (N-1)/2.
2. Исключаются числа типа i + j + 2ij, где i и j — натуральные числа, и i <= j.
3. Оставшиеся числа умножаются на 2 и увеличиваются на 1 — так получаем простые числа.

Этот алгоритм занимает меньше памяти, чем решето Эратосфена, поскольку работает только с половиной диапазона. Но при этом он сложнее в плане понимания и реализации.

Решето Аткина

Это уже современный алгоритм (появился в начале 21 веке). Он использует более сложные математические концепции и работает так:

1. Создается список чисел от 1 до N.
2. Используются квадратичные формы, чтобы предварительно отсеять составные числа.
3. Затем составные числа просеиваются финально для полного исключения.

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

Это три основных алгоритма для поиска простых чисел до N. Сейчас существуют различные оптимизации этих методов, например, колесная факторизация (оптимизированный алгоритм Эратосфена).

Ищем простые числа до миллиарда на Python и C++

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

PyCharm с ограничением 1 000 000 000 не завершает программу. Если же поставить лимит = 100 000 000, то получим такой результат (почти 8 секунд!):

Теперь попробуем проделать то же самое с библиотекой numpy, которая как раз подходит для работы с большими числами:

Результат будет таким:

Давайте попробуем сделать то же самое на С++:

Эта программа будет выполняться больше минуты:

Чтобы оптимизировать программу, можно использовать сегментированное решето Эратосфена:

Время выполнения уменьшилось на 20 секунд:

Итоги

В нашей задачке numpy действительно может оказаться быстрее, чем обычная реализация на C++. На то есть несколько причин:

1. Если в NumPy используется эффективный векторизованный алгоритм — в нашем случае решето Эратосфена, — преимущества SIMD-операций (одновременное выполнение одной операции над множеством данных) могут сильно ускорить вычисления.
2. Неоптимизированная реализация решета на C++ с обычными циклами может быть медленнее оптимизированной векторизованной реализации в NumPy.
3. NumPy использует внутренне оптимизированные C/C++ библиотеки, в которых есть куча оптимизаций для работы с массивами.

Но эффективно оптимизированный код на C++ (например, с использованием SIMD-инструкций, оптимизации кэш-памяти, параллелизма) почти всегда будет быстрее любой реализации на Python/numpy. Правда, такой код будет занимать сотни строк.

Производительность зависит от конкретных алгоритмов, поэтому так себе метод на C++ проиграет хорошему на numpy. Во многих задачах по работе с большими данными плюсы будут более быстрыми, но для типичного пользования numpy — отличная альтернатива.

Как ИИ меняет процесс разработки

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

По прогнозам МТС, к 2030 году более 90% программистов будут применять ИИ-инструменты для написания и проверки кода.

На данный момент:

• В среднем на рынке ИИ выполняет 5–10% рутинных задач.
• Нейросети заменяют функционал джуниор-разработчиков.
• Роль программистов постепенно трансформируется в архитектора решений.
• В 25% стартапов Y Combinator ИИ уже написал 95% кода.

Несмотря на такие темпы развития, пока код, сгенерированный ИИ, не идеален и требует проверки. Полного замещения разработчиков в ближайшее время не ожидается.

Какие решения внедряют компании

• МТС развивает DevX-платформу и Kodify, которые помогают ускорить разработку на 55%.
• Яндекс представил SourceCraft Code Assistant, который генерирует более 250 тыс строк кода в неделю для своих разработчиков. Поддерживаются 30+ языков, включая C++, Go, Kotlin, Python и другие.

Это стало возможным благодаря инструментам XenonRecomp и XenosRecomp, позволяющим преобразовывать PowerPC-код в x86-совместимый C++, а Xenos-шейдеры — в HLSL.

Проект получил название Unleashed Recompiled.

Почему Sonic Unleashed ждали на ПК

Но самое главное — эта технология теоретически позволяет портировать любую игру с Xbox 360 на ПК, даже если она не поддерживается в рамках обратной совместимости на современных консолях Xbox.

Sonic Unleashed давно считается «белым китом» для фанатов и моддеров. Основная причина — отсутствие официального порта на ПК.

До появления обратной совместимости на Xbox Series S/X единственным способом запустить уровни Unleashed в 60 FPS была модификация Unleashed Project для ПК-версии Sonic Generations, но она охватывала только дневные этапы.

С развитием эмуляторов Xenia (Xbox 360) и RPCS3 (PS3) стало возможно играть в оригинальную версию на ПК, но из-за оверхеда эмуляции производительность оставляла желать лучшего.

Что даёт Unleashed Recompiled

Теперь же, благодаря Unleashed Recompiled, проект впервые получил полноценный ПК-порт, который поддерживает:

• Неограниченное разрешение и гибкие настройки графики
• Моды и пользовательские патчи через HedgeModManager
• Функцию Music Attenuation, приглушающую внутриигровую музыку при воспроизведении внешнего аудио
• FPS выше 60 (хотя из-за багов физики рекомендуется использовать Lossless Scaling или Frame Generation от видеокарты)

Это инструмент для командной работы над кодом, в котором есть автоматизация CI/CD, умная навигация и встроенный ИИ-ассистент.

Пока что сервис работает в тестовом режиме — доступ можно получить по заявке.

Что умеет SourceCraft

SourceCraft предлагает знакомый интерфейс и удобную навигацию, напоминающую IDE. Разработчики могут искать код по ключевым словам, файлам и структуре проекта, что особенно полезно при работе с большими пул-реквестами.

Одним из главных элементов платформы стал ИИ-ассистент SourceCraft Code Assistant. Он поддерживает более 30 языков программирования (C++, Go, Java, Kotlin, Python и др), предлагает автодополнение кода и вскоре получит режим чата.

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

Мы создавали платформу с нуля и даже разрабатывали её последние версии внутри самой SourceCraft. Теперь мы готовы открыть тестирование для внешних пользователей и продолжим развивать платформу с учётом их обратной связи.

Будущее платформы

Сейчас SourceCraft доступен через веб-интерфейс, но в будущем появится глубокая интеграция с Yandex Cloud — развернуть проект в облаке можно будет «по нажатию кнопки».

Отдельный фокус сделан на безопасность. В ближайших обновлениях появятся:

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

Вместе с экспертами Kursfinder я проанализировала более 60 предложений. В итоге были отобраны 28 лучших курсов разработчика Unreal Engine. В статье они распределены по подборкам для удобства навигации. В начале я расскажу про 10 лучших учебных программ на мой взгляд. Затем вы найдете дополнительный список из 5 курсов, которые могут стать отличной альтернативой, если ни один из первых вам не подойдет. Далее представлены 5 программ, посвященных изучению Unreal Engine 5, а после них — 4 курса Unreal Engine 4. В завершение я собрала подборку бесплатных материалов. Полный список курсов Unreal Engine ищите в каталоге Kursfinder.

ТОП-10 лучших курсов по Unreal Engine в 2026 году

1. Разработка игр на Unreal Engine с нуля от Нетологии — лучший учебный курс от первых шагов в профессии до уровня разработчика игр.
2. Разработчик игр на Unreal Engine 5 с нуля от Skillbox.ru — программа с максимальным уклоном на практику.
3. Профессия Разработчик игр на Unreal Engine с нуля до Middle от Skillbox.ru — курс для освоения движка Unreal Engine и языка С++ и дальнейшего поиска работы..
4. Профессия Разработчик на Unreal Engine от GeekBrains — практический курс с живым общением на онлайн-занятиях.
5. Unreal Engine Game Developer. Basic от OTUS.ru — лучшее дистанционное обучение по созданию шутеров.
6. Unreal Engine Game Developer. Professional от OTUS.ru — программа для повышения уровня квалификации и подтверждения его документально.
7. Разработчик игр на Unreal Engine от XYZ School — онлайн-курс для развития навыков пользователя с нуля до уровня Junior Unreal Engine.
8. Геймплей-программирование от XYZ School — продвинутый курс для разработчиков игр с опытом.
9. Unreal engine 4 от Coddy School — программа для подростков 12–16 лет с индивидуальными и групповыми онлайн-занятиями.
10. Unreal Engine для новичков от Хохлова Сабатовского — лучший авторский курс для освоения Unreal Engine.

Особенность изучения Unreal Engine заключается в том, что потребуется знание языка программирования С++. Это несложно. Слушатели обычно осваивают его за пару занятий. Инструменты позволяют сделать игру под любую ОС и платформу (ПК, Андроид, iOS). Освоенные навыки пригодятся в любой сфере деятельности — от инженерии до индустрии развлечений. Другие названия профессии — режиссер и монтажер видеоконтента, мастер по анимации — как нельзя лучше определяют востребованность специалиста на рынке.

Онлайн-курсы по Unreal Engine

1. Разработка игр на Unreal Engine с нуля | Нетология

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

• Стоимость: 2 575 руб./мес.
• Длительность: 4,5 месяца
• Формат обучения: общеразвивающая теоретическая программа с уроками по расписанию, практические занятия, онлайн-вебинары (запись остается в личном кабинете), итоговый проект
• Сертификат: сертификат о прохождении программы

Кому подойдет: для начинающих

Преимущества:

• сложность итогового задания выбирается самостоятельно;
• можно получить работу через 3 месяца после начала учебы;
• бонусы — основы гейм-дизайна, софт скиллс, английский деловой язык, руководство по оформлению самозанятости.

Недостатки:

• обучение стартует с конкретной даты и заканчивается строго в установленный срок.

Программа обучения:

• основные алгоритмы;
• балансировка адвенчур с видом от третьего лица;
• объекты, наполнение, игровые элементы;
• игровые уровни, локации и миры в Unreal Engine.

Ознакомиться с полной программой >>>

2. Разработчик игр на Unreal Engine 5 с нуля | Skillbox.ru

Для этого курса характерно изучение новинок Unreal Engine 5. В частности, редактора для реалистичных человекообразных персонажей MetaHuman, 10 тысяч реальных объектов в пакете MegaScans, системы для автоматической отрисовки сложных моделей Nanite, инструмента для создания динамического освещения Lumen. Здесь писать код на С++ в нужном объеме для создания игр.

• Стоимость в месяц: 7 394 руб./мес.
• Длительность: 12 месяцев
• Формат обучения: видео, практика (65 заданий), общение с кураторами, еженедельные эфиры с геймдейв-экспертами
• Сертификат: сертификат установленного гос. образца

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

Преимущества:

• через 7 месяцев учебы можно смело брать коммерческие заказы;
• помощь с трудоустройством;
• создание 4-х разноплановых игр для портфолио;
• курс по нейросетям в подарок;
• доступ к личному кабинету и чату в Telegram навсегда.

Недостатки:

• отмечается сложная подача информации.

Программа обучения:

• процесс разработки игр;
• азы геймдизайна;
• код на С++;
• инструменты Unreal Engine 5;
• система визуального скриптинга Blueprints.

Ознакомиться с полной программой >>>

3. Профессия Разработчик игр на Unreal Engine с нуля до Middle | Skillbox.ru

Авторы курса разработчика Unreal Engine учат работать на движке, программировать на С++ и Blueprints, разным подходам к написанию кода. Всех ждет подробный разбор инструментов для постановки света, анимации, съемки и визуальных эффектов. Отдельное внимание будет уделено методу Kanban для грамотной организации рабочего процесса и работы в команде.

• Стоимость: 6 094 руб./мес.
• Длительность: до 8 месяцев
• Формат обучения: видеоуроки, вебинары, домашнее задание с поддержкой от кураторов, 4 итоговые игры
• Сертификат: сертификат установленного образца

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

Преимущества:

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

Недостатки:

• высокая полная цена.

Программа обучения:

• теоретическая часть с введением в разработку игр;
• работа с Unreal Engine + стажировка в практической лаборатории GameBox;
• как дорасти до уровня Middle-разработчика игр.

Ознакомиться с полной программой >>>

4. Профессия Разработчик на Unreal Engine | GeekBrains

Курс-практикум, состоящий из онлайн-занятий в мини-группах от 5 до 10 человек. В компании намного интереснее изучать разработку игровых проектов для ПК, Android и iOS, программировать на С++ и овладевать визуальным скриптингом на Blueprints. Здесь научат создавать собственные плагины, применять принципы ООП и паттернов для личного геймдева, работать с интеллектуальной надстройкой для улучшения структур и статического анализа. Для портфолио будут подготовлены аркада, 2D игра, парочка платформеров в стиле стелс и ретро. Командный проект со стажировки в профессиональной студии также можно приобщить списку собственных достижений.

• Стоимость: 3 386 руб./мес.
• Длительность: 12 месяцев
• Формат обучения: комбинирование живых уроков с теоретическими лекциями в записи, практика и геймджемы, домашние задания с проверкой в течение 24 часов
• Сертификат: официальный сертификат от школы на основании государственной лицензии об образовании

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

Преимущества:

• 4+ разноплановых проекта в портфолио;
• помогают с трудоустройством;
• стажировка в профессиональной студии по разработке игр;
• каждые 3 месяца проводится отбор для работы над реальными заказами.

Недостатки:

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

Программа обучения:

• введение в разработку игр;
• базовый уровень;
• продвинутый уровень;
• дополнительный курс по видеопродакшену.

Ознакомиться с полной программой >>>

5. Unreal Engine Game Developer. Basic | OTUS.ru

На этом онлайн-обучении Unreal Engine учат создавать динамичные шутеры. Для начала слушатели знакомятся с разработкой на Unreal Engine 5. Они научатся скрипте на Blueprints и программированию на С++, объединению анимации, визуальных эффектов, персонажей и других элементов в формат игры. Специальных навыков не требуется, но будет плюсом знание хотя бы одного языка программирования и принципов ООП.

• Стоимость: от 6 667 руб./мес.
• Длительность: 5 месяцев
• Формат обучения: только вебинары без предзаписанных занятий, живое общение с преподавателями в формате «вопрос-ответ», много практики, итоговый проект — шутер с видом от третьего лица
• Сертификат: именной сертификат о прохождении курса

Кому подойдет: желающим освоить разработку игр с нуля или сменить профессию на геймдев.

Преимущества:

• создание и пополнение портфолио;
• помощь с карьерой;
• размещение резюме в базе OTUS.

Недостатки:

• старт обучения закреплен за календарной датой;
• дедлайн из-за расписания онлайн-занятий.

Программа обучения:

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

Ознакомиться с полной программой >>>

6. Unreal Engine Game Developer. Professional | OTUS.ru

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

• Стоимость: 5 500 руб./мес.
• Длительность: 5 месяцев
• Формат обучения: онлайн-вебинары, записи которых сохраняются в свободном доступе, живое общение с преподавателями, домашние задания с проверкой, много практики, защита итогового проекта в виде онлайн-презентации
• Сертификат: сертификат установленного образца, свидетельство о повышении квалификации

Кому подойдет: новичкам в геймдеве. знакомым с основами программирования, начинающим гейм-мастерам.

Преимущества:

• помощь с трудоустройством + рекомендательное письмо;
• активное комьюнити в закрытом Telegram-чате;
• размещение резюме в базе OTUS;
• разработка для портфолио многопользовательской игры.

Недостатки:

• онлайн-занятия проводятся в среду и пятницу с 20:00 по МСК, а значит, придется планировать время, чтобы успеть подключиться к уроку.

Программа обучения:

• тестирование и выстраивание логики игры;
• разработка плагинов и модулей;
• задумка и развитие персонажа;
• дизайн уровней;
• мультиплеер.

Ознакомиться с полной программой >>>

7. Разработчик игр на Unreal Engine | XYZ School

Один из лучших курсов по разработке игровых интерфейсов, программирования на С++, реализации механики движения и стрельбы, настройки основных и неигровых персонажей. Можно записываться даже не имея никакой предварительной подготовки. 5 авторов-практиков учат с нуля и доводят до уровня Junior Unreal Engine-разработчика. В процессе обучения каждый слушатель придумает и сделает собственный инди-проект для портфолио.

• Стоимость: 5 800 руб./мес. в рассрочку;
• Длительность: 9 месяцев;
• Формат обучения: фидбэк от профессионалов (один урок + 1 домашнее задание), лекции, стримы, чек-листы и доп. материалы — в личном кабинете, итоговый проект
• Сертификат: сертификат об обучении

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

Преимущества:

• обучение в комфортном темпе;
• поддержка куратора;
• заморозка обучения, если не хватает времени.

Недостатки:

• высокая интенсивность подачи материала и много практики, которую не всегда успеваешь сделать.

Программа обучения:

• программирование на С++;
• реализация игровой механики;
• разработка интерфейса;
• создание движка для игр в формате 2D;
• дерево поведения и карта передвижений персонажей;
• код-ревью для устранения ошибок.

Ознакомиться с полной программой >>>

8. Геймплей-программи­рование | XYZ School

Этот курс придумали 2 практикующих автора — Александр Шумейко и Александр Баклашкин. Они предлагают программу на собственном опыте в области разработки игр на движке Unreal Engine. Для поступления потребуется знание хотя бы одного языка программирования и опыт геймдева.

• Стоимость: 5 327 руб./мес.
• Длительность: 5 месяцев
• Формат обучения: урок, домашние задания для закрепления материала раз в неделю, фидбэк от преподавателей, стримы, дипломный проект
• Сертификат: сертификат школы

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

Преимущества:

• учись, когда удобно, делай паузу в обучении, если нужно;
• личный куратор, поддержка и модерация;
• доступ в геймдев-сообщество № 1 на территории СНГ.

Недостатки:

• программу не освоить новичкам, не имеющим опыта.

Программа обучения:

• вводная часть, знакомство с интерфейсом;
• работа над созданием персонажа от внешнего вида до контроля за движением;
• наполнение арсенала + возможность прокачки оружия;
• использование ИИ для NPC в шутерах;
• геймплей, сохранение результатов, переход на следующие уровни.

Ознакомиться с полной программой >>>

9. Unreal engine 4 | Coddy School

Авторская группа, состоящая из преподавателей онлайн-школы, разработала специальный курс Unreal Engine 4 для детей от 12 до 16 лет. По мнению специалистов, именно в этом возрасте, а не раньше, лучше всего усваивается язык программирования С++. Но в данном случае кодирование не понадобится. Учитывая массовое увлечение подростков геймдевом, спикеры подробно и доступно расскажут о разработке игр без написания кода, помогут наработать практические навыки. На выходе у каждого ребенка будет собственноручно изготовленная игра.

• Стоимость: 6 800 руб.
• Длительность: 6 месяцев
• Формат обучения: индивидуальные и групповые занятия (до 8 человек) в онлайн/офлайн формате
• Сертификат: именной сертификат от школы

Кому подойдет: курс заявлен, как школьный, для детей 12–16 лет.

Преимущества:

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

Недостатки:

• есть системные требования к компьютеру;
• потребуется установка конкретных программ (школа предоставляет ссылки и инструкции).

Программа обучения:

• знакомство с интерфейсом Unreal Engine;
• принципы работы в 3D формате;
• освоение Material Editor;
• визуальное программирование в Blueprints;
• игровые персонажи, объекты, карты.

Ознакомиться с полной программой >>>

10. Unreal Engine для новичков | Хохлов Сабатовский

Авторский курс, охватывающий основные аспекты быстрого освоения Unreal Engine. Здесь закладываются первичные знания, дается необходимая база для дальнейшего развития в геймдеве. Дмитрий Шпатов разработал учебный план на основе собственного опыта. Когда-то он тоже начинал с разработчика игр, а сейчас выступает в качестве технического лида в Федеральном центре доп. образования России.

• Стоимость: 3 763 руб./мес.
• Длительность: 9 недель
• Формат обучения: урок + домашнее задание к нему, практические работы для сборки личного проекта в портфолио
• Сертификат: не предусмотрен

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

Преимущества:

• приобретение навыков;
• начало карьеры геймдева;
• проект в портфолио.

Недостатки:

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

Программа обучения:

• освоение Unreal Engine;
• создание виртуальных миров;
• анимация сцен;
• оптимизация проекта и вывод в формате видео.

Ознакомиться с полной программой >>>

Еще 5 курсов по Unreal Engine

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

• Курс Unreal Basics от Unrealskills — это вводный курс для освоения движка с нуля, разработанный Даниилом Лихомановым. Начать можно бесплатно, чтобы затем купить по специальной цене. В первой части дается доступ только к первому блоку, в котором предусмотрены знакомство с движком и созданию простенького проекта. В платной части эксперт научит манипулировать объектами, работать с редактором, создавать собственные PBR- и Parallax материалы, запекать свет в текстуры и другим фишкам. Явным плюсом является то, что автор не игнорирует пользователей и регулярно общается со всеми в закрытой группе VK.
• Курс Unreal Engine от Айтигенио (itgen.io) — программа направлена на формирование навыков для реализации самых креативных идей в геймдеве. Здесь научат свободно ориентироваться и пользоваться интерфейсом движка, создавать сцену со всеми визуальными эффектами и 2D-объектами, работать с ландшафтом, воплощать задумки по материалам и освещению, наполнять игру звуковым сопровождением, анимировать персонажей и программировать на BluePrints.
• Разработчик игр (Unreal Engine) от IT Avenue — трехмесячный онлайн-курс для освоения базовых навыков геймдева. Преподают геймдизайн, С++, игровую логику. Научат создавать и анимировать персонажей, настраивать звуки, эффекты и освещение, тестировать готовый продукт.
• Base. Unreal engine от XRschool — практический интенсив, состоящий из 21 занятия и работой над итоговым игровым проектом. Научат разрабатывать анимированные сцены, создавать собственные материалы и текстуры, настраивать звук и освещение, подбирать спец.эффекты. В конце выдается удостоверение о повышении квалификации.
• Unreal Engine — полное руководство по разработке на С++ от Udemy — учебно-практический курс с основ до полноценного игрового продукта. Рассматриваются все ключевые концепты движка, учат писать коды на С++. В процессе собирается материал для собственной игры. На выходе слушатель получает в портфолио шутер с видом от третьего лица.

Еще 5 курсов по Unreal Engine 5

Обновленный движок Unreal Engine 5 — это возможность создавать сотни персонажей, отличающихся лицом, одеждой, аксессуарами. Версия позволяет разработчикам использовать сетки с высокой детализацией процессов и динамическую глобальную систему освещения. Программное обеспечение уже оценили архитекторы, графические дизайнеры и другие специалисты, работающие над созданием виртуальных объектов.

• Unreal Engine 5 для дизайнеров и архитекторов от Специалист.ru — курс рассчитан на специалистов, работающих в сфере 3D-моделирования. Учат ориентироваться в интерфейсе, переносить объекты из 3dsMax вместе с материалами, освещением, анимацией, работать с библиотеками, настраивать свойства 3D-моделей в условиях движка, оптимизировать процесс с помощью Nanite, создавать и редактировать материалы.
• Уроки Unreal Engine от itProger — программа для новичков, желающих освоить обновленный движок. Научат работать с интерфейсом, делать красивую дизайн-среду, пользоваться возможностями встроенного магазина. Расскажут об особенности написания кода и возможности использовать No Code или Low Code подход, а также познакомят с работой Blueprints.
• Разработчик игр на Unreal Engine 5 от Teachmeskills — 9-месячный полный курс с нуля до трудоустройства. В программе — изучение системы визуального программирования Blueprints, языка С++, особенностей данной версии движка, проектирование и создание игр, освоение работы VFX, анимациями, звуками, левел дизайном.
• Unreal Engine 5 от Arhiteach — это курс архитектурной визуализации для профи. Слушатели получают сертификат международного образца по окончании обучения, более 160 уроков и сотни практических заданий для наполнения портфолио, живые вебинары с моментальной обратной связью, навыки для создания высокооплачиваемых кейсов.
• Разработка игр на Unreal Engine 5 от Scream School — курс для программистов, желающих создавать собственные игровые проекты. За несколько месяцев здесь научат полностью использовать потенциал движка для разработки креативных и коммерчески значимых проектов.

Еще 4 курса по Unreal Engine 4

Курсы Unreal Engine 4 остаются самыми востребованными у желающих освоить разработку компьютерных и мобильных игр, архитектурных рендеров и других виртуальных моделей.

• Создание игр на Unreal Engine 4 от Михаила Русакова — авторский видеокурс из 184 обучающих роликов продолжительностью около 41 часа. У издателя есть блог и группа в ВК, но для продажи данного учебного пособия создан сайт. Материал разбит на 12 блоков. Каждый модуль посвящен отдельной теме с лекциями и практическими примерами. К каждому уроку разработано упражнение, которое необходимо выполнить. Обратная связь возможна только на страничках в соцсетях.
• Unreal Engine 4 - Реалистичный Рендер Кухни-Гостиной от Udemy.com — курс для продвинутых пользователей, рассчитанный на 14 часов. Потребуются знания 3D Studio Max, Photoshop. Научат работать с 3D объектами с помощью инструментов Unreal Engine.
• Архитектурная визуализация в UE4 от CGTarian — онлайн-курс для тех, кто уже в профессии и хочет расширить уровень компетенций. Продолжительность — 2 месяца, старт назначается 1 раз в 3 месяца. Программа состоит из лекций, практических занятий с инструктором. Слушателю придется выделять 5–10 часов в неделю на обучение.
• Шутер на Unreal Engine 4 от itProger — это видеоурок по созданию шутера с помощью инструментов Unreal Engine 4. Научат настраивать камеру, шкалу жизни и доспехов персонажа, нанесение урона, прокачку навыков, оружия, снаряжения, стрельбу и прицеливание, анимацию, врагов, ИИ и другие элементы.

Бесплатные курсы по Unreal Engine

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

1. Создание игр на Unreal Engine — Stepik

Обучающий курс включает практику работы с обновленным движком UE5. В программе заявлены 125 теоретических урока, 103 теста для закрепления знаний, 163 интерактивные задачи.

Главное о курсе:

• предназначен для новичков и продвинутых пользователей;
• желательно знать английский язык на уровне чтения технической литературы;
• практика по созданию офлайн и онлайн игр;
• базовое изучение С++;
• обзор и применение основных функций Unreal Engine 5.

2. Unreal Engine 5 + Blender — «Мультодей»

Это видео-учебник по игровому дизайну для начинающих геймдевов. Он состоит из видеофильма, в котором развернуто рассказывается обо всех нюансах работы с движком. Особое внимание уделяется написанию собственного прототипа и сценария игры. В конце обучения вы научитесь создавать 3D-активы.

Главное о курсе:

• программа включает все этапы разработки игр (пре-продакшн, прототипирование, создание реквизитов и персонажей в Blender);
• 6-часовое видео разбито на эпизоды для удобной навигации;
• в видео включены отзывы о движке от разработчиков игр.

3. Базовый курс по Unreal Engine — AdQuantumDesign

Это 3-часовой видеофильм по работе в Unreal Engine 4 на примерах создания рекламных роликов для мобильных игр. Это пошаговая инструкция всего процесса и рекомендации, как достичь желаемого результата. Рассматриваются типовые вопросы, возникающие при установке движка и использовании инструментов.

Главное о курсе:

• подробный обзор интерфейса и режимов;
• установка плагинов;
• карты высот, каналы освещения, принципы работы с материалами;
• анимация и настройки рендера.

4. Game Animation Sample Project 5.5 Updates — Unreal Engine

Стрим, первый прямой эфир которого завершился 17 января 2025 года. Он посвящен разбору особенностей версии Unreal Engine 5.5. В нем появились обновления для движка, некоторых типовых проектов и анимации. В данном видео они рассматриваются на конкретном игровом проекте.

Главное о курсе:

• стримы проводятся раз в неделю;
• работает чат, в котором можно задавать вопросы авторам и его гостям;
• авторы проекта — команда профессиональных создателей анимационных объектов;
• на главной странице канала можно найти массу материалов о предыдущих версиях Unreal Engine.

Разработчик игр на Unreal Engine

Род деятельности

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

Навыки

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

Где учиться

Этой специализации обучают только на курсах, поскольку в учебных заведениях она пока не представлена. Один из вариантов — получить образование программиста, а затем самостоятельно освоить разработку игр на Unreal Engine.

Уровень заработной платы

Разработчики на Unreal Engine востребованы в различных сферах, включая гейм-девелопмент, архитектурную визуализацию и VR/AR. Средняя зарплата начинающего специалиста составляет около 60–80 тысяч рублей в месяц, а опытные разработчики могут зарабатывать от 150 до 300 тысяч рублей.

Рассмотрим несколько активных вакансий на hh.ru:

• Программист / Разработчик Unreal Engine 4/5 Developer (C++ / Blueprints) с опытом работы от 3 до 6 лет — до 200 000 руб. на руки;
• Blender-специалист со знаниями Unreal Engine 5 — от 250 000 до 300 000 руб. до вычета налогов;
• Технический дизайнер / Technical artist (Unreal Engine) — от 80 000 до 120 000 руб. на руки
• Cinematic Artist/Level Designer/Environment Artist/Layout Artist — от 100 000 руб. на руки.

Заключение

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

Подборки по схожим темам:

1. Лучшие курсы по созданию сайтов
2. Лучшие курсы веб-разработчика
3. Лучшие курсы HTML и CSS
4. Лучшие курсы по языкам программирования

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

В этой статье рассмотрим основные шаги и этапы в разработке, независимо от того, хотите вы создать игру «для себя» или для монетизации.

Выбор платформы и инструментов

Это первый и, пожалуй, самый важный шаг. Всё зависит от выбранного типа игры, ваших навыков, и платформы, на которой игра будет размещена.

1. Unity — самый популярный движок, известный своей гибкостью и возможностью создавать как 2D и 3D игры. На Unity можно клипать игры для ПК, консолей и мобильных устройств. Более половины всех игр созданы с этим движком.
2. Unreal Engine — движок от Epic Games, известный своей классной графикой и детализацией. Unreal Engine используют для создания ААА-игр за счёт работы на Blueprints. Кстати, многие крупные геймдев-компании предпочитают именно Unreal Engine.
3. Godot — открытый исходный код движка, который набирает популярность благодаря лёгкости освоения. У Godot есть свой язык, GDScript, который даёт возможность перейти к созданию игр без сложных настроек.

Есть два способа создания игр: программирование и визуальное программирование. И если с «обычным» программированием всё понятно, то с помощью Blueprints в Unreal Engine можно создавать сложные логические структуры; а GDScript — более традиционный способ программирования, но с упрощённым синтаксисом.

Сообщество геймдева, кстати, активно поддерживает разработчиков через форумы (например, gamedev.ru). Там вы сможете найти советы и истории разработки от профессионалов сферы.

Основы игрового дизайна

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

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

Третий шаг — тестирование MVP. Это тестирование идей и механик ещё до публикации игры. С помощью простых прототипов вы сможете проверить, как работает геймплей без необходимости полного погружения в разработку.

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

Базовые навыки в геймдеве

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

Без кода игра не будет работать так, как задумывалось (спасибо, кэп). Самыми популярными языками программирования для разработки игр считаются C#, Python и C++.

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

Python обычно не используется для больших коммерческих проектов из-за ограничений по производительности. Но всё-таки он идеально подходит для обучения и создания простых прототипов. Всё благодаря его (относительной) лёгкости в теории и на практике.

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

Графика и звук очень важны в создании «атмосферности». Именно с помощью них пользователи полностью погружаются в процесс игры.

• Начните с освоения базовых инструментов работы с графикой по типу Фотошопа или GIMP для 2D-графики и Blender или Maya для 3D-моделирования. Не забывайте про основы текстурирования и освещения — так сцены будут более реалистичными.
• Работа со звуком — создание и поиск подходящей музыки и звуковых эффектов. С этим помогут программы по типу Audacity или FL Studio, а ещё сайт Looperman, где можно найти бесплатные сэмплы. Звук существенно влияет на восприятие игры пользователями — от тревожной музыки до ярких звуков во время победы.

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

Анимация тоже важна. Здесь имеется в виду движение персонажей и объектов в самой игре. С этим поможет Spine для 2D-анимации и Adobe After Effects.

Что ещё важно

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

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

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

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

1. Определите ключевые элементы вашей игры. Например, если вы делаете платформер, сосредоточьтесь на механике прыжков и взаимодействии с препятствиями.
2. Используйте Photoshop или GIMP для создания спрайтов вашего персонажа и окружения.
3. Для программирования выбирайте игровые движки: Unity, Unreal Engine или Godot. У каждого из этих движков большой набор инструментов для начинающих. А в интернете можно найти подробную документацию и руководства по созданию игры.
4. Создайте тестовый игровой уровень, на котором вы и протестируете основные механики.

Далее наступает время тестирования. Это может быть либо самостоятельное тестирование, либо альфа/бета-тесты с привлечением небольшого пула игроков — так вы буквально сможете увидеть игру глазами ваших пользователя. А они укажут на элементы в игре, которые вы могли не заметить во время разработки.

После того, как получили первые отзывы на этапе тестов, важно доработать игру:

• Исправьте выявленные ошибки;
• Усильте графику, анимацию и звуковое сопровождение;
• Добавьте новые уровни или усложните уже существующие.

Рекомендации

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

Среди самых известных геймджемов — Ludum Dare, который проводится с 2002 года. Многие игры, впервые созданные на LD, далее превращались в полноценные коммерческие проекты: например, игра Druid, Broforce, Pony Island (от создателей Inscription).

А с помощью открытого исходного кода вы, как создатель игры, сможете изучить лучшие практики от опытных разработчиков и «забрать» их себе. На GitHub можно запросто найти много игр с открытым исходным кодом: от простых 2D-головоломок до сложных 3D-приключений.

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

И помните: многие игры создавались в одиночку. И при этом достигали большого успеха: Sally Face, Plague Inc, Papers, Please. И, конечно же, любимый многими разрабами Stardew Valley :)

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

Массив — структура данных фиксированного размера. Его элементы должны быть одного типа. Например: [10, 12, 85, 27]. Массивы статичны: нельзя изменить размер или тип элементов после объявления.

Список — динамическая структура данных. В нем можно хранить элементы разных типов. Такая структура есть в Python. Пример списка: [0,”red”, 8.5, False].

Создание массивов и связанных списков отличается в зависимости от языка программирования. Рассмотрим примеры на Python, Java и C++.

Объявление и создание

В C++ память под массив выделяется статически, размер фиксируется на этапе компиляции. В Python и Java коллекции динамические — можно менять их размер во время выполнения программы.

В Python список обозначается квадратными скобками:

В Java и C++ массивы объявляются с указанием типа данных, их значения заключаются в фигурные скобки:

Операции с массивами и списками

Основные операции для работы с массивами и списками:

• чтение и запись элементов по индексу,
• добавление новых элементов,
• удаление элементов,
• поиск элемента,
• сортировка.

Чтение и запись

Чтение и запись осуществляется с помощью индексов — целочисленных значений, указывающих позицию элемента. Индексация начинается с 0. Первый элемент имеет индекс 0, второй — индекс 1 и т. д.

Запись элемента в Python выполняется с присваиванием значения по индексу:

Отрицательные индексы

При обращении к элементам списка важно следить за границами индексов.

В Python допустимо обращение к элементам через отрицательные индексы:

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

Выход за пределы массива в C++ — неопределенное поведение. Все, что хранится за границами массива при обращении перезаписывается новым значением.

Java не поддерживает отрицательные индексы.

Добавление новых элементов

Добавление и удаление элементов зависит от используемого языка. В Python для этого есть встроенные методы:

В Java и C++ для добавления и удаления элементов массива нужно создавать новый массив. Процесс можно упростить с помощью динамических структур данных — класса ArrayList в Java или vector в C++.

Итерации и циклы

Самый распространенный способ обработки массивов и списков — циклы.

Цикл for позволяет обрабатывать элементы по порядку:

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

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

Пример подсчета элементов, значение которых больше 300:

Пример фильтрации списка:

В новый список попали только четные числа (те, которые делятся на 2 без остатка).

Пример преобразования данных путем возведения каждого значения в 3-ю степень:

Расширенные методы работы со списками

Python предоставляет множество методов для работы со списками.

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

Указатели и ссылки при работе с массивами в C++

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

Указатель — переменная, которая хранит адрес другой переменной.

Ссылка — альтернативное имя для существующего объекта.

Пример использования указателей для работы с массивами в C++:

Различия в реализации в языках программирования

Массивы в C++ vs списки в Python

В C++ работа с массивами происходит на низком уровне. Нужно следить за выделением и освобождением памяти, индексами и переполнением массива. В Python используются высокоуровневые списки, которые хранят ссылки на объекты в динамической памяти.

Типизация

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

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

Размер

Размер массива в C++ фиксируется при объявлении и не может быть изменен во время выполнения программы. Для изменения размера массива требуется создать новый и скопировать элементы.

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

Производительность

Массивы в C++ хранятся в непрерывной области памяти, поэтому операции с элементами выполняются быстрее, чем в Python. Однако в В C++ разработчик несет ответственность за выделение и освобождение памяти.

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

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

Методы и функциональность

Массивы в C++ имеют ограниченный набор встроенных операций и функций. Для выполнения более сложных операций требуется реализация собственных алгоритмов или использование внешних библиотек (например, STL).

Списки в Python предоставляют широкий набор встроенных методов и функций — добавление, удаление, сортировка, поиск и многое другое.

Массивы в Java vs списки в Python

Массивы в Java и списки в Python также имеют некоторые различия.

Типизация

Массивы в Java должны содержать элементы одного типа. Тип элементов указывается при объявлении массива.

Списки в Python могут работать с элементами разных типов.

Размер

Размер массива в Java фиксируется при его создании и не может быть изменен. Для смены размера требуется создание нового массива и копирование элементов.

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

Методы и функциональность

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

В основе Python есть набор встроенных методов для списков. В их числе добавление, удаление, сортировка, поиск, фильтрация и многое другое.

Производительность

Массивы в Java обеспечивают быстрый доступ к элементам по индексу и могут быть более эффективными при выполнении некоторых операций, особенно при работе с большими объемами данных.

Списки в Python медленнее по сравнению с массивами в Java, но предоставляют больше удобства и гибкости в использовании.

Советы по оптимизации и частые ошибки

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

Избежание переполнения массива

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

Оптимизация времени выполнения операций

При работе с массивами и списками рекомендуется использовать следующие подходы:

• Использовать фиксированные и динамические массивы для конкретной задачи. Например, хранить дни недели в фиксированном массиве и пользователей в динамическом.
• Сократить количество операций изменения размера массива или списка до минимума.
• Выделять памяти для массивов заранее, если известен их размер.

Устранение ошибок индексирования

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

• Проверять границы массива или списка перед доступом к элементам.
• Использовать соответствующие условия и циклы для итерации по элементам.
• Быть внимательным при работе с индексами, особенно при изменении размера массива или списка.

Пример доступа к элементам массива с проверкой границ на C++:

Что запомнить

• Массивы и списки используются для хранения и управления коллекциями элементов.
• NumPy в Python предоставляет инструменты для работы с многомерными массивами и матрицами, упрощая реализацию сложных алгоритмов. В других языках программирования есть аналоги: Eigen для C++ и Parallel Colt для Java.
• При работе с динамическими массивами в C++ необходимо использовать указатели и ссылки для выделения и освобождения памяти.
• Массивы в C++ и Java типизированные и имеют фиксированный размер. Списки в Python могут содержать элементы разных типов и имеют динамический размер.
• Во избежание ошибок индексирования необходимо проверять границы массива/списка перед доступом к элементам.

Желаем удачи в работе с массивами и списками!

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

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

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

О них сегодня и поговорим.

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

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

Устраивайтесь поудобнее и наливайте себе кружечку чая — перехожу к подборке сервисов для оценки и улучшения качества кода 🙂

SonarQube

Этот популярный инструмент для анализа качества кода способен выдавать результаты для более 30 языков программирования. SonarQube подходит для выявления ошибок, уязвимостей и проблем с безопасностью в коде, поддерживает поиск ошибок согласно правилам стандартов MISRA C, MISRA C++, MITRE/CWE и CERT Secure Coding Standards.

Он измеряет буквально всё:

1. качество кода;
2. потенциальные ошибки;
   
3. форматирование;
   
4. объявления переменных;
   
5. обработку исключений;
   
6. повторения участков кода и многое другое.
   

Сервис позволяет анализировать проекты, написанные на разных языках программирования, может быть интегрирован в конвейеры CI/CD, цикл сборки Maven и Gradle. Загрузить SonarQube можно с официального сайта.

ESLint

ESLint — это инструмент для анализа и улучшения кода, написанного на JavaScript и ECMAScript. Он помогает выявлять синтаксические ошибки, проблемы в шаблонах проектирования и отклонения от стиля кодирования, а еще, как и другие линтеры, способен «причесывать» код на основании заданных правил.

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

Среди преимуществ ESLint:

• Настраиваемость. Можно настроить правила проверки валидности кода под конкретные нужды проекта, обеспечивая единообразие стиля кода в команде, например, нам ESLint позволяет всем разработчикам писать код в едином стиле и придерживаться описанных в конфиге правил.
• Поддержка современных стандартов. Инструмент поддерживает новейшие стандарты JavaScript и популярные фреймворки (React, Vue.js, Node.js, TypeScript и др.), что помогает предотвратить использование устаревших/некорректных конструкций.
• Интеграция с редакторами кода и CI/CD. Можно интегрировать ESLint в редакторы кода и автоматические системы сборки для проверки HTML-кода на ошибки на каждом шаге разработки. Поддержка плагинов и расширений: можно расширять функционал с помощью плагинов и выполнять онлайн-проверку HTML-кода на основании специфичных для проекта или фреймворка правил.

Последняя выпущенная на данный момент версия сервиса – ESLint v9.17.0.

Codacy

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

Инструмент подходит для проверки кода на Java, Python, JavaScript, PHP и более 30 других языках, а еще с помощью искусственного интеллекта он может автоматически исправлять код, делая процесс его написания максимально эффективным.

Среди особенностей Codacy:

• возможность интеграции с GitHub, GitLab, Bitbucket и другими CI/CD-инструментами для автоматизации проверок;
• отслеживание прогресса — за счет метрик и наглядных отчетов о качестве кода и техническом долге;
• упрощение командной работы — благодаря добавлению комментариев и замечаний в pull request;
• поддержка интеграции с трекерами задач — например, с Jira, Trello и т. д.;
• универсальность — сервис подходит для проверки кода в облаке (например, его можно использовать совместно с облачной базой данных MySQL) или на локальном сервере.

Psalm

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

Вот несколько возможностей Psalm:

• Раннее выявление ошибок. Сервис анализирует код без его выполнения и находит ошибки еще на этапе разработки, таким образом, можно предотвратить баги в продакшене;
• Поддержка строгой типизации. Psalm работает с аннотациями типов в PHPDoc, что упрощает работу с типами данных и минимизирует ошибки, связанные с неправильными типами;
• Обнаружение устаревшего кода. С этим инструментом легко находить и удалять неиспользуемые методы, переменные и классы, улучшая читаемость и производительность проекта;
• Совместимость с популярными IDE и плагинами. Например, PhpStorm, что обеспечивает удобный процесс исправления ошибок, а поддержка самых разных плагинов (Symfony, Laravel, Doctrine и др.) позволяет настроить Psalm для анализа специфичных случаев или интеграции с другими инструментами.

В Бегете мы используем этот инструмент для поддержания качества кода, снижения количества ошибок и обеспечения согласованности стиля кодирования в разных проектах. Psalm поддерживает настройку уровней строгости анализа, поэтому его можно адаптировать под потребности конкретного проекта, что довольно удобно. При этом сервис легко настраивается для работы в системах непрерывной интеграции, таких как GitHub Actions, GitLab CI или Jenkins, то есть проверка кода может выполняться автоматически.

Документация Psalm доступна на официальном сайте, также есть страница на GitHub.

Code Climate

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

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

А еще Code Climate помогает:

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

Благодаря поддержке множества языков можно производить проверку кода на JS, Python, Ruby, PHP, Go и т. д., так что сервис может пригодиться в различных проектах, кроме того, он легко интегрируется в процессы непрерывной интеграции и доставки (CI/CD), обеспечивая автоматический анализ кода при каждом коммите или пулл-реквесте.

Выбрать тарифный план можно на официальном сайте, также доступна 14-дневная бесплатная пробная версия.

Заключение

Сегодня, когда количество библиотек с открытым исходным кодом только растет, анализ и аудит кода обязательны для IT-компаний, а качество кода – едва ли не краеугольный камень для создания любого ПО. Чистый код повышает эффективность разработки, упрощает понимание и поддержку проекта, снижает затраты на тестирование и, наконец, способствует более быстрому внедрению новых функций.

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

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

На этом всё, выбирайте подходящий сервис — и пусть ваш код всегда будет чистым 🙂

Буду рада вашим комментариям!

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

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

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

Новые возможности Fish 4.0

Переход на Rust открыл двери для улучшений и новых функций. Среди ключевых нововведений в Fish 4.0:

• Обновленные привязки клавиш: Бинды стали более интуитивными, упрощая взаимодействие с терминалом.
• Улучшенный поиск по истории: Теперь пользователи могут находить команды быстрее благодаря более мощным алгоритмам поиска.
• Поддержка многопоточности: Благодаря Rust, Shell теперь эффективно обрабатывает несколько задач одновременно.

Эти изменения делают Fish еще более удобным и современным инструментом для работы в командной строке.

Как протестировать новую версию?

Бета-версия Fish 4.0 доступна для тестирования. Установочные пакеты предоставлены для macOS, Ubuntu и других популярных дистрибутивов Linux.

Также доступны портативные бинарные файлы, которые можно запустить без установки.

Для тестирования пользователи могут перейти на официальный сайт проекта и скачать соответствующую версию.

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

TypeScript впервые стал #1 на GitHub, обогнав Python и JavaScript

Python по-прежнему лидирует в TIOBE (21,25%), но потерял 2,59 п.п. за год

Go упал с 7-й на 16-ю позицию в TIOBE — самое неожиданное падение года

Самые высокие зарплаты в РФ у Go-разработчиков — 320 000 ₽ (медиана)

Рост зарплат в IT остановился: +19% (H2’2024) → 0% (H2’2025)

На что мы опирались при составлении этого обзора:

TIOBE Index (март 2026) — отслеживает популярность языков программирования на основе поисковых запросов, упоминаний в новостях, научных статьях и на форумах.

GitHub Octoverse 2025 — рейтинг на основе статистики GitHub. Показывает, какие языки используют в репозиториях и какие проекты популярны среди пользователей.

Данные Хабр Карьеры (H2 2025) по медианным зарплатам программистов, работающих с разными языками.

В статье рассмотрим:

1. Python;
2. TypeScript;
3. JavaScript;
4. Java;
5. C++;
6. Golang (Go);
7. 1С.

Python

Популярность

Python уверенно удерживает первое место в рейтинге TIOBE с долей 21,25%, хотя за год потерял 2,59 процентных пункта. На GitHub он опустился на 2-е место, уступив TypeScript. При этом по числу новых репозиториев Python вырос на 53% за год — 9,26 млн новых репо.

Уровень зарплат

Медианная зарплата Python-разработчиков во втором полугодии 2025 составила 229 000 ₽ (+8% к H1 2025). Python показывает стабильный рост зарплат на фоне общего замедления рынка.

Перспективы

Python — ключевой инструмент для анализа данных, машинного обучения, автоматизации и веб-разработки. Бум ИИ продолжается: 1,1 млн публичных репозиториев на GitHub используют LLM SDK (+178% за год), и Python остаётся языком #1 для ИИ-проектов.

TypeScript

Популярность

TypeScript совершил исторический прорыв: в августе 2025 он впервые стал языком #1 на GitHub по числу контрибьюторов, обогнав Python и JavaScript. GitHub назвал это «самым значительным сдвигом за десятилетие». Рост числа контрибьюторов — +66,63% за год, а новых репозиториев стало на 78% больше.

В рейтинге TIOBE TypeScript пока не вошёл в топ-10, но это объясняется методологией индекса: TIOBE считает поисковые запросы, а не реальное использование.

Уровень зарплат

В российских зарплатных обзорах TypeScript обычно объединяют с JavaScript. Медиана для JavaScript/TypeScript-разработчиков во втором полугодии 2025 — 241 000 ₽ (+11%).

Перспективы

TypeScript популярен в веб- и мобильной разработке, облачных и корпоративных приложениях. Главная причина роста — ИИ: строгая типизация TypeScript делает код, сгенерированный Copilot и другими ИИ-ассистентами, безопаснее для продакшена. Крупные фреймворки теперь по умолчанию генерируют проекты на TypeScript.

JavaScript

Популярность

JavaScript сохранил 6-ю позицию в TIOBE (3,45%) и опустился на 3-е место на GitHub, уступив TypeScript. Но важно понимать: JavaScript + TypeScript вместе по-прежнему образуют крупнейшую экосистему. По числу новых репозиториев JavaScript всё ещё лидирует — 9,35 млн (+14,6%).

Уровень зарплат

Медианная зарплата JavaScript/TypeScript-программистов во втором полугодии 2025 составила 241 000 ₽ (+11%). Это один из самых заметных ростов среди всех языков.

Перспективы

JavaScript остаётся фундаментом веб-разработки, хотя многие проекты мигрируют на TypeScript. В России спрос на JS-разработчиков стабильно высок благодаря цифровизации бизнеса и импортозамещению. Node.js позволяет использовать его как для фронтенда, так и для бэкенда.

Java

Популярность

Java опустился на 4-е место в TIOBE (7,99%, -2,37 п.п.), но это всё ещё один из крупнейших языков мира. На GitHub Java держится на 4-м месте с устойчивым ростом контрибьюторов (+20,7%).

Уровень зарплат

Медианная зарплата Java-разработчиков — 226 000 ₽ (+1% к H1 2025). Рост минимальный, но стабильный.

Перспективы

Java активно используют в корпоративных приложениях, банковских сервисах и Android-приложениях. В России появилась отечественная IDE — OpenIDE — для работы с Java и другими языками. Это хороший сигнал для развития экосистемы.

C++

Популярность

C++ опустился с 2-й на 3-ю позицию в TIOBE (8,18%), уступив место языку C. На GitHub C++ стабильно входит в топ-6 языков по использованию.

Уровень зарплат

Медианная зарплата разработчиков на C++ — 241 000 ₽ (+14% за полугодие). Это самый сильный рост среди всех языков во втором полугодии 2025.

Перспективы

C++ остаётся основным инструментом для геймдева, встроенного ПО и высокопроизводительных систем. Рост зарплат на 14% объясняется спросом в embedded-разработке и оборонном секторе. Изучать C++ как первый язык непросто, но после него легко освоить другие языки.

Golang (Go)

Популярность

Go показал самое неожиданное падение года: с 7-й на 16-ю позицию в TIOBE (-1,49 п.п.). Однако это не значит, что язык теряет актуальность — TIOBE меряет поисковые запросы, а не реальное использование. На практике Go остаётся одним из самых востребованных языков в России.

Уровень зарплат

И вот главный аргумент: Go-разработчики получают самые высокие зарплаты среди всех языков в нашем рейтинге. Медиана — 320 000 ₽ (+4% к H1 2025). Это на 37 000₽ больше, чем у C# и на 91 000₽ больше, чем у Python.

Перспективы

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

1С

Популярность

Этого языка нет в международных рейтингах TIOBE и GitHub — в наш топ он попал вне конкурса. 1С использует большинство компаний России для бухучёта, управления торговлей и расчёта зарплат.

Уровень зарплат

Медиана для 1С-программистов — 200 000 ₽. Рост зарплат остановился (0% во втором полугодии 2025). На рынке переизбыток джунов, но синьоры 1С по-прежнему в дефиците.

Перспективы

Спрос на 1С-разработчиков стабилен благодаря импортозамещению: компании переходят на отечественное ПО. 1С — идеальный шанс войти в IT для тех, кто не уверен в английском.

Кстати, мы уже публиковали статью «Стоит ли учиться программированию на 1С» — там можно узнать все за и против.

Окей, так какой язык выбрать в итоге?

Зависит от ваших интересов и направления, в котором планируете развиваться.

— Хотите строить карьеру в области ИИ, анализа данных или автоматизации — обратите внимание на Python. Это лучший старт для новичков.

— Для веб-разработки и фулстека — TypeScript (язык #1 на GitHub) или JavaScript. TypeScript становится стандартом для новых проектов.

— Хотите максимальную зарплату и работу в финтехе — выбирайте Go. Медиана 320 000₽ — это на 40% больше, чем у Python.

— Универсальный и стабильный выбор — Java. Корпоративные приложения, банки, Android — Java подходит для любых задач.

— Геймдев, embedded, системы реального времени — C++. Зарплаты выросли на 14% за полгода.

— Для работы в российских компаниях — 1С. Идеальный шанс войти в IT без английского.

В комментариях можно дополнить наш обзор — и поделиться своим опытом. Так статья будет еще полезнее!

Если бы вы составляли топ языков для изучения в 2026 году, какие ЯП туда бы включили и почему?

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

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

Кто и как создаёт нейросети

Начнём с азов.

Нейросетями занимаются ML-инженеры — специалисты по машинному обучению.

Чтобы создать нейросеть, нужно пройти следующие этапы:

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

Таким образом, создание нейросетей — процесс, включающий сбор данных, выбор модели, обучение, проверку и, при необходимости, настройку.

Языки машинного обучения

Python

Самый популярный язык программирования этого года по версии TIOBE, а также № 1 в машинном обучении. По данным ChatGPT и Google Bard, они созданы с использованием Python и фреймворков для глубокого обучения TensorFlow и PyTorch.

Плюсы Python:

• простой синтаксис, который может легко освоить даже новичок в программировании. Также это плюс и для опытных инженеров — вместо того чтобы думать, как обойти технические сложности языка, они могут сконцентрироваться на решении задач машинного обучения
• большое количество библиотек и фреймворков, которые помогают в создании ML-моделей и ускоряют разработку. Например, TensorFlow, Keras, Scikit-learn и Pandas
• Python легко интегрируется с другими языками программирования, что полезно при работе с библиотеками и инструментами, написанными на других языках

Минусы Python:

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

Java

Ещё один популярный выбор ML-инженеров, которые ценят стабильность, надёжность и производительность. Java использовали для создания чат-бота A.L.I.C.E., выпущенного в 1995 году, мобильных роботов для исследований полярного круга и движка для разработки рекомендательных систем Seldon Server.

Плюсы Java:

• Java — кроссплатформенный язык программирования. Поэтому код на этом языке без изменений работает на любых операционных системах. Это особенно важно при создании нейросетей, предназначенных для использования в разных средах
• Java известен стабильностью и надёжностью, что может быть серьёзным плюсом при разработке критически важных систем, например в области медицины и финансов
• Java имеет большую библиотеку и фреймворки для обучения нейросетей (например, Weka, Apache Mahout, Deeplearning4j, Mallet, MLlib)

Минусы Java:

• Java — компилируемый язык, поэтому код сначала компилируется в машинный, а затем выполняется. Это может замедлить процесс разработки и обучения нейросетей
• сообщество разработчиков в области машинного обучения в Java не такое активное, как в случае с Python. Это значит, что сложнее найти обучающие материалы и ответы на свои вопросы

С++

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

Плюсы С++:

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

Минусы С++:

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

C#

C# — универсальный язык от компании Microsoft, который она активно продвигает для машинного обучения, для чего создала библиотеку ML.NET.

Плюсы C#:

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

Минусы C#:

• в сравнении с такими языками, как Python, у C# более ограниченная экосистема библиотек и фреймворков для машинного обучения
• C# более сложный для освоения новичками, чем тот же Python

R

Язык R разработали учёные факультета статистики Оклендского университета. Обычно он используется в связке с Python для обработки и визуализации данных.

Плюсы R:

• имеет большое количество библиотек для машинного обучения и работы с данными: Caret, DataExplorer, Dplyr, Ggplot2, kernLab и другие
• если ваши данные и задачи тесно связаны со статистикой, R может быть хорошим выбором, так как он широко используется в академических и исследовательских сферах

Минусы R:

• может быть менее эффективным по сравнению с такими языками, как C++ или Python, что может сказаться на производительности при обучении сложных нейронных сетей
• имеет меньше инструментов для развёртывания ML-моделей, что усложняет работу с ними
• довольно узкая сфера применения

Выводы

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

Дальше можно добавить R для работы с большими данными. А если вы уже не новичок в программировании, подойдут Python, Java или С++ (последний особенно актуален для проектов в сфере интернета вещей).