Практический интерес здесь не в самом Plush, минималистичном динамическом языке на Rust, а в измеренном ответе на старый вопрос: сколько стоит стековая модель байткода. Вывод автора сформулирован жёстко: «вам, вероятно, не стоит писать стековые байткод-интерпретаторы в 2026 году» (перевод редакции). Для тех, кто пишет свои DSL, скриптовые движки или встраиваемые интерпретаторы, это готовый аргумент с цифрами и с честным списком того, что не ускорилось.

• Медианное ускорение 2,07 раза, максимальное 3,37; геометрическое среднее 1,94 раза, из них 1,55 дала сама регистровая модель без оптимизаций, ещё 25% добавили специализированные инструкции.
• Инструкция теперь 64-битное слово вместо enum на 24 байта; трёхадресная форма reg(a) = reg(b) + reg(c), до 64 000 локальных переменных, 76 опкодов.
• Замеры: MacBook Air M5 (10 ядер, arm64), rustc 1.96.0, 11 чередующихся запусков на тест, медиана; повторный прогон дал те же результаты.
• Против Lua 5.5.1: быстрее на 24% в fib и на 55% в binary_tree; сравнение с CPython 3.14.6 и CRuby 4.0.6 автор ограничивает оговорками о разной семантике и составе тестов.
• Тесты сборщика мусора почти не изменились: регистровая модель ускоряет диспетчеризацию, а не аллокацию.

Почему стековая машина медленнее

В стековой VM выражение a + b превращается в три инструкции: положить a, положить b, сложить. Каждая инструкция проходит через диспетчер: прочитать опкод, перейти на обработчик, сдвинуть указатель. В регистровой VM то же выражение записывается одной инструкцией с тремя операндами: куда положить и что сложить. Главный тезис статьи: в интерпретаторе самый большой рычаг производительности это число инструкций, которые нужно продиспетчеризовать, и регистровая модель сокращает его в разы. Автор цитирует это как основной вывод: «снова, в интерпретаторе главный рычаг это уменьшение числа инструкций» (перевод редакции).

Второй эффект: значения не гоняются между локальными переменными и временным стеком. Локальные переменные и есть регистры фрейма, поэтому x = y + z не требует ни загрузки, ни сохранения.

Как устроен новый байткод

Старая инструкция была Rust-перечислением Insn размером 24 байта. Новая упакована в 64-битное слово: опкод и операнды-регистры. Для сравнения автор приводит Lua: там 32-битное слово с 8-битными полями, отсюда лимит в 255 регистров на фрейм и 200 именованных локальных переменных. У Plush поля шире, до 64 000 локальных переменных, ценой вдвое большего размера инструкции. Всего опкодов 76. Сверху добавлены оптимизации, каждая из которых убирает инструкции: слитые сравнение-и-переход, сдвиги и маски с непосредственными операндами, свёртка констант, устранение лишних пересылок. Инлайн-кэши вынесены в отдельные таблицы, чтобы не раздувать слово инструкции.

Замену enum на 64-битное слово автор описывала неделей раньше, тогда это дало 17% на старой стековой модели; нынешняя статья седьмая в серии о Plush.

Что показали замеры и где их границы

Методика описана подробно: MacBook Air M5, rustc 1.96.0, для каждого сравнения 11 чередующихся запусков старой и новой версии, берётся медиана, весь набор прогнан дважды. Сравнивались конкретные коммиты репозитория. Неоптимизированная регистровая VM дала 1,55 раза по геометрическому среднему, оптимизации добавили ещё 25%, итого 1,94; медиана по отдельным тестам 2,07, максимум 3,37. Тесты, упирающиеся в сборщик мусора, остались на месте: диспетчеризация там не узкое место.

Сравнение с другими языками автор сопровождает оговорками: CPython 3.14.6, CRuby 4.0.6 и Lua 5.5.1 имеют другую семантику, а набор тестов синтетический. Заявлены только два прямых результата против Lua: fib на 24% быстрее, binary_tree на 55%. Отдельная демонстрация: программный рендеринг уровня Quake в 800 на 600 в один поток, около 47 кадров в секунду, с живой кучей до 1 ГБ без заметных пауз GC по оценке автора.

Что из этого забрать в свой интерпретатор

• Если вы проектируете байткод с нуля, начинайте с регистровой модели: выигрыш от неё больше, чем от любой микрооптимизации диспетчера.
• Считайте инструкции, а не такты: слитые инструкции (сравнение плюс переход) и непосредственные операнды окупаются именно сокращением диспетчеризации.
• Не ждите ускорения там, где узкое место в аллокации: GC-тесты Plush не изменились.
• Готовые бинарники Plush есть для Linux и macOS (x86-64 и arm64) и через PowerShell-установщик для Windows x86-64; код под Apache-2.0, примеры под CC0, всё в репозитории.

Кому это не пригодится: тем, кто использует готовые рантаймы и не пишет свои. CPython, к слову, остаётся стековой машиной, и разница подходов хорошо видна на его фоне; о цене операций в самом Python мы недавно писали в связи с новой 3.15.0rc2. Другой свежий пример переписанного интерпретатора с подробным разбором каждой оптимизации: Wasmi 2.0, где тоже сменили промежуточное представление и получили 2,2 раза.

Источники: Pointers Gone Wild: Plush's New Register-Based Interpreter, Репозиторий Plush, Предыдущая статья серии: Replacing a Rust enum with a 64-bit word

Ошибка проявляется только там, где FMA эмулируется программно: на x86 это дешёвые или старые Intel без AVX2 и процессоры Hygon без аппаратного FMA, а также 32-битный ARM и старые встраиваемые тулчейны. 64-битный ARM, по словам автора, не затронут. На практике это касается детерминированных симуляций и численных библиотек, где одинаковый код обязан давать одинаковые биты на разных машинах: сетевые игры с lockstep, физические движки, воспроизводимые вычисления. Автор честно пишет, что не знает, насколько ошибка важна в реальных программах.

• Ошибка: неправильное округление fmaf на субнормальных входах, отличие на один младший бит.
• Затронуты f32::mul_add и std::simd в Rust, fmaf() в musl; проверка одна и та же: a = 0x97000800, b = 0x1cfff001, c = 0x00010002, верный ответ 0x00010001, ошибочный 0x00010002.
• Исправлены fearless_simd и ABI f128 в компиляторе Rust на 32-битном ARM; патч в стандартную библиотеку Rust на момент публикации ждал ревью, исправления musl не влиты.
• Аппаратный FMA (x86 с AVX2/FMA3, 64-битный ARM) не затронут: ошибка живёт в программной эмуляции.
• Контрпример к первой версии исправления в Rust нашла языковая модель, которую автор попросил искать ошибки.

Что такое FMA и откуда берётся лишний бит

Fused multiply-add вычисляет a*b+c с одним округлением в конце вместо двух: после умножения и после сложения. Так требует IEEE 754, и именно на это рассчитывают численные алгоритмы: одно округление даёт предсказуемую ошибку. Когда у процессора нет аппаратной инструкции, библиотека эмулирует FMA через операции с расширенной точностью и ручную коррекцию округления. Ошибка, которую нашёл автор, живёт в этой коррекции на субнормальных числах, то есть очень маленьких значениях, у которых часть мантиссы уже ушла в ноль. В таких случаях программная реализация округляла не в ту сторону.

Автор переносил формально верифицированный алгоритм и гонял его в CI на эмуляторах SIMD, добавив тесты на миллион субнормальных значений и ещё миллион случаев, требующих коррекции округления. Отдельно он попросил языковую модель искать контрпримеры, и она нашла случай, ломающий первую версию исправления для стандартной библиотеки Rust: там ошибка приводила ещё и к неправильной установке флагов исключений плавающей точки.

Как проверить свою платформу

Достаточно трёх чисел. Ниже проверка на C для fmaf из системной libc; в Rust то же самое делается через f32::from_bits и mul_add:

Если вывод 00010002, ваша libc или тулчейн эмулируют FMA с ошибкой. На машине с аппаратным FMA (любой современный x86 с AVX2, 64-битный ARM) результат будет верным независимо от библиотеки, поэтому проверять имеет смысл именно сборки под старое или встраиваемое железо и контейнеры на musl (Alpine) на таких хостах.

Состояние исправлений

• fearless_simd: исправлено, можно использовать как реализацию FMA без этой ошибки.
• Rust, тип f128 на 32-битном ARM: ошибка ABI исправлена в компиляторе (тип доступен только в nightly).
• Стандартная библиотека Rust (f32::mul_add, std::simd): патч на момент публикации ожидал ревью; номер версии с исправлением не назван.
• musl: предложены минимальное исправление и полная переработка fmaf(), ни то ни другое не влито. Автор отмечает, что код FreeBSD, откуда растёт реализация, мог копироваться и в другие тулчейны.

Кому это ничего не меняет: сервисам на современных x86 и ARM64, где FMA аппаратный, и коду, не зависящему от битовой точности. Кому стоит проверить: авторам физических движков и симуляций с детерминизмом между машинами, разработчикам под 32-битный ARM и тем, кто собирает статические бинарники под musl для старых серверов. Про то, как выбор libc влияет на скорость тех же бинарников, мы писали на примере Rust Coreutils; смежная тема из этой же недели: переписывание линкера mold на Rust. Что мы проверим дальше: когда патч попадёт в стабильный Rust и появится ли исправление в релизе musl.

Источники: Shnatsel: Implementing FMA and finding bugs in C and Rust standard libraries, Обсуждение на Lobsters

Между rc1 и rc2 вошло около 144 исправлений от 76 участников: ошибки, сборка, документация. До финала принимаются только проверенные исправления багов, новых функций не будет. Релиз-менеджер Хьюго ван Кеменаде называет rc2 финальным кандидатом и просит мейнтейнеров тестировать пакеты именно сейчас; ставить rc2 в прод команда не рекомендует.

• 3.15.0rc2 — последний запланированный кандидат; ABI заморожен, финальный релиз назначен на 1 октября 2026 года.
• JIT: в среднем на 8–9% быстрее обычного интерпретатора на x86-64 Linux и на 12–13% быстрее tail-calling interpreter на macOS с Apple Silicon; разброс по тестам от замедления на 15% до ускорения больше чем вдвое; цифры предварительные.
• Официальные сборки для Windows x64 используют tail-calling interpreter, сборки для macOS по умолчанию поддерживают free-threading.
• Новое в языке: ленивые импорты через ключевое слово lazy (PEP 810), встроенные типы frozendict (PEP 814) и sentinel (PEP 661).
• Мейнтейнерам: собирайте wheels под 3.15 и гоняйте тесты на rc2; после 1 октября исправление попадёт только в 3.15.1.

Что означает «ABI заморожен»

ABI — набор правил, по которым скомпилированный код (numpy, pydantic-core, любой пакет с C или Rust внутри) обращается к интерпретатору: размеры структур, порядок полей, сигнатуры функций. Пока ABI меняется, wheel, собранный под бету, может упасть на финальной версии. Теперь команда CPython обещает: «There will be no ABI changes from this point forward in the 3.15 series» (перевод редакции: «С этого момента в серии 3.15 изменений ABI не будет»). Значит, wheel, собранный сегодня под rc2, останется валидным для 3.15.0 и всех 3.15.x.

На практике это точка, после которой авторы популярных библиотек выкладывают на PyPI сборки для новой версии. Если ваш проект зависит от пакета, который до сих пор не собран под 3.15, самое время открыть issue или прислать PR: у мейнтейнеров есть месяц.

Сколько на самом деле даёт JIT

Документация «What's New» приводит две цифры, и их важно не смешивать. На x86-64 Linux JIT даёт 8–9% ускорения в среднем геометрическом относительно обычного интерпретатора. На macOS с процессорами Apple JIT сравнивают с более быстрым tail-calling interpreter, и там выигрыш 12–13%. Разброс по отдельным тестам огромный: от замедления примерно на 15% до ускорения больше чем вдвое. Документация подчёркивает, что цифры предварительные и до финала могут измениться. Так что «Python стал на 10% быстрее» — неверное обобщение: на вашем коде может быть и минус.

Tail-calling interpreter — другой способ реализовать цикл исполнения байткода, где каждая инструкция вызывает следующую хвостовым вызовом вместо большого switch. В 3.15 именно он идёт в официальных 64-битных сборках для Windows. Официальные сборки для macOS по умолчанию получают поддержку free-threading, то есть режим без GIL остаётся экспериментальным, но доступным без пересборки.

Три новинки языка, которые вы заметите

Ленивые импорты (PEP 810): ключевое слово lazy перед import откладывает загрузку модуля до первого обращения. Это ответ на старую проблему медленного старта CLI-утилит, которые тянут тяжёлые зависимости «на всякий случай».

frozendict (PEP 814) — неизменяемый словарь, встроенный в язык: если все его ключи и значения хешируемы, его можно использовать как ключ другого словаря, и его безопасно отдавать наружу как константу. sentinel (PEP 661) закрывает старый обходной приём с _MISSING = object() для «значение не передано»: у таких маркеров появляется нормальный repr и корректное поведение при pickle.

Что сделать до 1 октября

• Поставьте rc2 рядом с рабочей версией: официальные установщики и исходники на python.org; в uv или pyenv сначала проверьте, что версия появилась в их списках (uv python list), и прогоните тесты проекта.
• Если у вас пакет с расширениями: соберите wheels под 3.15 и выложите на PyPI; ABI больше не изменится.
• Замерьте свой код с JIT и без: флаги сборки и переменные окружения описаны в документации; средним цифрам не верьте.
• Проверьте зависимости на совместимость с ленивыми импортами: код, который полагается на побочные эффекты при импорте, с lazy сломается.
• Нашли регрессию — сообщайте в трекер CPython сейчас: после релиза исправление уйдёт только в 3.15.1.
• Если пользуетесь корпоративным зеркалом PyPI, убедитесь, что оно синхронизирует wheels с тегом cp315: первые сборки под 3.15 появятся в ближайшие недели.

Контекст

Разработка 3.15 началась 7 мая 2025 года, первая бета вышла 7 мая 2026-го, rc1 — 4 августа. После финального релиза ветка получит около двух лет исправлений ошибок и затем ещё примерно три года обновлений безопасности, по обычному графику CPython.

Источники: Python 3.15.0rc2 (python.org), What's New in Python 3.15

Изображение на обложке: Python Software Foundation

Разбираем, откуда взялось это слово — его придумал создатель 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.

В августе 2026 года рынок моделей для генерации кода уперся в новый потолок: Anthropic выпустила Claude Opus 5, OpenAI показала GPT-5.6 Sol в ограниченном доступе, а китайские разработчики предложили открытые веса с результатами уровня флагманов прошлого квартала. Разбираем, что из этого реально купить и как не переплатить.

Что такое SWE-bench и почему он стал главным аргументом

SWE-bench Verified — это набор из 500 реальных задач с GitHub: модели видят описание бага и должны сгенерировать патч, который проходит существующие тесты проекта. Не задачи из LeetCode, а настоящие репозитории с чужой архитектурой и зависимостями. Для оценки кодогенерации это ближе к продакшену, чем большинство альтернатив.

С апреля 2026 года Verified «насытился»: топ выстроился в узкий коридор 95-96%. Поэтому внимание переключилось на SWE-bench Pro — 1865 более сложных задач из 41 репозитория на нескольких языках. Именно здесь видна разница между «хорошо пишет функции» и «разбирается в большом коде».

Claude Opus 5 — лучший баланс качества, цены и доступности: 96,0% на SWE-bench Verified и $5/$25 за миллион токенов.

Claude Mythos 5 лидирует на SWE-bench Pro (80,3%), но доступен лишь ~100 партнёрам программы Glasswing.

GPT-5.6 Sol теоретически первый по Verified (96,2%), но цифра не подтверждена OpenAI, а доступ ограничен ~20 партнёрами.

GLM-5.2 — сильнейший открытый вариант: 62,1% на SWE-bench Pro под лицензией MIT, но сжигает в 2-3 раза больше выходных токенов.

Gemini 3.1 Pro и DeepSeek V4-Pro предлагают ~80% на Verified за $2-3 за миллион токенов — лучшее соотношение цена/качество для массовых задач.

Как устроена верхушка рейтинга

Claude Opus 5 — практичный выбор

Anthropic выпустила Claude Opus 5 24 июля 2026 года по цене старого Opus 4.8: $5 за входящий и $25 за исходящий миллион токенов. На SWE-bench Verified модель набрала 96,0%, а на более сложном SWE-bench Pro — 79,2%. Этого хватает для большинства инженерных задач, а цена остаётся вдвое ниже, чем у Mythos-класса.

Главное ограничение Opus 5 — уступка собственным старшим собратьям на Pro. Если ваша работа связана с большими межрепозиторными изменениями, Mythos 5 и Fable 5 дают 80,0-80,3%, но вы платите $10/$50 за миллион токенов и, в случае Mythos, ещё и проходите отбор в программу Glasswing.

Mythos 5 и Fable 5 — потолок, до которого не дотянуться

В июне Anthropic представила Claude Fable 5 и Claude Mythos 5 — первые модели, преодолевшие 90% на SWE-bench Verified. Обе показывают 95,0% Verified, а Mythos 5 держит лучший результат на Pro — 80,3%. Fable 5 доступен через обычный API любому клиенту, готовому платить Mythos-тариф.

Mythos 5 закрыт примерно для 100 партнёров в рамках программы Glasswing, в основном для исследований в области кибербезопасности и биобезопасности. Это важный нюанс для российских команд: даже если у вас есть бюджет, доступ к модели зависит от одобрения Anthropic, а не только от платёжной карты.

GPT-5.6 Sol — красивое число, которое никто не проверил

OpenAI выпустила GPT-5.6 Sol в ограниченном превью для примерно 20 партнёров, прошедших правительственную проверку. Компания не опубликовала официальных результатов SWE-bench, но сторонние трекеры, включая vals.ai, сообщают 96,2% на Verified.

Пока это не результат, на который можно ориентироваться при выборе инструмента. Цена, если доступ появится, составляет $5/$30 за миллион токенов — чуть дороже Opus 5. Для российских пользователей добавляется и стандартная проблема доступа к API OpenAI, которая уже несколько лет сильнее ограничена, чем у Anthropic или Google.

GLM-5.2 — открытые веса с реальными цифрами

Zhipu AI выпустила GLM-5.2 под лицензией MIT. Модель показывает 62,1% на SWE-bench Pro — выше, чем GPT-5.5 (58,6%), и выше предшественника GLM-5.1 (58,4%). Контекстное окно составляет 1 млн токенов, а обучение проходило на чипах Huawei Ascend, а не NVIDIA.

Цена API — $1,40/$4,40 за миллион токенов, но на практике GLM-5.2 расходует около 43 000 выходных токенов на одну кодинговую задачу против 16 000 у GPT-5.5. Поэтому итоговая стоимость за выполненную задачу ближе к флагманам, чем кажется по прайс-листу. Главное преимущество — возможность скачать веса и развернуть модель у себя. Для команд с требованиями к локальному хранению кода это может перевесить экономию на API.

Gemini 3.1 Pro и DeepSeek V4-Pro — флагманы за разумные деньги

DeepSeek V4-Pro и Gemini 3.1 Pro показывают по 80,6% на SWE-bench Verified — ровно тот уровень, который в апреле считался потолком. DeepSeek стоит $1,74/$3,48 и работает с полностью открытыми весами. Gemini 3.1 Pro стоит $2/$12, имеет окно в 1 млн токенов и 91,7% на LiveCodeBench.

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

Как читать таблицу моделей

Результаты можно свести к трём осям: качество на Verified, качество на Pro и реальная доступность. Если смотреть только на Verified, четыре модели стоят плечом к плечу в диапазоне 95,0-96,2%. Разница появляется, когда добавляешь цену, условия доступа и более жёсткий бенчмарк.

Как ориентироваться в ценах:
Цены указаны за 1 млн входящих / 1 млн исходящих токенов. На практике важнее стоимость за завершённую задачу: одна модель может быть дешевле за токен, но генерировать в 2-3 раза больше текста.

Вот как распределяются роли:

• Claude Opus 5 — универсальный выбор, если нужен API без листов ожидания и цена ниже Mythos.
• Claude Mythos 5 — для команд с доступом к Glasswing, которые решают самые сложные многофайловые задачи.
• GLM-5.2 — для self-hosted сценариев и требований к открытым весам.
• DeepSeek V4-Pro и Gemini 3.1 Pro — для высоконагруженных сценариев, где важна цена за токен.

Методология: почему Verified больше не разделяет лидеров

Авторы обзора используют три сигнала. SWE-bench Verified даёт понять, справляется ли модель с реальными багами. SWE-bench Pro проверяет, как модель работает с более крупными и разнообразными репозиториями. Третий сигнал — это статус доступа и независимость проверки: официальная цифра, сторонний трекер или собственная оценка вендора.

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

Историческая динамика: бенчмарки устаревают быстрее моделей

В марте 2025 года лидером был Claude 3.5 Sonnet с около 49%. В январе 2026 четыре модели одновременно преодолели 78%. В апреле Verified «сел» на плато 76-81%, и внимание перешло на Pro. В июне Mythos-класс впервые превысил 90%, а к концу июля Opus 5 почти догнал его по цене вдвое ниже.

Этот цикл повторяется: бенчмарк насыщается, появляется более сложная версия, цена становится главным разделителем. Для команд это означает, что не нужно гнаться за каждым новым релизом. Достаточно раз в квартал пересматривать соотношение цена/качество и проверять, не появился ли модель с доступным API, который закрывает 80% ваших задач за меньшие деньги.

Что выбрать: чек-лист для команды

Чтобы не утонуть в таблицах, можно пройти по четырём вопросам:

1. Есть ли у вас доступ к API Anthropic, OpenAI или Google? Если нет, открытые веса DeepSeek или GLM-5.2 остаются единственной рабочей опцией.
2. Решаете ли вы локальные баги в одном репозитории или межрепозиторные изменения? Для второго важнее SWE-bench Pro.
3. Какой бюджет на 1 млн исходящих токенов? При высоких объёмах разница между $25 и $3 за миллион ощутима уже на первой неделе.
4. Нужно ли хранить код внутри периметра? В этом случае self-hosted GLM-5.2 или DeepSeek выигрывают у облачных API независимо от бенчмарков.

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

FAQ

Выводы

В июле 2026 года рынок моделей для генерации кода разделился на два лагеря. Первый — закрытые флагманы, которые достигли потолка Verified и теперь конкурируют по цене и доступности. Второй — открытые и полуоткрытые модели, которые отстают по верхним цифрам, но выигрывают у крупных вендоров в контроле над данными и стоимости инфраструктуры.

Для российских команд ключевой вопрос не в том, какая модель «умнее», а в том, какая из них реально доступна, не требует сложных схем оплаты и укладывается в бюджет. В этом контексте Claude Opus 5, DeepSeek V4-Pro и GLM-5.2 выглядят наиболее практичными вариантами — каждый под свои ограничения.

Источник: обзор Best AI Models for Code Generation — July 2026 на Awesome Agents. Данные по бенчмаркам и ценам приведены по состоянию на 29 июля 2026 года.

На конференции Open Source Summit India 2026 в Мумбаи Кроах-Хартман выступил с докладом «Rust and Linux: How the Rust Language is Going to Help Linux Succeed». В нём он признался, что поначалу относился к языку скептически и считал, что всё необходимое уже есть в C. Сейчас он считает иначе: Rust действительно делает программирование интереснее и безопаснее.

• Грег Кроах-Хартман назвал Rust постоянной частью Linux, а не временным экспериментом.
• По его оценке, около 80% уязвимостей ядра за последние 25 лет можно было бы поймать на этапе компиляции Rust.
• Linux получает около 13 CVE в день и почти 9 изменений в час на протяжении десяти лет и более.
• Binder — ключевой механизм IPC Android — уже имеет параллельную реализацию на Rust, а C-версия скоро уйдёт.
• Git и ряд других крупных проектов также движутся в сторону Rust.

От скептицизма к поддержке

Кроах-Хартман рассказал, что несколько лет назад друг советовал ему попробовать Rust, но он отмахнулся: C казался достаточным. Со временем он изменил мнение. «Он был прав. Я должен был сделать это тогда. Rust на самом деле весёлый. Он заставляет программирование быть весёлым», — сказал мейнтейнер.

Главное преимущество языка в ядерной разработке — владение и типизация, которые убирают массу мелких ошибок: непроверенные указатели, забытые разблокировки, неправильная очистка ресурсов. Именно такие баги, по словам Кроах-Хартмана, составляют большинство ежедневных CVE.

Масштаб проблемы

Linux развивается с огромной скоростью. Кроах-Хартман привёл цифры: ядро набирает примерно девять изменений в час уже больше десяти лет, а количество публично раскрываемых уязвимостей держится на уровне около 13 CVE в день. Большая часть из них — не сложные атаки, а простые ошибки в C-коде.

Я видел каждую CVE ядра за последние 25 лет. Думаю, 80% исчезли бы просто потому, что Rust поймал бы их.

Что уже меняется в ядре

Rust постепенно становится обязательным выбором для отдельных подсистем. Кроах-Хартман отметил, что новые драйверы некоторых подсистем будут приниматься только на Rust. Яркий пример — Binder, межпроцессный механизм Android, от которого зависят миллиарды устройств. В ядре уже существуют параллельные реализации Binder на C и Rust, и C-версия «скоро исчезнет».

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

Контекст:
Binder — это механизм межпроцессного взаимодействия (IPC) в Android. Он позволяет приложениям и системным сервисам безопасно обмениваться данными. Переписывание Binder на Rust напрямую влияет на безопасность и стабильность почти всех Android-устройств.

Выводы

Позиция Кроах-Хартмана — ещё один сигнал того, что Rust перешёл из разряда «перспективного языка» в разряд инфраструктурного инструмента. Если оценка в 80% CVE верна, массовый переход на Rust в ядре может существенно снизить количество исправлений безопасности и освободить время мейнтейнеров для сложных логических задач.

Источник: Slashdot.

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

Go остаётся стандартным выбором для большинства микросервисов: быстрая компиляция, простота найма, огромная экосистема.

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

Zig подходит для узких, критичных к производительности участков и для интеграции с существующим C-кодом, но экосистема пока незрелая.

В больших системах работает гибридный подход: Go для скорости разработки, Rust/Zig для горячих путей.

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

Почему именно эти три языка

В 2026 году для нового backend-проекта по-прежнему можно взять Java, C#, Python или Node.js. Но если речь заходит о высоких нагрузках, низкой задержке и контроле над ресурсами, внимание смещается к трём игрокам.

• Rust — язык с владением и заимствованием, дающий безопасность памяти без сборщика мусора.
• Go — язык с простой моделью конкурентности, статической линковкой и минималистичной философией.
• Zig — язык в духе C, но с современной системой сборки, comptime и явным управлением памятью.

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

Rust: максимум производительности, максимум сложности

Сильные стороны

• Безопасность памяти на этапе компиляции — нет use-after-free, data races и большинства утечек.
• Нулевая стоимость абстракций: высокоуровневый код часто компилируется так же эффективно, как ручной C.
• Мощная модель конкурентности поверх tokio или async-std.
• Зрелая экосистема: axum, actix-web, serde, sqlx.

Слабые стороны

• Крутая кривая обучения: borrow checker требует перестройки мышления.
• Долгая компиляция: полная пересборка крупного проекта занимает десятки секунд и минуты.
• Меньше кадров на рынке, чем у Go или Java.
• Итерации медленнее: каждая ошибка компилятора — это время на переделку.

Когда выбирать Rust

Rust логичен, если вы строите инфраструктуру — прокси, базы данных, очереди, edge-сервисы — или если профилирование показывает, что горячий путь съедает CPU и память. Примеры из продакшена: Cloudflare использует Rust на edge, Discord переписал на Rust часть read-path сервисов.

Go: скорость разработки в масштабе

Сильные стороны

• Компиляция за секунды и один статический бинарник для деплоя.
• Встроенные горутины и каналы — простая, но мощная конкурентность.
• Отличная стандартная библиотека и быстрое тестирование через go test.
• Большая база инженеров и проверенные практики в крупных компаниях.

Слабые стороны

• Сборщик мусора может давать всплески задержек, хотя в последних версиях паузы сокращаются.
• Меньше контроля над расположением памяти и размером структур.
• Пиковая пропускная способность ниже, чем у Rust и Zig, на CPU-bound задачах.
• Система типов и обработка ошибок минималистичны — кому-то этого достаточно, кому-то не хватает.

Когда выбирать Go

Go — выбор по умолчанию для команд из 5–50 человек, которым нужно быстро запускать CRUD-сервисы, API-шлюзы и data pipeline. Uber, Google и Яндекс активно используют Go в микросервисах. Если главная метрика — time to market, а не последний процент производительности, Go обычно выигрывает.

Zig: новый игрок с C-душой

Сильные стороны

• Производительность уровня C с более современным синтаксисом и системой сборки.
• comptime — выполнение кода на этапе компиляции для генерации оптимизированных структур.
• Прямое взаимодействие с C без FFI-слоёв.
• Маленькие быстрые бинарники и явное управление памятью.

Слабые стороны

• Экосистема backend-фреймворков и библиотек пока существенно меньше, чем у Rust и Go.
• Сообщество и количество инженеров на рынке ограничены.
• Ручное управление памятью перекладывает ответственность на разработчика.
• Некоторые части языка и стандартной библиотеки всё ещё эволюционируют.

Когда выбирать Zig

Zig хорош, когда нужна C-производительность, но с более удобным инструментарием, или когда приходится интегрироваться с существующим C-кодом. Пример из продакшена: финансовая база данных TigerBeetle написана на Zig. Для универсального backend в 2026 году Zig ещё рано называть mainstream-выбором.

Сравнение в цифрах

Ниже — иллюстративные цифры из оригинального материала, полученные на AWS c7g.2xlarge (Graviton3). Относитесь к ним как к точке отсчёта, а не как к гарантии для вашего сервиса: в реальности большее значение имеют I/O, запросы к базе данных и сетевая задержка.

Бенчмарки:
HTTP throughput — Rust 892K req/s, Go 734K req/s, Zig 812K req/s.
JSON-сериализация — Rust 1,2M/s, Go 890K/s, Zig 1,1M/s.
Память на 10K соединений — Rust 45MB, Go 78MB, Zig 38MB.
Размер бинарника — Rust 8,2MB, Go 12,4MB, Zig 6,1MB.
Время компиляции с нуля — Rust 42s, Go 3,2s, Zig 18s.
P99 latency — Rust 2,1ms, Go 3,8ms, Zig 2,4ms.

Реальные истории миграции

Discord: Go → Rust

Discord переводил read-path сервисы с Go на Rust из-за пауз сборщика мусора, которые проявлялись в хвостовых задержках. По данным компании, throughput вырос в несколько раз, а tail latency снизилась. Ключевой вывод: мигрировать стоит только горячие пути, а не весь сервис целиком.

Uber: Python → Go

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

TigerBeetle: C++ → Zig

TigerBeetle — финансовая база данных, ориентированная на корректность и производительность. Команда выбрала Zig, отказавшись от сложности C++ и сборщика мусора. comptime позволил генерировать специализированные структуры данных под задачу.

Гибридная архитектура

На практике редко выбирают один язык на весь проект. Гораздо чаще используют гибрид:

• API Gateway и CRUD — Go: быстро писать, просто деплоить, легко искать людей.
• Горячие пути — Rust: низкая задержка и контроль над памятью.
• Специализированные компоненты — Zig: парсинг бинарных форматов, криптография, интеграция с C.

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

Что выбрать в 2026 году

Выбор зависит от приоритетов команды и задачи:

• Нужна скорость разработки и лёгкий найм — Go.
• Нужна максимальная производительность и безопасность памяти — Rust.
• Нужна C-производительность с современной сборкой и интеграцией с legacy на C — Zig.
• Команда маленькая и сроки горят — начинайте с Go, профилируйте, мигрируйте горячие пути при необходимости.
• Строите базу данных, прокси или edge — Rust становится очень сильным кандидатом.

FAQ

Выводы

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

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

Источник: Pooya Golchian — Rust vs Go vs Zig: High-Performance Backend Services in 2026.

Это не дословный перевод, а авторский разбор на основе исследования Nicolas Laurent (norswap), дополненный практическими примерами для enterprise-разработки на TypeScript.

Что такое вывод типовых переменных

В TypeScript, когда вы вызываете функцию с дженериком function foo<T>(x: T), компилятор должен понять, чему равен T. Этот процесс называется type variable inference — выводом типовой переменной. Он происходит в две фазы: сначала TypeScript собирает «кандидатов» из типов аргументов и контекста возврата, а затем «сворачивает» список кандидатов в единственный тип.

Звучит просто, но на практике алгоритм полон тонкостей: covariant и contravariant позиции, приоритеты кандидатов, странное поведение пересечений и неочевидные ограничения. Разберём всё по порядку.

TypeScript выводит типовые переменные в две фазы: сбор кандидатов из аргументов и контекста, затем свёртка списка в единственный тип.

Кандидаты делятся на ковариантные (выходные позиции) и контравариантные (входные позиции); контравариантный результат обычно побеждает.

При свёртке TypeScript ищет общий супертип в списке кандидатов, но никогда не выбирает тип, которого нет в списке.

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

В generic-контексте условные типы (extends ? :) не вычисляются, что ломает инференс через Exclude и подобные утилиты.

NoInfer<T> (с TypeScript 5.4+) позволяет блокировать вывод типа из конкретной позиции — полезно для API со значениями по умолчанию.

Фаза 1: сбор кандидатов

Когда TypeScript видит вызов функции с дженериком, он сопоставляет типы аргументов (source types) с типами параметров функции (target types). Каждый раз, когда «прогулка» по типам доходит до «голого» type parameter в target, соответствующий source type записывается как кандидат.

Ковариантные и контравариантные кандидаты

Кандидаты собираются в два списка. Если type parameter находится в позиции аргумента функции или возвращаемого значения — это ковариантный (output position) кандидат. Если type parameter находится в позиции параметра callback-функции — это контравариантный (input position) кандидат.

Условные типы и infer

Когда TypeScript встречает условный тип, кандидаты собираются только из той ветки, которая теоретически может сработать. Но важно: само условие не добавляет кандидатов. Запись T extends Foo НЕ добавляет Foo как кандидат для T.

Это классическая ловушка: кандидаты собираются из одной ветки, а типовая проверка — из другой. TypeScript не вычисляет условные типы на этапе инференса.

Распределение по union

Если source type — union, а target — не «голый» type parameter, TypeScript проходит по каждой ветке union отдельно и собирает кандидатов из всех веток в один список.

Что НЕ учитывается при сборе

• Условие условного типа (только ветки).
• Constraints (<T extends Foo>) — они проверяются позже, на этапе разрешения.
• Дефолтные значения type parameter (<T = unknown>) — используются только если список кандидатов пуст.
• Супертипы source type.

Фаза 2: разрешение кандидатов

После сбора TypeScript сворачивает каждый список в единственный тип. Алгоритм зависит от вариантности и содержимого списка.

Ковариантные кандидаты

1. Если все кандидаты — литералы одного базового типа, они объединяются в union.
2. Иначе ищется кандидат, который является строгим супертипом всех остальных. Если найден — он выбирается.
3. Если нет — выполняется left-reduce: начинаем с первого кандидата, идём по списку, заменяя текущий на супертип, если встречаем его.

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

Контравариантные кандидаты

Для контравариантных кандидатов логика зеркальная: ищется общий подтип, иначе — left-reduce с подтипами. Если оба списка (ковариантный и контравариантный) непусты, контравариантный результат обычно побеждает — за исключением случаев, когда ковариантный результат является подтипом контравариантного.

Приоритеты кандидатов

Каждый кандидат помечается приоритетом. Кандидат с более высоким приоритетом стирает все кандидаты с более низким приоритетом. Основные приоритеты: None (0), NakedTypeVariable (1), MappedTypeConstraint (32), ReturnType (128), LiteralKeyof (256).

Приоритеты MappedTypeConstraint, ReturnType и LiteralKeyof — «комбинационные»: при них результатом становится union или intersection всех кандидатов, а не единственный тип.

Пересечения: загадочное поведение

Одно из самых неинтуитивных мест — вывод через пересечения. Рассмотрим несколько примеров.

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

Вывод в generic-контексте

Когда инференс происходит внутри другой generic-функции, условные типы не могут быть вычислены, потому что type variables ещё не связаны. Это ломает паттерны вроде Exclude, если вызывать их через generic-обёртку.

В типовых enterprise-проектах, где активно используются типовые утилиты для валидации API (например, в проектах на NestJS или с Zod), это ограничение часто приводит к необходимости явно прописывать generic-аргументы или реструктурировать типы.

NoInfer: как управлять выводом

Начиная с TypeScript 5.4, в языке есть встроенный вспомогательный тип NoInfer<T>. Он блокирует сбор кандидатов для T из той позиции, где используется NoInfer<T>.

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

FAQ

Выводы

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

Ключевые практические выводы для разработчиков:

1. Если функция принимает несколько аргументов одного дженерика — убедитесь, что они совместимы, иначе TypeScript выберет первый кандидат и отвергнет остальные.
2. Не полагайтесь на супертипы для инференса: они не попадают в список кандидатов.
3. В generic-контексте условные типы «замораживаются» — проектируйте API с этим ограничением.
4. Используйте NoInfer<T> в библиотечном коде для точного контроля над источниками вывода типов.
5. При странном поведении с пересечениями — перепишите типы явно или добавьте constraint.

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

Источники:

• How TypeScript infers type variables — Nicolas Laurent (norswap)
• How TypeScript distributes unions — Nicolas Laurent (norswap)
• TypeScript Handbook: Generics

Если у вас есть примеры неожиданного поведения TypeScript с дженериками — делитесь в комментариях. Соберём коллекцию «типовых загадок» вместе.

В IPv6 каждый сетевой интерфейс получает link-local адрес из диапазона fe80::/10 (первые 10 бит фиксированы, остальное — адрес интерфейса). Если у машины два интерфейса — например, Ethernet и Wi-Fi — оба будут в одном и том же префиксе. Вопрос: как операционная система понимает, к какому именно интерфейсу адресовать пакет? Ответ — зоны (scopes).

В IPv6 зона интерфейса записывается через %: fe80::4%eth0. Это нужно, чтобы различать link-local адреса на разных сетевых интерфейсах.

В URL зона попадает внутрь квадратных скобок: [fe80::4%eth0]:80. Но символ % в URL — это начало percent-encoding, поэтому парсер ломается.

Решение — экранировать % как %25: [fe80::4%25eth0]:80. Это поведение зафиксировано в RFC 6874.

Проблема затрагивает не только Go, но и nginx, Python requests и браузеры. Поддержка зон в HTTP-клиентах остаётся фрагментарной.

Как зоны работают в IPv6

Зона (или scope ID) — это механизм, позволяющий ядру отличать адреса из пересекающихся диапазонов. Для link-local адресов fe80::/10 он критичен: без него роутинговая таблица не поймёт, через какой интерфейс отправлять трафик.

Формат зоны зависит от ОС. В Linux это имя интерфейса — eth0, wlan0, ens192. В Windows — числовой идентификатор интерфейса. Полный адрес выглядит так:

Квадратные скобки отделяют хост от порта — иначе двоеточия IPv6-адреса спутаются с разделителем порта.

Конфликт зон и URL

Теперь вставим этот адрес в URL. На первый взгляд всё просто:

Но попробуем распарсить его в Go:

Получаем ошибку:

Что произошло? В URL любой символ, не входящий в разрешённый набор, должен быть percent-encoded. Пробел превращается в %20, кириллица — в последовательности вроде %D0%90. Парсер видит %e и пытается декодировать его как hex-последовательность. et — не валидный байт, поэтому URL отклоняется.

Почему Go падает и как это чинить

С точки зрения стандарта Go ведёт себя корректно. RFC 3986 определяет URL-грамматику, а RFC 6874 специально дополняет её для IPv6-зон: символ % перед zone ID должен быть сам закодирован как %25.

Правильный URL выглядит так:

Проверяем в Go:

Вывод:

Go корректно декодирует %25 обратно в % при извлечении хоста. То есть библиотека поддерживает RFC 6874, но требует от вызывающего кода заранее закодировать зону.

RFC 6874: это не баг, а фича

В RFC 6874 формально описан синтаксис IPv6-адресов с зонами в литералах URL. Ключевой фрагмент:

То есть зона записывается не как %eth0, а как %25eth0. Это выглядит ужасно с точки зрения пользовательского опыта, но таково решение стандартизации: совместимость с существующей URL-грамматикой важнее эргономики.

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

И действительно, та же проблема есть и в других инструментах:

• nginx — тикет #623, созданный более десяти лет назад; проблема отсутствия поддержки link-local адресов с зонами до сих пор актуальна.
• Python requests — issue #6808: даже при ручном кодировании % как %25 библиотека некорректно обрабатывает IPv6-зоны в URL, потому что urllib3 декодирует %25 обратно в %.
• Браузеры — draft Schinazi объясняет, почему зоны ломают концепцию origin, и рекомендует использовать mDNS вместо прямого указания link-local адресов в URI.

Что делать разработчику

Если ваше Go-приложение работает с локальными IPv6-адресами — например, подключается к сервисам в Docker-сети, IoT-устройствам или внутренним API через link-local — учитывайте следующее:

1. Перед передачей IPv6-адреса с зоной в url.Parse всегда экранируйте % как %25.
2. Используйте net.JoinHostPort для сборки host:port — он корректно оборачивает IPv6 в скобки, но не кодирует зону. Дополнительное кодирование остаётся на вас.
3. Если адрес приходит от пользователя, валидируйте его до парсинга: зона должна содержать только допустимые символы (имя интерфейса в Linux, числовой ID в Windows).
4. Тестируйте на реальных интерфейсах с разными зонами, чтобы убедиться, что кодирование работает корректно в вашей среде.

На заметку:
Если вы пишете HTTP-клиент для embedded-устройств или промышленных контроллеров, которые общаются через link-local IPv6, ручное кодирование зоны — не костыль, а необходимость. Большинство библиотек не делают этого автоматически.

FAQ

Выводы

IPv6-зоны — редкий, но живучий граничный случай. Если вы пишете сетевой код на Go, который должен работать в гетерогенных средах — Docker, Kubernetes, embedded-системы, промышленные сети — знайте, что fe80::1%eth0 в URL превращается в fe80::1%25eth0. Это не баг парсера, а требование стандарта RFC 6874.

Инкапсулируйте кодирование зоны во вспомогательную функцию и всегда прогоняйте IPv6-адреса через неё перед сборкой URL. Экономия пяти минут сейчас обернётся часом отладки в продакшене, когда сервис внезапно не сможет достучаться до соседнего контейнера по link-local.

Источники:
• Xe Iaso — IPv6 zones in Go URLs
• RFC 6874 — Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
• draft-schinazi-httpbis-link-local-uri-bcp-03 — IPv6 Link-Local URIs

Но пока что искусственный интеллект работает не идеально и может допускать ошибки и уязвимости. Чтобы увеличить надёжность результатов работы ИИ, есть несколько правил. Применять их можно даже без опыта разработки, достаточно использовать те же ИИ-инструменты. Что это за правила, рассказывает руководитель больших данных, высоконагруженных систем и машинного обучения Битрикс24 Александр Сербул.

Когда вайбкодинг — это риск

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

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

Создатель AI-агента Open Claw Питер Штайнбергер говорит: «Вайбкодинг — это навык, который прокачивается». Это значит, что использовать публично и в открытом доступе под нагрузками для критически важных процессов написанный ИИ код можно только при полном понимании того, как он работает.

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

Правило 1: выбираем строго типизированный язык

Программа работает с разными типами данных: числами, строками, логическими значениями.

Некоторые языки программирования более гибкие, например PHP, Python или JavaScript. В них можно менять типы данных по ходу работы программы — это может быть удобно разработчику, но для ИИ повышается вероятность допустить ошибку. Другой вариант — типизированные языки, которые заставляют разработчика сразу указывать, какие типы данных где находятся: TypeScript, Java, Kotlin, Rust. Человеку с таким языком работать труднее, но нейросети их понимают хорошо, и количество ошибок нейросети резко снижается.

Для гибких языков программирования решение тоже есть: можно добавить дополнительные аннотации типов и проверки-валидаторы типов данных. Пример такого валидатора — MyPy для Python.

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

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

Правило 2: включаем базовую проверку с помощью линтеров

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

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

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

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

Правило 3: пишем тесты

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

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

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

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

Правило 4: считаем тестовое покрытие

Следующий шаг, который нужен для надёжного вайбкодинга: общее тестовое покрытие.

Покрытие показывает, какая часть приложения проверяется тестами. Иначе может оказаться так, что тесты есть, но значительную часть кода они не проверяют. Покрытие измеряется в процентах. Например, покрытие в 75% может означать, что тесты проверяют 750 строк из 1000.

Покрытие — это показатель не качества тестов, а того, насколько код вообще проверяется. Даже 100% покрытие не гарантирует отсутствие ошибок, но его отсутствие почти всегда означает, что часть системы вообще не проверяется.

Правило четвёртое: считайте процент тестового покрытия. Минимальный процент — 70-80% программы.

Правило 5: проверяем входные данные, фреймворки и зависимости

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

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

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

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

Проблема в том, что фреймворк — это отдельная сложная программа, и почти к каждому есть сложная объёмная документация. Фреймворк — это сложная внешняя система со своей логикой и обновлениями. Чем больше фреймворков — тем сложнее поддержка и выше риск ошибок. Поэтому если задачу можно решить за 50-100 строк обычного кода, не нужно пытаться сократить их за счёт добавления фреймворка.

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

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

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

Чтобы упростить процесс такого контроля за продуктом, можно использовать специально подготовленные платформы для ИИ-разработки, вроде Битрикс24 VibeCode или Replit. Такие платформы работают по разному: выстраивают ограничения для агентов, другие сразу направляют ИИ для работы с конкретными технологиями. Ещё в них используются техники минимизации рисков: серверы с запущенными приложениями недоступны для атаки снаружи, а данные из приложений фильтруются через слой защищённого официального REST API.

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

Насколько надёжнее становится результат вайбкодинга

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

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

Zig — системный язык с С-подобным синтаксисом и упором на явное управление памятью. 0.16.0 — не LTS, но в терминах API это один из самых ломающих релизов: многие библиотеки придётся переписывать под новый std.Io. Разбираем, что именно изменилось и ради чего.

Что: Zig 0.16.0 — крупный релиз за 8 месяцев. I/O как интерфейс, DI в main, новый ELF-линкер.

Когда: 14 апреля 2026 года.

Где: ziglang.org/download, тарболы под все Tier-1 и Tier-2 платформы.

Масштаб: 244 контрибьютора, 1183 коммита, ломающие изменения в стандартной библиотеке.

Ключевое для кода: pub fn main(init: std.process.Init) — точка входа получает аллокаторы, Io, env и preopens.

Juicy Main — DI на уровне точки входа

«Juicy Main» — это внутреннее название proposal Эндрю Келли: идея в том, что точка входа должна получать «сочный» набор готовых зависимостей, а не создавать их внутри. DI здесь значит, что аллокатор, I/O, env и preopens передаются в main снаружи, а не конструируются каждым приложением заново. Раньше каждая программа на Zig начиналась с одного и того же бойлерплейта: создать GeneralPurposeAllocator, получить arg-итератор через std.process.argsAlloc, отдельно дёрнуть std.process.getEnvMap. В 0.16 всё это подаётся параметром в main:

std.process.Init — структура с пре-инициализированными значениями: процессная arena с автоматической очисткой при выходе, дефолтный GPA (General Purpose Allocator) с leak-checker в debug, подходящая под таргет реализация Io, карта переменных окружения, preopens (наследие WASI-модели: файловые дескрипторы, переданные родительским процессом как capability). Это классический DI: main собирает зависимости, библиотеки внутри принимают Allocator и Io через параметры.

Подпись main теперь может быть одной из трёх:

• Без параметров — нельзя получить CLI-аргументы и окружение. Подходит для чистых вычислительных утилит.
• process.Init.Minimal — только сырые argv и environ, без аллокаторов и Io.
• process.Init — полный набор: аллокаторы, Io, env-map, preopens.

I/O как интерфейс — async без раскраски функций

Второе крупное изменение: std.Io стал абстрактным интерфейсом, а не набором конкретных функций. Реализации:

• Io.Threaded — текущая дефолтная, работает поверх ОС-потоков, поддерживает cancelation.
• Io.Evented — экспериментальная, на userspace-стеках с work-stealing (M:N, «зелёные потоки»).
• Io.Uring — proof-of-concept на Linux io_uring, без сети и обработки ошибок.
• Io.Kqueue — proof-of-concept на macOS/BSD.
• Io.Dispatch — поверх Grand Central Dispatch (macOS).
• Io.failing — возвращает ошибку на любую операцию, для тестов.

Философия — ровно та же, что у Allocator: функции принимают интерфейс, а не привязываются к конкретной реализации. Это даёт Zig async без раскраски функций — то, на чём подрывались Rust, JavaScript и C#. Асинхронная функция ничем не отличается по сигнатуре от синхронной — меняется только переданный Io.

На уровне API появились новые абстракции:

• Future(T) — таск, создаётся через io.async, ожидается через future.await. Может быть реализован синхронно, если Io не умеет concurrency.
• Group — набор независимых тасков с общим awaiting и cancelation.
• Queue(T) — многопроизводительная/многопотребительная очередь с блокировкой.
• Select и Batch — выполнение нескольких операций одновременно с ожиданием первого завершения.
• Clock, Duration, Timestamp, Timeout — type-safe единицы времени.

Есть цена: весь код стандартной библиотеки, который делал I/O, пришлось переписать под интерфейс. Старые типы GenericReader, AnyReader, FixedBufferStream удалены — в крейтах, обновлявшихся из 0.15, почти гарантированно сломается чтение/запись.

Environment перестаёт быть глобальным

В C setenv в многопоточной программе — UB: глобальная environ читается без блокировок. Zig до 0.16 наследовал эту проблему через std.os.environ, который ещё и нельзя было заполнить без линковки libc.

Теперь окружение доступно только из main через init.environ_map. Если библиотеке нужен env — она принимает его параметром, как аллокатор. Это ломает код, дёргавший std.process.getEnvVarOwned из произвольного места, но убирает целый класс thread-safety-багов.

Параллельно переименованы функции в std.mem: indexOf → find, добавлены cut / cutScalar для разбиения слайсов по первому/последнему вхождению.

Новый ELF-линкер — без LLVM для Linux

В 0.16 появился собственный ELF-линкер — включается флагом -fnew-linker, а при -fincremental на self-hosted ELF-сборке используется автоматически. Он пока не feature-complete (например, не пишет DWARF), поэтому по умолчанию release-сборки идут через LLVM + LLD. Выгода — инкрементальная линковка (194мс → 65мс на тестовом проекте) и меньше зависимостей для debug-сборок.

Плюс доработки под Windows: сетевой стек теперь работает без ws2_32.dll (напрямую через NtDll), завершена миграция с Win32 API на NtDll для остальных системных вызовов, появился inter-process progress reporting для параллельных сборок.

Что ещё важного в 0.16

• x86-бэкенд компилятора стал самодостаточным — дебажные сборки на x86_64 собираются без LLVM и идут значительно быстрее. aarch64-бэкенд ещё work-in-progress: в 0.16 он падает на behavior-тестах.
• Инкрементальная компиляция переработана, меньше false-rebuilds, стабильнее на больших проектах.
• Fuzzer (zig test --fuzz) получил multi-process режим, infinite mode и crash dumps с AST-дампом.
• Build-система: локальный override пакетов, --error-style и --multiline-errors, таймауты юнит-тестов, temporary files API.
• Крипто: добавлены AES-SIV, AES-GCM-SIV, Ascon-AEAD, Ascon-Hash, Ascon-CHash.
• Heap: ArenaAllocator стал thread-safe и lock-free, обёртка ThreadSafeAllocator удалена.
• Тулчейн: LLVM 21 (с отключённой loop vectorization из-за регрессии), musl 1.2.5, glibc 2.43, Linux 6.19 headers, macOS 26.4 headers, MinGW-w64, FreeBSD 15.0 libc.

Как мигрировать с 0.15

1. Ставьте 0.16 из тарбола или zigup параллельно со старой версией. Одновременная установка нескольких версий — штатный сценарий.
2. Соберите проект и смотрите на ошибки. Чаще всего сломается: вызовы std.os.environ, std.process.getEnvVarOwned, использование GenericReader/AnyReader, FixedBufferStream.
3. Перепишите main на новую сигнатуру. Даже если просто хотите старое поведение — объявите pub fn main(init: std.process.Init.Minimal), так вы получите хотя бы args/environ.
4. Если нужен Io в библиотеке, но вы не контролируете main — временно используйте Io.Threaded в режиме single-threaded и берите threaded.io(). Это не рекомендуемый путь, но он работает как page_allocator для аллокатора.
5. Проверьте зависимости через zig fetch. Старые версии пакетов под 0.15 скорее всего не соберутся, ждите апдейтов или фиксируйте у себя fork.
6. Пересоберите и прогоните тесты на std.testing.io — это Io-бэкенд для тестов, аналог std.testing.allocator.

Что дальше

После 0.16 любая Zig-функция, принимающая Io, автоматически работает и в sync-, и в async-режиме без смены сигнатуры. В Rust это требует async fn + executor-specific runtime — в Zig теперь параметр.

0.16.0 — это не про новые фичи, а про фундамент: зафиксированы I/O-интерфейс и контракт точки входа. Если у вас есть Zig-код на 0.15 — закладывайте день на миграцию по чек-листу выше. Если смотрели на Zig со стороны и интересует async без раскраски — ставьте 0.16 и загляните в исходники stdlib: это самая чистая реализация «нераскрашенного» async среди мейнстримных языков на 2026 год.

Полные release notes — на ziglang.org. Обсуждение и отчёты о багах — в GitHub.

Исследователь Доминик Цёлек (ciolek.dev) обнаружил два бага в цепочке компиляции Go и сообщил о них команде безопасности. Та ответила на первый отчёт через 3 минуты, на второй — через 4. Что показательно: git blame указал на самого исследователя как автора кода, в котором обнаружился баг, — он же сам написал его три года назад.

• CVE-2026-27143: переполнение int8-счётчика в цикле → prove pass удалял bounds check → инъекция инструкций
• CVE-2026-27144: no-op-конверсия *p = T(*q) вместо *p = *q → компилятор пропускал careful copy path при пересечении памяти → memory corruption
• Общая причина: «counterfeit certainty» — оптимизатор повышал «вероятно безопасно» до «доказано безопасно» слишком рано
• Memory safety — свойство всей цепочки инструментов (frontend, optimizer, lowering, runtime, codegen), а не только языка
• «Every optimization is a security claim» — каждая оптимизация компилятора является утверждением о безопасности

Баг 1 (CVE-2026-27143): переполнение счётчика цикла убирает bounds check

Первый баг связан с фазой prove pass — проходом компилятора, который статически доказывает инварианты и на основании этого удаляет избыточные проверки. Идея хорошая: зачем проверять границы массива, если компилятор «знает», что индекс всегда находится в допустимом диапазоне?

Рассмотрим цикл с переменной типа int8, шагом 10 и лимитом 120:

На первый взгляд код безопасен: i не превышает 120, массив размером 200 байт — никакого выхода за границы. Prove pass рассуждал именно так: раз условие цикла гарантирует i ∈ [0, 120], bounds check можно удалить.

Но int8 хранит значения от -128 до 127. После 120 следующий шаг — 130, что переполняет тип и оборачивается в -126. Условие i < 120 снова становится истинным, цикл продолжается, но уже с отрицательным индексом. Bounds check, который мог бы это поймать, компилятор уже выбросил — ведь он «доказал» безопасность. В результате происходит запись за пределы массива, что открывает возможность для control-flow hijack и инъекции инструкций.

Prove pass повысил «индекс вероятно в пределах диапазона» до «индекс доказано в пределах диапазона», не учтя возможность целочисленного переполнения малых типов.

Баг 2 (CVE-2026-27144): no-op-конверсия и пересечение памяти

Второй баг тоньше. Go использует «careful copy path» — специальный путь копирования данных при работе с пересекающимися областями памяти (overlapping memory). Без него можно записать в destination данные, которые уже были перезаписаны в процессе копирования из source.

Проблема возникала при казалось бы безобидной конструкции — no-op-конверсии типа при присваивании через указатель:

Конверсия T(*q) здесь не делает ничего содержательного — типы совпадают. Компилятор распознал её как no-op и оптимизировал… но при этом забыл переключиться на careful copy path. Если области памяти p и q пересекаются — данные копируются некорректно, что приводит к повреждению памяти.

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

Общая причина: «counterfeit certainty»

Оба бага объединяет одна концептуальная проблема: компилятор принимал «вероятно безопасно» за «доказано безопасно» и на этом основании удалял защитные механизмы. Цёлек называет это counterfeit certainty — поддельная уверенность.

В первом случае prove pass «доказал» безопасность индекса, не учтя переполнение малых целых типов. Во втором случае оптимизатор «знал», что конверсия — no-op, и сделал из этого вывод, что careful copy path не нужен. В обоих случаях рассуждение было формально правильным, но неполным: не были рассмотрены все возможные состояния программы.

Every optimization is a security claim. — Каждая оптимизация компилятора является утверждением о безопасности.

Когда компилятор удаляет bounds check — он утверждает, что выход за границы невозможен. Когда он пропускает careful copy path — он утверждает, что пересечения памяти нет. Ошибка в этих утверждениях напрямую превращается в уязвимость безопасности.

Memory safety — свойство всей цепочки инструментов

Принято считать, что memory-safe языки (Go, Rust, Java, C#) гарантируют отсутствие memory corruption по определению. Это правда — в рамках спецификации языка. Но между спецификацией и работающей программой стоит компилятор.

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

• Frontend (парсинг, type checking) — проверяет синтаксис и типы
• Optimizer (prove pass, escape analysis) — доказывает инварианты и устраняет лишние проверки
• Lowering — преобразует высокоуровневые операции в машинно-зависимые
• Runtime (garbage collector, goroutine scheduler) — управляет памятью во время выполнения
• Codegen — генерирует итоговый машинный код

CVE-2026-27143 затронул фазу optimizer, CVE-2026-27144 — фазу lowering. Обе уязвимости существовали несмотря на то, что исходный код был написан на «memory-safe» языке. Memory safety — это свойство, которое нужно обеспечивать на каждом уровне стека, не только на уровне языка.

Go security team: ответ за 3–4 минуты

Исследователь отправил отчёты об обоих багах в Go security team. Первый ответ пришёл через 3 минуты, второй — через 4. Оба бага были исправлены в Go 1.26.1. Сам Цёлек отметил, что процесс взаимодействия с командой был образцовым: быстрая реакция, прозрачная коммуникация и оперативный выпуск патча.

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

Выводы

История с CVE-2026-27143 и CVE-2026-27144 показывает: использование memory-safe языка — необходимое, но недостаточное условие для безопасности программы. Компилятор — не чёрный ящик с гарантиями, а сложная система с собственными инвариантами, которые могут нарушаться.

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

Практический вывод прост: обновляйтесь. Следите за golang-announce, обновляйтесь до новых версий Go сразу после выхода патчей безопасности, и помните, что «написано на Go» ≠ «memory-safe по определению».

Вы знаете, что a + b * c + d вычисляется как a + (b * c) + d. Но как объяснить это машине? Как закодировать правила приоритета операторов так точно, чтобы парсер сам правильно строил дерево разбора?

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

— AST — основная структура данных: оператор над операндами, вычисление снизу вверх.

— Приоритет операторов определяет наклон дерева: выше приоритет — глубже в дерево.

— При падении приоритета алгоритм поднимается по «хребту» дерева — это и есть суть Pratt parsing.

— Левая и правая ассоциативность задаются через LBP и RBP (left/right binding power).

— Полный парсер с поддержкой всех операторов — около 10 строк на Python.

Абстрактное синтаксическое дерево

Наиболее распространённое решение для разбора выражений — абстрактное синтаксическое дерево (AST, Abstract Syntax Tree). В AST каждый оператор стоит над своими операндами. Вычисление идёт снизу вверх: сначала обрабатываются дочерние узлы, затем операция над ними.

Для выражения a + b * c + d правильное AST выглядит так:

Узел * находится глубже, чем +, — это и отражает более высокий приоритет умножения. При вычислении сначала перемножаются b * c, результат складывается с a, затем прибавляется d.

Как приоритет влияет на форму дерева

Здесь кроется главная интуиция Pratt parsing. Приоритет операторов напрямую определяет, в какую сторону «наклоняется» дерево:

• Убывающий приоритет (например, * + ==) — дерево наклонено влево: операторы с большим приоритетом оказываются глубже.
• Возрастающий приоритет (например, == + *) — дерево наклонено вправо.
• Равный приоритет — по соглашению левая ассоциативность, дерево наклоняется влево.

Рассмотрим промежуточное состояние разбора. Пусть мы уже построили дерево I для выражения (a > b + c * d) — это правонаклонное дерево: > наверху, * в самом низу.

Теперь встречаем следующий оператор. Куда вставить новый узел? Зависит от приоритета:

• [I] * e — приоритет * не меньше приоритета * в дереве, вставляем в самый глубокий узел.
• [I] + e — приоритет + ниже *, но выше >, поднимаемся по хребту выше узла *.
• [I] == e — приоритет == ниже всего дерева, всё дерево I становится левым потомком.

Ключевое наблюдение: когда встречается оператор с меньшим приоритетом, мы поднимаемся по правому хребту дерева, собирая узлы с более высоким приоритетом. Это и есть Pratt parsing — алгоритм, который реализует именно этот подъём по хребту.

От интуиции к коду

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

Здесь leaf() читает следующий терминал (число или переменную), peek() смотрит на текущий токен без продвижения, advance() читает и сдвигает позицию.

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

Это уже работает для правоассоциативных операторов. Но у нас if — разобрали один оператор и вышли. Для левоассоциативных нужен цикл:

Полный Pratt parser

Замена if на while — это и есть процедура подъёма по хребту дерева. Цикл продолжается, пока следующий оператор имеет достаточно высокий приоритет, чтобы «захватить» левую часть. Как только приоритет падает — выходим, и текущее поддерево передаётся вверх по стеку вызовов.

Правая ассоциативность через binding power

До сих пор у нас одно число приоритета на оператор. Но для управления ассоциативностью нужно различать, насколько «сильно» оператор притягивает операнды слева и справа. Вводятся два понятия:

• LBP (left binding power) — сила притяжения левого операнда.
• RBP (right binding power) — сила притяжения правого операнда.

Правила ассоциативности через binding power:

• Левоассоциативные операторы (+, *): LBP == RBP. Правый рекурсивный вызов получает тот же приоритет — следующий оператор с таким же приоритетом не захватывается, строится левое дерево.
• Правоассоциативные операторы (**, =): RBP = LBP − 1. Правый рекурсивный вызов получает чуть меньший приоритет — следующий оператор с таким же приоритетом захватывается, строится правое дерево.

Это финальная версия Pratt parser. Всего 8 строк кода — и корректный разбор всех операторов с любым приоритетом и ассоциативностью.

Итог

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

Ключевые детали реализации:

• while вместо if — реализует подъём по хребту для левоассоциативных операторов.
• Передача приоритета в рекурсию — ограничивает, какие операторы «захватываются» на следующем уровне.
• LBP / RBP — контролируют ассоциативность через разницу в единицу.

Понимание этой геометрии делает Pratt parsing прозрачным: каждая строка кода отражает конкретное геометрическое действие с деревом, а не магию таблиц приоритетов.

В субботу, 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.

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

Нет. WebAssembly победил — просто не так, как все ожидали.

Главное: WebAssembly не заменил JavaScript в браузере — и не должен был. Его главная роль — мост между языками. Figma, Godot, Squoosh, Cloudflare Workers, Zellij — все они используют Wasm, но вы этого не замечаете — и это нормально.

Где Wasm уже работает

• Figma — конвертирует C++ кодовую базу в браузерное приложение + запускает пользовательские плагины в песочнице через QuickJS+Wasm
• Godot — сборка игр для веба
• Squoosh.app — использует C/C++ библиотеки сжатия изображений прямо в браузере
• Stackblitz — веб-контейнеры на Wasm
• Ruffle — эмулятор Flash в браузере
• Cloudflare Workers — запуск недоверенного кода через V8 isolates
• Zellij, Envoy, Lapce — экосистема плагинов на Wasm

Что такое WebAssembly на самом деле

WebAssembly — это язык. Более точно — байткод, похожий на JVM bytecode, но с меньшим API, более строгими гарантиями безопасности и без мнений о том, как управлять памятью.

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

Цель компиляции, не язык разработки

В Wasm компилируются десятки языков: Rust, C, Zig, Go, Kotlin, Java, C#. Даже интерпретируемые языки работают — их рантаймы компилируются в Wasm (Python через Pyodide, PHP, Ruby). Есть и языки, которые компилируются исключительно в Wasm: AssemblyScript, Grain, MoonBit.

Ваш браузер уже умеет запускать Wasm. Но есть и автономные рантаймы: Wasmtime, WasmEdge, Wasmer — аналоги JVM, но для Wasm.

Безопасность — главное преимущество

Всё внешнее взаимодействие — явные импорты от хоста. Это даёт изоляцию на уровне процесса внутри одного процесса. Cloudflare запускает недоверенный код через V8 isolates — старт в 100 раз быстрее, чем отдельный процесс. Fermyon заявляет о старте менее чем за миллисекунду.

Мост между языками — главная роль

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

Ограничения

• В браузере Wasm работает через тот же пайплайн, что и JS — потолок на производительность
• Пересечение границы хост-программы стоит дорого — пост-мортем Zaplib показал, что постепенная миграция может не дать выигрыша
• Нет нативного строкового типа — системные API приходится пересоздавать, WASI помогает частично
• Самые компактные бинарники даёт Zig, самые тяжёлые без оптимизации — Rust

Почему кажется, что ничего не произошло

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

Фреймворки Blazor (.NET) и Leptos (Rust) позволяют писать веб-приложения без прямого контакта с JS. Стандартизация идёт: WasmGC уже в Chrome, Firefox и Safari; Component Model развивается в Bytecode Alliance.

FAQ

WebAssembly быстрее JavaScript?

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

Wasm заменит JavaScript?

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

С чего начать?

Попробуйте watlings — упражнения по ручному написанию WAT в стиле rustlings. А для практического применения — wasm-pack для Rust.

Источник: What Happened To WebAssembly — EmNudge

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

Морфология вместо порядка — как типы вместо позиций

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

Чем это похоже на код? Как минимум тем, что поведение объекта определяется его типом и свойствами, а не тем, в какой строке он стоит.

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

Это тренирует рабочую память и способность декомпозировать структуру.

Санскрит как формальная грамматика

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

Там есть рекурсия. Есть правила, которые применяются к другим правилам. Есть даже строгая формальная логика вывода словоформ.

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

А практический смысл есть?

Есть побочный бонус: примерно 60% английской лексики и до 90% научной терминологии имеют латинские и греческие корни. Это не делает вас лучшим разработчиком автоматически, но улучшает понимание терминов и документации.

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

Подборка в этом материале опирается на 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, ведь через какое-то количество лет код не будут писать руками, только проектировать.

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

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

В 2025 году преподаватели Пензенского университетаперевелисинтаксис JavaScript на кириллицу и уже обучают студентов писать код без единой латинской буквы.

В статье рассказываем, как работали русскоязычные ЯП, почему они появились именно в СССР, какие задачи решали и что с ними стало после распада Союза — некоторые идеи актуальны до сих пор.

1. Рапира

Язык придумали в 1987 году в Институте систем информатики им. А.П. Ершова в Новосибирске. Название расшифровывается как «Русский Алгоритмический Процедурный Императивный Расширяемый Адаптируемый».

Рапиру создавали для обучения программированию школьников и студентов. Синтаксис использовал русские ключевые слова:

• проц вместо function,
• цел вместо int,
• вывод вместо print.

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

Рапиру преподавали в советских школах и вузах с конца 1980-х до середины 1990-х годов. После распада СССР язык исчез из учебных программ — его вытеснили Pascal и Basic.

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

2. ПЭВМ Искра-1256

Безымянный язык программирования для компьютера «Искра-1256» появился в конце 1980-х годов. Машину выпускал Ленинградский завод имени Светланы для автоматизации офисной работы — учёта, делопроизводства, составления отчётов.

Разработчики встроили интерпретатор языка в ПЗУ компьютера, чтобы пользователи писали программы без установки дополнительного софта. Целевая аудитория — бухгалтеры, секретари, экономисты без технического образования.

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

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

«Искра-1256» выпускалась ограниченной серией и поставлялась в государственные учреждения. После 1991 года производство прекратилось. Компьютеры заменили на машины с DOS и Windows. Язык исчез вместе с платформой — портирование на другие системы не проводилось.

Сегодня информация о языке сохранилась в технических описаниях «Искры-1256» и воспоминаниях пользователей.

3. Эль-76

Это разработка конца 1970-х годов родом из Института точной механики и вычислительной техники в Москве. Язык придумали специально для суперкомпьютера «Эльбрус-1».

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

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

После распада Союза производство суперкомпьютеров прекратилось, Эль-76 перестали использовать. Сегодня процессоры «Эльбрус» выпускаются для государственных нужд, но работают с современными языками — C, C++, Fortran.

4. КуМир

КуМир (Комплект Учебных МИРов) разработан в НИИСИ РАН в начале 2000-х годов. Его создали для обучения школьников. В отличие от Рапиры и Эль-76, КуМир пережил свою эпоху.

Синтаксис использует русские ключевые слова:

• алг (алгоритм),
• нач (начало),
• кон (конец),
• цел (целое),
• нц (начало цикла).

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

Язык входит в школьную программу по информатике. Задания ЕГЭ публикуют на псевдокоде, который копирует синтаксис КуМира. Ученики решают задачи в среде КуМир, готовятся к экзамену.

Практическое применение ограничено образованием. КуМир не используют в коммерческой разработке, библиотек для веб-разработки или работы с базами данных. После школы ученики переходят на Python, JavaScript или C++.

5. АЛМИР-65

Название расшифровывается как «Алгоритмический язык для машины инженерных расчётов». Язык работал на компьютерах серии МИР — настольных машинах размером с письменный стол.

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

Язык обрабатывал числа с плавающей точкой, работал с массивами и матрицами. Компьютер МИР выводил результаты на экран сразу после ввода команды — диалоговый режим работы в 1965 году встречался редко.

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

6. Аналитик

Язык создали в 1968 году в Институте кибернетики АН УССР. Разработка продолжила линию языка АЛМИР-65. Первую версию Аналитика запустили на компьютерах МИР-2, созданных в том же институте.

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

В 1974 году вышла версия Аналитик-74 для компьютеров МИР-3. Язык применяли в научных расчётах — физике, математике, механике. Исследователи писали программы для вывода формул, дифференцирования, интегрирования, работы с матрицами и полиномами.

После распада СССР разработка не прекратилась, на его базе создали систему компьютерной алгебры Аналитик-2010. Современная версия работает на актуальных операционных системах и сохраняет идеи оригинального языка.

Практическое применение Аналитика ограничено академической средой.

7. Робик

Язык используют в российских школах с 2000-х годов. Синтаксис построен на кириллических ключевых словах.

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

Робик содержит три управляющие конструкции:

• цикл со счётчиком (нц 10 раз … кц),
• цикл с условием (нц пока свободно снизу … кц),
• условный оператор (если закрашена то … иначе … все).

Переменных, функций и типов данных нет — только последовательность команд.

Пример программы, которая закрашивает квадрат 3×3:

Робик входит в задания по информатике ОГЭ и ЕГЭ. Практическое применение ограничено образованием.

8. ДРАКОН

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

Язык использовали в НПО «Энергия» при разработке «Бурана». Сейчас существуют редакторы ДРАКОН-схем с генерацией кода на Python, C++, Java. Программист рисует схему, нажимает кнопку — получает исходники.

Практическое применение:

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

ДРАКОН-схема заменяет десятки страниц технического описания.

9. ЯМБ

Язык Машин Бухгалтерских разработали в конце 1970-х годов. Название связывают с инициалами Марины Борисовны Ярошевской — руководителя группы разработки из СКБ ВТ «Искра».

ЯМБ использовал русскоязычный синтаксис — команды записывали кириллицей. Программисты писали на нём приложения для учёта материальных ценностей, начисления зарплаты, формирования отчётности.

Язык адаптировали под специфику бухгалтерских задач:

• работу с таблицами,
• суммирование колонок,
• форматирование документов.

Практическое применение ограничивалось советскими организациями. После перехода бухгалтерий на программы типа «1С» про ЯМБ забыли.

10. 1С:Предприятие

Платформу «1С:Предприятие» выпустили в 1991 году. Фирма «1С» создала её для автоматизации бухгалтерского учёта в российских компаниях.

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

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

Язык запросов встроен в платформу — разработчик получает данные через конструкции типа ВЫБРАТЬ Номенклатура, Количество ИЗ Документ.Товары.

Рынок 1С существует параллельно классической разработке. Вакансий публикуют больше, чем по Rust или Swift. Специалисты пишут типовые конфигурации, дорабатывают учётные системы под требования заказчиков, интегрируют 1С с сайтами и CRM.

Выводы

Большинство языков исчезли вместе с платформами, для которых создавались. Рапира, Эль-76, АЛМИР-65, ЯМБ остались в архивах и воспоминаниях — их вытеснили международные стандарты.

Три проекта выжили:

• КуМир стал основой для подготовки к ЕГЭ.
• ДРАКОН занял нишу в документировании сложных систем.
• 1С превратилась в отдельную индустрию с десятками тысяч вакансий.

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

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

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

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

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

Этот вопрос также помогает прояснить разницу между языками, которые на первый взгляд сильно пересекаются по возможностям. Судя по количеству вопросов статей вроде “Go или Rust” и “Rust или Zig”, люди тоже не понимают, что происходит. Сложно запомнить, что язык X лучше для веб-сервисов, потому что у него есть фичи a, b и c, а у языка Y только a и b. Гораздо проще запомнить, что язык X лучше для веб-сервисов, потому что язык Y создан человеком, который ненавидит интернет (условно) и считает, что нужно вырубить всю сеть.

Я собрал здесь мнение о трёх языках, с которыми недавно экспериментировал: Go, Rust и Zig. Я попытался превратить свой опыт с каждым языком в общий вывод о том, что этот язык представляет из себя и насколько хорошо реализует свои ценности. Да, это упрощение, но кристаллизация упрощённых предубеждений — именно то, что я здесь и делаю.

Go: минимализм для корпораций

Go выделяется своим минимализмом. Его называют “современным C”. Go не похож на C, потому что у него есть сборщик мусора и полноценная среда выполнения, но он похож на C тем, что весь язык помещается в голове.

Весь язык помещается в голове, потому что в Go очень мало возможностей. Долгое время Go был известен отсутствием дженериков. Их наконец добавили в Go 1.18, но только после 12 лет, в течение которых люди умоляли это сделать. Другие возможности, обычные для современных языков — например, размеченные объединения (tagged unions) или синтаксический сахар для обработки ошибок — в Go так и не появились.

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

Ещё один пример минимализма Go — тип slice. И в Rust, и в Zig есть slice, но это толстые указатели (fat pointers) и только они. В Go slice — это толстый указатель на непрерывную последовательность в памяти, но slice также может расти. То есть он объединяет функциональность типа Vec<T> из Rust и ArrayList из Zig. Кроме того, поскольку Go управляет памятью за вас, он сам решает, где будет жить память вашего slice — в стеке или куче. В Rust или Zig вам придётся сильно задуматься, где живёт ваша память.

История происхождения Go, насколько я понимаю, примерно такая: Роб Пайк устал ждать компиляции проектов на C++ и устал от ошибок, которые другие программисты Google делали в тех же проектах на C++. Поэтому Go прост там, где C++ перегружен. Это язык для рядовых программистов, спроектированный быть достаточным для 90% задач и при этом простым для понимания, даже (или особенно) при написании конкурентного кода.

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

Rust: максимализм ради безопасности

Если Go минималистичен, то Rust максималистичен. Популярный слоган Rust — “абстракции с нулевой стоимостью” (zero-cost abstractions). Я бы дополнил: “абстракции с нулевой стоимостью, и их очень много!”

У Rust репутация сложного для изучения языка. Я согласен с Джейми Брэндоном, который пишет, что Rust делает сложным не система времён жизни (lifetimes), а количество концепций, запиханных в язык. Я не первый, кто приводит в пример этот конкретный комментарий на GitHub, но он идеально показывает концептуальную плотность Rust:

Тип Pin<&LocalType> реализует Deref, но не реализует DerefMut. Типы Pin и & помечены #[fundamental], так что возможна реализация DerefMut для Pin<&LocalType>>. Вы можете использовать LocalType == SomeLocalStruct или LocalType == dyn LocalTrait, и можете привести Pin> к Pin>. (Действительно, два слоя Pin!!) Это позволяет создать пару “умных указателей, реализующих CoerceUnsized, но имеющих странное поведение” на стабильной версии (Pin<&SomeLocalStruct> и Pin<&dyn LocalTrait> становятся умными указателями со «странным поведением», и они уже реализуют CoerceUnsized).

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

Цель производительности понятна сама по себе. Что означает “безопасность” — менее очевидно, по крайней мере для меня (хотя, может быть, я просто слишком долго писал на Python). “Безопасность” означает “безопасность памяти” — идею, что вы не должны иметь возможность разыменовать невалидный указатель или сделать двойное освобождение памяти. Но это также означает больше. “Безопасная” программа избегает всего неопределённого поведения (undefined behavior, или UB).

Что такое ужасное UB? Лучший способ понять это — вспомнить, что для любой работающей программы ЕСТЬ СУДЬБЫ ХУЖЕ СМЕРТИ. Если в программе что-то идёт не так, немедленное завершение — это прекрасно! Потому что альтернатива, если ошибка не поймана — ваша программа переходит в сумеречную зону непредсказуемости, где её поведение может определяться тем, какой поток выиграет следующую гонку данных, или тем, какой мусор оказался по конкретному адресу памяти. Теперь у вас хайзенбаги и дыры в безопасности. Очень плохо.

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

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

Zig: свобода и контроль

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

Не знаю, правда ли это, но мне нравится думать о Zig как о реакции одновременно на Go и Rust. Go прост, потому что скрывает детали того, как работает компьютер. Rust безопасен, потому что заставляет прыгать через свои обручи. Zig освободит вас! В Zig вы контролируете вселенную, и никто не может указывать, что делать.

И в Go, и в Rust выделить объект в куче просто — достаточно вернуть указатель на структуру из функции. Выделение памяти неявное. В Zig вы выделяете каждый байт сами, явно. (В Zig ручное управление памятью.) У вас больше контроля, чем даже в C: чтобы выделить байты, нужно вызвать alloc() на конкретном виде аллокатора, то есть вы должны выбрать лучшую реализацию аллокатора для вашего случая.

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

Неопределённое поведение всё ещё важно в Zig

Zig называет его “нелегальным поведением” (illegal behavior). Он пытается обнаружить его во время выполнения и обрушить программу, когда это происходит. Для тех, кого беспокоит стоимость таких проверок по производительности, Zig предлагает четыре разных “режима релиза” на выбор при сборке программы. В некоторых проверки отключены. Идея в том, что вы можете запустить программу достаточно раз в проверяемых режимах, чтобы иметь разумную уверенность: в непроверяемой сборке нелегального поведения не будет. Это кажется мне очень прагматичным дизайном.

Ещё одно различие между Zig и двумя другими языками — отношение Zig к объектно-ориентированному программированию. ООП давно не в моде, и Go, и Rust избегают наследования классов. Но в Go и Rust достаточно поддержки других идиом ООП, чтобы вы могли построить программу как граф взаимодействующих объектов, если захотите. В Zig есть методы, но нет приватных полей структур и нет языковой возможности для полиморфизма во время выполнения (динамической диспетчеризации), хотя std.mem.Allocator просто умирает стать интерфейсом. Насколько я могу судить, эти исключения намеренны; Zig — язык для дата-ориентированного дизайна (data-oriented design).

Ещё одна вещь, которую я хочу сказать, потому что она открыла мне глаза: может показаться безумием создавать язык программирования с ручным управлением памятью в 2025 году, особенно когда Rust показал, что сборка мусора не нужна и компилятор может всё сделать за вас. Но это дизайнерский выбор, тесно связанный с выбором исключить возможности ООП. В Go, Rust и множестве других языков вы обычно выделяете маленькие кусочки памяти за раз для каждого объекта в графе объектов. У вашей программы тысячи маленьких скрытых malloc() и free(), и, следовательно, тысячи разных времён жизни. Это RAII. В Zig может показаться, что ручное управление памятью потребует много утомительной, подверженной ошибкам работы, но это так только если вы настаиваете на привязке выделений памяти к каждому маленькому объекту. Вместо этого вы можете просто выделять и освобождать большие куски памяти в определённых разумных точках программы (например, в начале каждой итерации цикла событий) и использовать эту память для данных, с которыми работаете. Именно этот подход и поощряет Zig.

Многие люди не понимают, зачем нужен Zig, если уже есть Rust. Дело не только в том, что Zig пытается быть проще. Думаю, разница более важная. Zig хочет, чтобы вы вырезали ещё больше объектно-ориентированного мышления из своего кода.

У Zig весёлая, подрывная атмосфера. Это язык для разрушения корпоративной классовой иерархии (объектов). Это язык для мегаломанов и анархистов. Мне он нравится. Надеюсь, он скоро выйдет в стабильный релиз, хотя текущий приоритет команды Zig — переписать все свои зависимости. Не исключено, что они попытаются переписать ядро Linux, прежде чем мы увидим Zig 1.0.

Go — для командной работы и быстрой разработки, Rust — для критически важных систем, где нужны максимальные гарантии, Zig — для тех, кто хочет полного контроля и готов от ООП отказаться в пользу дата-ориентированного подхода. Выбор зависит не от списка фич, а от того, какая философия вам ближе.

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

Спустя полтора года у него за плечами 700+ решенных задач и впечатляющий стрик длиной в 600 дней.

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

«LeetCode — это спорт»

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

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

Он выделяет три типа решений на платформе:

• Производительные и сложные, где «изобретают велосипед» ради скорости;
• Элегантные, но непроизводительные, зато читаемые и похожие на реальный продакшн-код;
• «Чтобы просто работало» — типичные решения новичков без оптимизаций.

Сам разработчик предпочитает второй вариант: чистый код, пусть и не самый быстрый.

Стоило ли того?

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

«После 200+ дней это превращается в рутину — задача ради задачи. Но привычка сильнее мотивации. Делая по одной задаче в день, можно дойти до любого уровня».

Среди советов начинающим — не гнаться за hard-задачами, смотреть чужие решения и помнить, что прогресс измеряется не количеством, а осознанностью.

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

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

История: золотой век мейнфреймов и становление цифровой инфраструктуры

В 1960-80-е годы, во время «экономического чуда», Япония массово внедряла компьютеры. Стандартом стали мейнфреймы IBM, а COBOL — идеальным языком для них.

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

Принцип «Работает — не трогай»

Из истории вытекает первая и главная причина живучести COBOL — эффект path dependency (зависимость от предшествующего развития).

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

Из-за этого эффекта инженеры были ограничены в своём выборе. При этом каждый программист знает, что не стоит трогать legacy, которое работает. А чем дольше его не трогать — тем старше и больше оно становится. Чем старше и больше — тем страшнее, дороже и рискованнее его изменять.

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

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

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

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

Экономика: стоимость замены против стоимости поддержки

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

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

Следующий вопрос — экономическая выгода. Руководство компаний справедливо задаётся вопросом: «Какую прибыль принесет нам этот переход?». Чаще всего ответ — «Никакой, мы просто получим систему, которая делает то же самое, но на другом языке». С точки зрения ROI (возврата инвестиций) проекты миграции или модернизации выглядят крайне непривлекательно.

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

Культура: японский консерватизм и системный подход

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

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

Ещё одна особенность — система пожизненного найма.

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

Такая традиция создала уникальную среду: инженеры, начавшие работать с COBOL в 1980-х, оставались в компаниях до пенсии, накапливая и передавая бесценные знания. Это создавало внутреннюю стабильную экосистему экспертизы.

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

Решение кадрового кризиса: не вопреки, а благодаря

Самое большое заблуждение — считать, что Япония столкнулась с кадровым голодом и ничего не делает. Напротив, она выстроила целую индустрию по управлению этим COBOL-наследием.

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

Крупные корпорации передают поддержку COBOL-систем специализированным IT-гигантам, таким как Fujitsu, NEC, NTT Data, IBM Japan. Внутри этих компаний существуют целые департаменты, которые:

1. Целенаправленно нанимают и обучают молодых инженеров работе с COBOL и мейнфреймами.

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

3. Разрабатывают инструменты модернизации: транспайлеры (конвертирующие COBOL в Java, в том числе на базе AI), эмуляторы и платформы для запуска legacy-кода в облаке.

Проблема кадров осознана и решается решается разными путями. Но возможно ли и нужно ли поддерживать COBOL бесконечно?

Есть ли у COBOL преимущества сегодня?

Кажется, что у такой старой технологии нет никаких преимуществ. Но давайте найдём одно — стабильность и надёжность. Системы продолжают работать исправно и пока их удаётся поддерживать. Вряд ли новый проект начнут разрабатывать на COBOL, но поддержка всё ещё продолжается.

Безусловный минус — стоимость поддержки. К 2025 году затраты на поддержку COBOL-решений могли составить до 12 триллионов йен в год или 80 миллиардов долларов, что уже превышает некоторый психологический барьер. Этому прогнозу уже несколько лет, так что сегодня компании стоят перед сложным выбором: вкладываться в модернизацию или продолжать поддержку.

В конечном итоге, живучесть COBOL в Японии — это не признак технологической отсталости, а следствие расчёта, уважения к стабильности и долгосрочной стратегии управления legacy. Эти старые системы — всё ещё ядро национальной цифровой инфраструктуры: дорогое в обслуживании, но надёжное.

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

Но переход в IT редко бывает лёгким. Первые месяцы поиска работы обернулись десятками отказов: более 110 отправленных резюме, более 500 откликов на HeadHunter, 200 на Хабр и около 50 – на вакансии в телеграм. И только одно приглашение на собеседование. Желанный оффер казался недосягаемым.

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

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

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

Как стать ментором: от сарафанного радио к полноценному проекту

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

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

Сначала я просто помогал знакомым: объяснял, что-то подсказывал. Потом ко мне начали обращаться и те, с кем я лично не был знаком. Полноценно, в публичном формате я занимаюсь менторством около полутора-двух лет. Начиналось всё довольно скромно: завёл соцсети, к нам приходило совсем немного учеников, и я работал с ними индивидуально. Постепенно у меня родилась идея превратить это в продукт — в полноценное менторство по трудоустройству Python-разработчиком.

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

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

Я увидел, что это работает, что людям действительно помогает. За это время мы довели до трудоустройства десятки ребят. И каждый день стараемся улучшать программу: добавляем новые форматы, тесты, домашние задания, вводим регламенты качества. Если вспомнить, с чего всё начиналось, то это был буквально чат в Telegram с небольшой подборкой тем. Сейчас же у нас полноценная платформа с уроками, практикой, проверками и системой поддержки.

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

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

Что происходит на рынке и почему Женя не мог найти работу

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

• Кризис — и мировой, и локальный. Компании стали экономить, поэтому вакансий объективно стало меньше.
• Кандидатов стало больше. Конкуренция выросла, и это естественно заставляет работодателей поднимать планку.
• Чтобы выбрать из сотни резюме, компании добавляют дополнительные фильтры: усложняют задания, делают больше этапов, повышают требования на собеседованиях.

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

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

Рекрутеры зачастую не читают резюме внимательно — в HeadHunter нажимают пару фильтров и отсекают людей, которые могли бы подойти. У самих сотрудников, которые проводят собеседования, нет отдельной мотивации. Им просто говорят: «Иди проведи собес», они идут и делают, без особого энтузиазма.

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

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

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

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

До того, как взять помощь наставника Женя сам прорабатывал своё резюме около восьми часов, читал статьи на Хабре и Тпрогере, пытался применить описанные другими разработчиками лайфхаки. Но выходило слабовато — откликов на резюме практически не было.

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

Процесс выглядел так: он выполнял шаг — присылал результат. Это могло быть резюме, итоги собеседования или вопросы. Я давал обратную связь не в формате “ок/не ок”, а с конкретикой: что именно поправить — раз, два, три — и что делать следующим шагом. Если всё в порядке, фиксировали результат и переходили к следующему пункту. По сути, я выдавал ему алгоритм и сопровождал его шаг за шагом. После корректировки резюме Жене наконец стали поступать отклики с HH и приглашения на скрининги от HR.

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

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

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

Ошибки в резюме

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

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

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

Самостоятельно понять, что именно нужно рынке — непросто. Да, можно смотреть ролики на YouTube, читать статьи и искать материалы в открытом доступе, но чаще всего такие источники не заточены под реальный результат — трудоустройство.

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

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

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

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

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

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

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

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

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

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

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

Кому нужен ментор и как прокачиваться

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вы пользовались услугами менторов или наставников? Или помогали кому-то сами? Расскажите о своём опыте в комментариях.

В этой статье будет много моих выводов, гипотез и идей. Это моя первая статья, поэтому буду рад услышать аргументированную критику. В статье часто используется псевдокод, чей синтаксис напоминает смесь 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.

BeeCR: автоматический помощник для ревью в GitLab

BeeCR — сервис, который автоматически просматривает изменения в запросах на слияние (Merge Requests) в проектах GitLab и добавляет к ним комментарии. Каждый файл, который вы меняете, получает свой набор комментариев.

Сервис пригодится всем, кто пишет код на популярных языках программирования, и понимает, зачем нужно код-ревью. BeeCR работает с кодом на Python, JavaScript, Java, Kotlin, Swift, C#, C++, Ruby, PHP, Go, Bash/Shell, TypeScript и др.

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

Что именно проверяет?

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

• Нарушения логики в алгоритме.
• Лишний код, который случайно остался после отладки.
• Ошибочность информации в логах.
• Неудачное именование сущностей. Его задача — помочь найти неочевидные проблемы и дать рекомендации.

Как он встраивается в процесс разработки?

BeeCR бесшовно интегрируется с GitLab. Результаты автоматического ревью отображаются прямо в привычном интерфейсе GitLab Code Review, рядом с комментариями ваших коллег.

Есть два основных способа интеграции:

• Через Вебхук: это самый простой и удобный вариант для большинства. Вебхук BeeCR запускается автоматически при создании или обновлении Merge Request.
• Через CI/CD: если у вас уже есть развитая конфигурация GitLab CI/CD, этот вариант позволит выполнить более тонкую настройку. BeeCR предоставляет готовые конфигурации или шаблоны CI/CD-задач, которые можно использовать как есть или доработать. Для новых версий GitLab (начиная с 17) доступен CI/CD-компонент.

Можно ли настроить BeeCR под себя?

В BeeCR можно кастомизировать разные рабочие параметры:

• Язык комментариев: по умолчанию комментарии пишутся на английском, но вы можете указать другой язык, например, русский.
• Фильтрация файлов: управляйте списком файлов для проверки (или исключения) с помощью регулярных выражений.
• Языковая модель: в версии On-Premises можно выбрать языковую модель (например, OpenAI или Ollama) и настроить её параметры.
• Дополнительные инструкции: можно задать промты, чтобы получить более специфичные комментарии, через конфигурационный файл или комментарий в Merge Request.
• Триггер и путь к конфигу: вы можете переопределить ключевое выражение-триггер (по умолчанию /beecr) и путь к конфигурационному файлу .beecr.yml. Настройки задаются через HTTP-заголовки вебхука, параметры запроса в URL, конфигурационный файл .beecr.yml в корне репозитория, переменные окружения сервера API (для On-Premises) или параметры задачи CI/CD.

Как попробовать и сколько это стоит?

BeeCR предлагает пробный период на 1 месяц без ограничений. Стоимость рассчитывается по количеству активных участников в запросах на слияние в GitLab. К таким участникам относятся разработчики, ревьюверы, участники дискуссий и ответственные за слияние ветки. Сервис доступен в облачной версии (SaaS) или для локальной установки (On-Premises).

В версии On-Premises можно использовать как локально развернутые, так и внешние модели ИИ (например, ChatGPT), при этом оплата внешних моделей ложится на клиента. BeeCR включен в реестр Российского программного обеспечения (реестровая запись №25382 от 12.12.2024).

Reshift — автоматическая проверка безопасности JS-кода

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

Поддерживаемые языки: JavaScript.

Что именно проверяет?

В функции плагина входят:

• Набор проверок безопасности, разработанных экспертами в области безопасности;
• Подробные, понятные описания обнаруженных проблем (DevSec Coach);
• Рекомендации по исправлению (remediation snippets);
• Ссылки на дополнительные ресурсы по уязвимостям.

Как встраивается?

Сейчас плагин доступен только ограниченной группе участников закрытого бета-тестирования. Чтобы подключиться, нужно записаться на waitlist через сайт Reshift.

Collaborator — расширенное ревью с фокусом на командную работу

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

Практически все популярные языки программирования, включая Java, Python, JavaScript, C#, C++, PHP, Go, Swift, Kotlin и др. Также поддерживается ревью не только исходного кода, но и документации (Markdown, reStructuredText, HTML, PDF, Word) и тестовых сценариев.

Что именно проверяет?

Collaborator сочетает автоматическую проверку и ручное ревью, в его функции входят:

• Ревью исходного кода и документов (Word, PowerPoint, Visio, PDF, изображения, URL и др.)
• Совместное обсуждение изменений, пометки дефектов и контроль версий
• Возможность создания шаблонов ревью, чек-листов и пользовательских рабочих процессов
• Отчёты для анализа процессов, отслеживания дефектов и аудита

Как встраивается?

• Поддерживаются более 11 систем контроля версий: Git, Subversion, Perforce, TFS, CVS, Mercurial, ClearCase, AccuRev, Rational Team Concert и др.
• Также интеграция со средами разработки (Eclipse, Visual Studio), Jira, Web UI и API.

Можно ли настроить под себя?

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

Как попробовать и сколько стоит?

Community — бесплатная для небольших команд (до ~10 пользователей), с базовым набором функций.

Team — платная, для средних команд (до ~25 пользователей), с расширенными возможностями ревью. $755 в год за пакет на 5 пользователей (до 25 человек).

Enterprise — полная версия для крупных организаций; включает мощные настройки, интеграции и поддержку Simulink моделей. Около $1349 в год за одну concurrent-лицензию, включая поддержку Simulink и расширенные возможности.

Codestriker — лёгкий инструмент для асинхронного ревью

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

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

Что именно проверяет?

Сам по себе Codestriker не выполняет глубокий автоматический анализ кода.

Для статического анализа, проверки стиля или поиска уязвимостей его можно дополнить линтерами, CI-скриптами или внешними утилитами.

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

Как встраивается в процесс разработки?

• Работает через веб-интерфейс, не требует сложной установки.
• Поддерживает загрузку диффов и изменений напрямую или через интеграцию с системами контроля версий.
• Сохраняет историю всех ревью для удобного поиска и аудита.
• Поддерживает экспорт результатов и комментариев в HTML или текстовые файлы — полезно для отчётности и архивирования.
• Интегрируется с системами контроля версий: CVS, Subversion, ClearCase, Perforce, Visual SourceSafe.
• Паспортная интеграция с баг-трекерами (Bugzilla, Flyspray) и системой LXR для быстрого просмотра кода.

Можно ли настроить под себя?

Можно дорабатывать под свои процессы, так как это open-source.

• Поскольку Codestriker — это open-source, его можно модифицировать под внутренние процессы: добавить плагины, интеграцию с баг-трекерами, отчёты в специфическом формате.
• Можно настраивать шаблоны комментариев, порядок отображения изменений, форматы экспорта.
• Код доступен для свободной доработки, что делает сервис особенно привлекательным для команд с собственными требованиями.
• Требует наличие сервера и СУБД — поддерживаются MySQL, PostgreSQL, Oracle, SQL Server и любая база через DBI.
• Разворачивается на сервере: конфигурация веб-сервера (Apache/IIS), базы данных, установка Perl-модулей.

Как попробовать и сколько стоит?

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

Gerrit — мощный инструмент для распределённых команд

Gerrit — это мощная open-source платформа для ревью кода, тесно интегрированная с Git. Она используется во многих крупных компаниях и open-source проектах, где требуется строгий контроль качества кода и формальный процесс утверждения изменений.

Поддерживаемые языки: любые Gerrit работает на уровне изменений в Git, а не конкретного языка. Можно ревьюить и код, и документацию, и конфигурационные файлы.

Проект начал развиваться как форк от системы Rietveld и был создан Шоном Пирсом (одним из авторов Git) для внутренней разработки Android в Google .

В версии 2.x проект был переписан с Python на Java (Java EE), с использованием SQL для метаданных. Начиная с версии 3.x, Gerrit перешёл на NoteDb, где все метаданные хранятся непосредственно в Git-репозитории.

Что именно проверяет?

Сам по себе Gerrit не выполняет статический анализ, но легко интегрируется с линтерами, CI/CD-пайплайнами и системами тестирования. Основная задача — управление процессом ревью: комментарии к конкретным строкам, обсуждения, обязательное одобрение перед слиянием. Поддерживает настройку правил мёрджа (например, «два апрува от сеньоров» или «все тесты должны пройти»).

Пользователи создают review, отправляя коммит на refs/for/branch, что отличает изменения, требующие ревью, от прямых коммитов. Ревьюеры могут голосовать, модель оценки, например, используется шкала от -2 до +2 для Code-Review и Verified чеков. Доступно изменение изменений в рамках одного change (patch set), с возможностью обсуждения и улучшения кода до принятия.

Как встраивается?

• Работает как веб-приложение поверх Git. Поддержка SSH и HTTPS для работы с Git-клиентами, возможность размещения и управления множеством репозиториев с продвинутым контролем доступа и репликацией (например, геораспределённые зеркала)
• Предоставляет визуальный интерфейс для сравнения изменений и обсуждения.
• Глубокая интеграция с Jenkins, GitHub Actions, GitLab CI и другими CI/CD-системами.
• Поддерживает fine-grained permissions — можно задать права на просмотр, комментирование и утверждение кода на уровне проекта, папки или файла.
• Расширяемый через серверные плагины, доступные в официальном репозитории.

Можно ли настроить под себя?

Доступны плагины, собственные скрипты, тонкая настройка прав доступа:

• Плагины для интеграции с трекерами задач (Jira, Redmine и др.).
• Скрипты для автоматизации ревью и проверки коммитов.
• Возможность настроить workflow под конкретный проект: обязательные шаги, правила коммит-месседжей, формат патчей.

Как попробовать и сколько стоит?

• Полностью бесплатен, распространяется под лицензией Apache 2.0.
• Можно развернуть на своих серверах или использовать облачные инсталляции.
• Отлично подходит для крупных команд с формализованным процессом разработки.
• Gerrit — полностью open-source. Обновления можно скачивать в виде .war или через Maven Central, подписанные ключом автора.
• Сообщество активно поддерживает релизы, документацию и обсуждения через форумы, Discord и пользовательские мероприятия.

Crucible — код-ревью с аналитикой и интеграцией в Atlassian

Crucible от Atlassian — это инструмент для код-ревью, ориентированный на большие компании, которым нужны интеграции с экосистемой Atlassian (Jira, Bitbucket, Confluence) и детальная аналитика по процессу ревью.

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

Что именно проверяет?

• Логические ошибки;
• Историю коммитов с возможностью поиска;
• Потенциальные баги и нарушения стиля кода (с помощью подключаемых линтеров);
• Несоответствия между кодом и документацией;
• Общие архитектурные недочёты (в рамках командного обсуждения).

Доступны Review и обсуждения — есть возможность комментировать строки кода, запускать threaded-дискуссии, упоминания и встроенные обсуждения. Ленты событий показывают последние комментарии, обновления, активность команды.

Как встраивается?

• Поддерживает Git, SVN, Mercurial, Perforce и CVS.
• Интегрируется с Jira — можно привязывать задачи к конкретным ревью.
• Есть возможность планировать ревью, назначать ответственных, отслеживать прогресс и статистику по команде.
• Поддерживает расширение через REST API, можно создавать надстройки через плагины.

Можно ли настроить под себя?

Это кроссплатформенное (Windows, Linux, macOS) Java-приложение — требует x86‑64 или аналогичный. Подключаются официально поддерживаемые СУБД: HSQLDB (для тестирования), MySQL, PostgreSQL, Oracle, SQL Server.

• Настраиваемые шаблоны ревью.
• Чек-листы для проверки типовых требований.
• Автоматические уведомления и напоминания для участников.
• Гибкая настройка прав доступа.

Как попробовать и сколько это стоит?

• Платная лицензия: от $10 для 5 пользователей, далее цена зависит от команды.
• Есть 30-дневный бесплатный пробный период.
• Оптимально для компаний, уже использующих Atlassian Jira и Bitbucket.

Это позволяет вставлять работающий код 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 — язык из категории эзотерических.

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

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

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

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

Какие IT-профессии наиболее востребованы за рубежом

По данным сервиса по поиску работы HeadHunter, в 2024 году наибольшим спросом за границей пользовались российские:

• менеджеры по продажам и работе с клиентами (13%),
• операторы колл-центров (5%),
• дизайнеры, менеджеры по маркетингу, интернет-маркетологи, художники (по 4%),
• учителя, SMM- и контент-менеджеры (по 3%),
• секретари, помощники руководителя, ассистенты (по 2%).

Программисты и разработчики заняли почётное второе место (10%). А специалисты технической поддержки и тестировщики набрали всего по 2%.

Но в исследовании образовательной онлайн-платформы «Нетология» и международного коммуникационного агентства Zecomms Agency специалист технической поддержки — наоборот, наиболее востребованная профессия за рубежом. С ним связано 17% от общего массива IT‑вакансий, что делает специалиста техподдержки абсолютным лидером по количеству открытых вакансий.

На втором месте расположился программный инженер (16%), на третьем — бизнес-аналитик (6%) и IT-консультант (6%).

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Языки программирования, актуальные для иностранных компаний

Согласно исследованию «Нетологии» и Zecomms Agency, Java признан самым популярным языком программирования — его активно используют компании по всему миру. На Java приходится более четверти всех открытых вакансий (26%) в сфере IT в Европе, США, Латинской Америке, Азии и на Ближнем Востоке.

Java — это универсальный язык программирования, который отличаются стабильностью, масштабируемостью и кроссплатформенностью. На нём пишут крупные корпоративные приложения в банках, промышленных, страховых и телеком-компаниях, облачные, распределённые и IoT- системы, микросервисы. Также Java считается неотъемлемой частью бэкенд-разработки.

На втором месте по популярности находится язык SQL, который используют для разработки баз данных и систем аналитики. На него пришлось 24% всех вакансий, бóльшая часть из них в Европе, Азии и на Ближнем Востоке.

Замыкает тройку лидеров Python (23%) — более половины открытых вакансий в Азии и на Ближнем Востоке связано именно с этим языком. Оно и неудивительно: на Python пишут модели для машинного обучения, анализа данных и автоматизации.

Сколько айтишникам платят за границей

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Но ключевое — размер оклада. По данным «Профсоюза работников ИТ», медианная зарплата специалистов уровня senior в России составляет 276 362 рубля в месяц, в то время как за рубежом она равна 386 730 рублей в месяц. Российские миддлы получают 170 000 рублей, а работающие за границей — 205 142 рубля. Зарплата джунов несильно отличается, хотя «за бугром» она всё-таки немного больше: 85 000 рублей против 80 000 рублей в России.

Таким образом, зарплата IT-специалистов за рубежом как минимум в 1,5 раза больше, чем в России.

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

Где IT-кадры пользуются спросом

Найти работу в IT сейчас везде нелегко, но чуть проще это сделать там, где активно развивается IT-сектор и требуется много кадров соответствующего профиля:

Германия. Наибольший дефицит IT-специалистов наблюдается в Германии — в 2023 году было опубликовано 103 089 вакансий. Особенно остро нехватка кадров ощущается в таких областях, как разработка программного обеспечения, Data Science, кибербезопасность и DevOps. А в 2025 году страна планирует выдать на 10% больше рабочих виз, чем годом ранее.

Нидерланды. В стране большое внимание уделяется IT-стартапам. Так, в 2024 году голландские технологические компании привлекли €3,7 млрд венчурных инвестиций — это около 5% от общего объёма капитала, вложенного в европейскую экосистему. Благодаря этому Нидерланды вошли в топ‑10 стран Европы по объёму инвестиций в технологии. Особенно быстро растёт сектор DeepTech («глубоких технологий») — полупроводники, искусственный интеллект и квантовые технологии.

Канада. Такие канадские города как Торонто, Ванкувер и Монреаль считаются настоящей IT-меккой. Здесь активно развиваются стартапы и работают подразделения крупнейших технологических компаний — Google, Microsoft, Amazon. Кроме того, для IT-специалистов есть много иммиграционных программ, например, Global Talent Stream, которая позволяет получить разрешение на работу в течение двух недель.

США. В 2023 году объём IТ-рынка США достиг $1,3 трлн и продолжает развиваться высокими темпами. В Европейском союзе он составил $1,05 трлн, в Китае — $348 млрд, в России — $36,1 млрд. Таким образом, американский технологический рынок в 36 раз больше российского, в 1,24 раза больше европейского и почти в четыре раза превосходит китайский. Это подтверждает его статус мирового лидера. Соответственно, IT-специалистов нужно много.

Куда уехать проще всего

По данным HeadHunter, активнее всего российских специалистов приглашают на работу компании из:

• Белоруссии — 172,3 тыс. приглашений,
• Казахстана — 150,9 тыс. приглашений,
• Грузии и Турции — 69,7 тыс. и 67,8 тыс. приглашений соответственно,
• Узбекистана — 57,2 тыс. приглашений.

Самый большой рост интереса продемонстрировали китайские работодатели — он увеличился почти в шесть раз. В 2023 году количество предложений для жителей России о работе в Китае составляло всего 4,8 тыс., тогда как в 2024 году цифра достигла 27,6 тыс. предложений.

Кроме того, за год потребность в российских специалистах выросла в Сербии с 5,8 тыс. до 26,3 тыс. (+356,3%), в Турции — с 23,5 тыс. до 67,8 тыс. (+188,6%), на Кипре — с 4,6 тыс. до 12 тыс. (+160,9%), в Польше — с 4,1 тыс. до 9,0 тыс. (+119,6%) и в ОАЭ — с 19,2 тыс. до 41,7 тыс. (+117,2%).

А Европа стала лидером по количеству предложений для IT-специалистов со знанием русского языка — 3% всех IT-вакансий в регионе. На других рынках доля таких предложений не превышает 1%. Чаще всего русскоязычных специалистов ищут в Польше — 2 200 вакансий, Венгрии — 752 вакансии, Австрии — 178 вакансий, Греции — 152 вакансии.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Как IT-специалисту найти работу за границей: четыре шага

1. Зарегистрируйтесь на международных платформах

Принцип поиска работы за рубежом такой же, как и в России. Нужно зарегистрироваться на платформах по типу HeadHunter и откликаться на понравившиеся вакансии. Чем больше откликов, тем лучше.

Вот подборка сайтов для поиска работы за границей:

• LinkedIn — профессиональная социальная сеть, где можно искать вакансии и налаживать контакты;
• Indeed — международный агрегатор вакансий, позволяющий фильтровать их по странам, городам и отраслям;
• Relocate.me — платформа для вакансий с релокацией;
• Remote OK — площадка для поиска удалённой работы;
• WWR — сервис, где публикуют вакансии крупные зарубежные компании, например, Amazon или Google.
• AngelList Talent — каталог вакансий в иностранных стартапах.

Некоторые из них открываются только с VPN.

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Удобнее всего искать вакансии зарубежных компаний через LinkedIn. По моему опыту, большинство специалистов находят работу за границей именно через эту площадку. Но есть и альтернативные варианты — например, телеграм-каналы с профильными вакансиями. Будьте готовы к тому, что придётся отправлять много откликов. В среднем на 100 откликов приходится не более 5 ответов.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

2. Адаптируйте резюме для иностранного рынка

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

Эксперты компании EP Advisory, которая помогает российским специалистам строить карьеру за рубежом, рекомендуют включать в CV разделы Name, Profile, Education, Experience, Skills & Other. Названия предыдущих компаний и занимаемые должности следует выделять, а каждый блок — разграничить чертой.

Кроме того, в некоторых странах, например, Великобритании, США и Канаде не принято добавлять фото в резюме. Такое правило стало следствием законов против дискриминации в этих странах, поэтому его несоблюдение может вызвать негативную реакцию и привести к мгновенному отказу.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

3. Обратитесь в агентство по трудоустройству

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

Вот список наиболее известных рекрутинговых агентств:

• Adecco — крупнейшее агентство с вакансиями по всему миру;
• Manpower — международная стаффинговая, аутсорсинговая и HR-консалтинговая компания из России;
• Michael Page — международная компания, которая специализируется на подборе персонала среднего и высшего звена;
• Hays — британская рекрутинговая компания, которая предоставляет услуги по подбору персонала в 33 странах мира;
• Harvey Nash — международная компания, которая специализируется на IT-аутсорсинге;
• Randstad — голландская консалтинговая компания, которая сотрудничает с ведущими зарубежными работодателями.

Агентства также консультируют по вопросам адаптации и помогают с поиском жилья.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

Чтобы найти работу в Лондоне, я сотрудничал с международными и британскими рекрутинговыми агентствами — Hays, Harvey Nash и Michael Page. Примерно 50% предложений приходили именно от них. Эти агентства играют важную роль на IT-рынке и обладают широкой сетью контактов с работодателями по всей Европе. Они помогали мне в поиске подходящих позиций и сопровождали на всех этапах — от первичного отклика до собеседования и подписания оффера.

4. Получите визу и разрешение на работу

Без визы и разрешения приступить к работе за границей не получится. Здесь доступны два варианта — Digital Nomad Visa или обычные рабочие визы.

Digital Nomad Visa. Digital Nomad Visa или «виза цифрового кочевника» позволяет легально жить за рубежом, но при этом продолжать удалённо работать на родину. В отличие от туристической визы, Digital Nomad Visa даёт право длительно находиться в определённой стране, а в сравнении с рабочей визой — не требует трудоустройства на местном рынке.

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

Чтобы получить визу цифрового кочевника, нужно подтвердить минимальный доход (чаще всего не ниже 2000 евро в месяц) и наличие медицинской страховки. Также может понадобиться трудовой договор или договор подряда, доказывающие, что вы работаете удалённо. Сейчас Digital Nomad Visa оформляют в 66 странах, включая Португалию, Испанию, Эстонию, ОАЭ и Южную Корею.

Классические рабочие визы. Это визы EU Blue Card или виза H‑1B.

• Голубая карта (EU Blue card) — виза для работы в Европе. Чтобы получить её, нужен диплом о высшем образовании (не ниже бакалавра) и оффер с зарплатой от 48 300 евро год (43 760 евро для IT‑специалистов) на срок минимум шесть месяцев. В случае одобрения выдаётся вид на жительство, действующий до четырёх лет с возможностью продления.

• Виза H‑1B — виза для работы в США. Она также требует наличия высшего образования и оффера от местной компании. Но американское законодательство устанавливает лимит на выдачу H‑1B — 65 000 базовых и 20 000 дополнительных виз для специалистов с магистерской степенью из США. Всего 85 000 виз в год. Виза предоставляется максимум на три года с возможностью продления до шесть лет.

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

Официальное трудоустройство или фриланс

Удалённая работа на фрилансе

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

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

Официальное трудоустройство с релокацией

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

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

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

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

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

Для оценки владения иностранными языками, включая английский, в Европе используют систему CEFR (Common European Framework of Reference). CEFR выделяет шесть уровней знания языка: A1, A2, B1, B2, C1, C2.

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

Максим Оганов, ментор, бизнес-консультант, автор проекта Oganov.Consulting:

Обязательное требование — свободное владение английским: например, в Португалии большинство сотрудников IT-компаний общаются на нём. Но иногда кандидату необходимо знание местных языков — так, если вы хотите переехать во Францию, шансы на трудоустройство без владения французским минимальны.

Евгений Козак, senior фронтенд-разработчик компании With Intelligence, живёт в Лондоне, более 10 лет опыта работы за границей:

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

Коротко о главном

• Иностранные компании активно используют Java, Python, SQL и нуждаются в программистах, умеющих писать на этих языках.
• IT-специалисты особенно востребованы в Германии, Нидерландах, Канаде и США — странах с наиболее интенсивным ростом технологического сектора.
• Проще всего уехать в Белоруссию, Казахстан, Турцию, Грузию и Китай.
• Работать за границей можно официально или на фрилансе.
• Чтобы получить оффер, следует зарегистрироваться на международных платформах для поиска работы, адаптировать резюме, оформить визу и, при необходимости, обратиться в агентство.

Казалось бы, код — это просто текст. Но каждый запрос к 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 году это актуально как никогда.

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

Код ≠ программа

По словам Экрема, программа — это не набор строк. Это ментальная модель: зачем все устроено именно так, как устроено.

Архитектура, допущения, компромиссы — все это нельзя просто вычитать из кода, это нужно понимать. И если автор той или иной реализации внутри проекта уходит, вместе с ним уходит и теория. И хоть сам код остается, но лишь скорее как «пустая оболочка».

Как мы теряем смысл

Экрем поделился мнением, что мы сегодня пришли к кризису теории. Причины очевидны:

• ИИ-помощники генерируют код без контекста.
• Молодые разработчики используют его рефлекторно, без анализа.
• Бизнес подталкивает к скорости, а не к качеству.

Код растет, архитектура рушится. Никто не знает, как и почему что-то работает. И что будет, если это изменить.

Проблема не нова, но масштаб — новый

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

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

Зачем нужны синьоры

В свою очередь старшие разработчики не просто пишут код. Они:

• Удерживают теорию — понимают, как связаны бизнес и архитектура.
• Фильтруют ИИ — отличают полезное от вредного.
• Учат — объясняют, что важно понимать, а не делать лишь «чтобы работало».
• Сохраняют согласованность — следят, чтобы код отражал суть системы.

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

Как избежать надвигающейся проблемы

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

• Документировать не только что, но и зачем.
• Проводить ревью с упором на идейную целостность.
• Передавать знания через наставничество.
• Не допускать, чтобы ИИ заменял мышление.

Больше новостей в нашем тг-канале Представляешь

Что известно на данный момент

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

На старте платформа предлагает тесты по следующим направлениям:

• 5 языков программирования: Python, Java, SQL, C#, PHP;
• 12 теоретических и прикладных тем: HTML, ООП, PostgreSQL, функциональное и регрессионное тестирование, Git, API, CSS, Docker, алгоритмы и структуры данных, JavaScript и Linux.

В течение 2025 года планируется добавить ещё два языка программирования — C++ и Go — а также два новых направления: «Математическая статистика» и «Машинное обучение». Всего в этом году платформа охватит 21 ИТ-компетенцию.

Для прохождения тестирования необходимо зайти на страницу «Национальная система подтверждения ИТ-компетенций» на Госуслугах, выбрать интересующий навык и перейти на платформу. Также пройти оценку можно напрямую на сайте hh.ru — именно эта платформа выступает техническим оператором проекта.

Сертификат будет храниться в личном кабинете на Госуслугах в разделе «Образование» и будет действовать в течение одного года. Важно отметить, что платформа фиксирует только успешные попытки. Если пройти тест с первого раза не удалось, повторная попытка станет доступна через месяц. В резюме на hh.ru отразится лишь удачная сдача в виде значка-подтверждения.

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

Что такое DevSecOps

DevSecOps образовано от слов development (разработка), security (безопасность) и operations (эксплуатация или операции). Это подход к разработке приложений, при котором безопасность учитывается на каждом этапе CI/CD, чтобы минимизировать стоимость и повысить скорость исправления ошибок. К нему относятся не только инструменты, по типу различных сканеров библиотек и кода, но и определённые договоренности между разработчиками, DevOpsами и безопасниками.

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

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

Лицо врага

Не все библиотеки с открытым исходным кодом, выложенные в публичные репозитории, можно считать безопасными. Их авторы часто остаются неизвестными — это могут быть как энтузиасты, так и злоумышленники, включая хакеров или представителей недружественных государств. В итоге даже при использовании сложных систем защиты — межсетевых экранов, VPN, антивирусов, DLP и PAM — компания может оказаться уязвимой. Уязвимость может прийти изнутри — через стороннюю библиотеку, которая станет «троянским конём» и даст злоумышленникам доступ к данным, производственным процессам и критичной инфраструктуре.

Процент небезопасных приложений в исследованиях российских компаний, занимающихся защитой приложений, в разные годы отличается и зависит от отрасли. Так, про финансовую отрасль Positive Technologies в 2015 говорили о 90%, в 2016 г. — о 71%, а в 2017 – о 56%. Если замеченный Positive Technologies тренд защищенности приложений финансового сектора сохранился бы в тех же пропорциях, то сегодня процент был бы ещё меньше. Однако исследование «Стингрей Технолоджис» 2024 г. говорит о 56% опасных приложений в финтехе.

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

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

Какие есть риски для данных

Основные риски для данных обычно связаны с нарушением их конфиденциальности. В процессе разработки важно проводить тесты, а для этого нужны данные, причём не сильно отличающиеся от настоящих. Также важен их объём, иначе не получится провести нормальные нагрузочные тесты. Выгрузка реальных данных — самый заманчивый вариант. Но если для стендов Dev и Test используются облачные среды или в процессах разработки задействованы подрядчики, то некоторые организации могут на такое не решиться из-за требований к ИБ. И это логично, поскольку в Prod есть комплексный подход к защите, а на стендах Dev и Test меры защиты могут быть минимизированы.

Один из способов снизить риски — использовать системы маскирования: они помогают обезличить персональные и финансовые данные (например, номера карт и счетов). Сейчас действует приказ Роскомнадзора №996 от 2013 г., но, необходимо отметить, уже опубликован проект приказа Роскомнадзора «Об утверждении требований к обезличиванию персональных данных и методов обезличивания персональных данных», который его заменит.

Контейнеры стали стандартом для запуска приложений, но вместе с удобством они приносят и риски — особенно в защите данных. Да, контейнеризация улучшает доступность и масштабируемость, но не решает проблем с конфиденциальностью и целостностью «из коробки». На российском рынке уже существуют отечественные платформы контейнеризации, например, Штурвал, DeckHouse, в которых сразу учтены механизмы безопасности либо есть накладные средства для kubernetes от Luntry, PT, Kaspersky и т.д.

Как внедрять DevSecOps

DevSecOps — подход, при котором безопасность вшита в код на всех этапах. Уязвимости ищут не в самом конце, а прямо по ходу разработки: в pull request'ах, CI/CD и при работе с зависимостями. Такой подход требует, чтобы разработчики, DevOps и специалисты по безопасности работали как одна команда, а не передавали задачи «по цепочке» в последний момент.

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

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

Cloud Native — это подход к разработке приложений, изначально ориентированных на работу в облачной среде и интеграцию с облачными сервисами. Сегодня большинство новых решений проектируются именно так. Для безопасной работы таких приложений важно не только адаптировать архитектуру под облако, но и выстраивать взаимодействие с провайдером: от заключения договора до работы с API. Облачные провайдеры часто предлагают инструменты, которые помогают встроить безопасность в процесс разработки. У многих есть готовые сервисы Kubernetes, в том числе с учётом требований информационной безопасности. Также доступны решения уровня WAF и инструменты анализа безопасности кода (например, SAST, DAST, SCA) — иногда по подписке, как в случае с некоторыми российскими платформами.

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

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

Однако не стоит думать, что это финальная точка. DevSecOps — постоянный процесс: мониторинги, улучшения, обновления стандартов ИБ и поиски идеальных практик.

Цена вопроса

Вернемся к примеру с салатом. Все любят разное: кто-то — «цезарь», другой – «селёдку под шубой». Разные языки программирования, риск-аппетиты в командах в отношении принятия требований безопасности, цели внедрения DevSecOps (кому-то нужно в итоге получить сертификат, а кому-то страшно за конечный продукт и важно обеспечить реальную максимальную безопасность) — всё это не позволяет создать коробочный продукт с фиксированной ценой, хотя на рынке есть те, кто предлагает поставить 2-3 сканера и удовлетвориться этим, назвав DevSecOps.

При внедрении DevSecOps стоит учитывать затраты на разделение сред Dev, Test и Prod — это не входит в концепцию по западным лекалам. Однако от руководства компаний-клиентов нам часто поступают запросы на усиление безопасности разработки, поскольку разработчик перепутал стенд, после чего важнейшие системы компании пострадали. Вынести в облако Dev и Test и оставить у себя Prod кажется хорошей идеей (или наоборот). Для некоторых она способна полностью решить вышеупомянутую проблему.

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

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

Статический анализ кода (SAST) — может быть реализован через бесплатные инструментов, таких как SonarQube, semgrep, gitleaks/trufflehog, но есть и платные – PVS-Studio, Svace, Solar appScreener и т.д.

Динамический анализ кода (DAST) — можно осуществить с помощью бесплатных инструментов OWASP ZAP, Nuclei, NMAP, Burp Suite или платных, например, PT BlackBox.

И другие элементы DevSecOps (анализ мобильных приложений, API и т.д.) можно реализовать с использованием платных или бесплатных инструментов.

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

В процессы Ops можно также включить элемент безопасности WAF (Web Application Firewall). Доступны как бесплатные варианты (например, ModSecurity), так и платные (PTAF, Гарда WAF, Вебмониторэкс и т.д.).

Начинать стоит с бесплатных инструментов, поэтапно внедряя их в CI/СD, взаимодействуя с командой DevOps. По сути, DevSecOps – это консалтинг с возможностью применения платных инструментов, если к ним готова команда DevOps. И мы абсолютно уверены, что ради его внедрения точно не стоит жертвовать командой разработки. Кстати, для трактовки отчётов сканеров зачастую используются те же консалтеры, что внедряли DevSecOps.

Нельзя забывать и об обучении команды практикам безопасной разработки. Тут следует упомянуть, что сканеры типа CheckMarx наглядно демонстрируют эксплуатацию уязвимостей. Часто вендоры сводят DevSecOps к сканерам, консалтеры — к процессам, а про людей и их обучение — забывают.

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

Требования к безопасной разработке ПО

Уже сейчас требования по безопасной разработке (а если есть DevOps, то по сути это требования к внедрению DevSecOps) появились в:

• ГОСТ Р 57580.1-2017: СМЭ.6, СМЭ.7, ЖЦ.4, ЖЦ.5, ЖЦ.6, ЖЦ.7. ЖЦ.24;
• PCI DSS 4.0.1: 6.2, 6.3, 6.5;
• ГОСТ Р ИСО/МЭК 15408-3-2013: ALC_CMC, ALC_CMS, ALC_DEL, ALC_DVS, ALC_FLR, ALC_LCD, ALC_TAT.

Если речь идет о средствах защиты информации (СЗИ), которые нужно будет сертифицировать по требованиям ФСТЭК или ФСБ, важно помнить: инструменты, которые вы используете для сканирования кода, тоже должны быть сертифицированы. Иначе при испытаниях возникнут сложности — лаборатории не примут результаты без официальной документации.

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

Куда будет развиваться DevSecOps

Очевидно, что DevSecOps ждет намного более массовое внедрение и развитие — устранить проблемы на этапе разработки дешевле, чем позже латать пробоины в ИБ.

Скорость появления эксплоитов растёт — и это прямая угроза. Если раньше у команд была пара месяцев, чтобы закрыть уязвимость до начала атак, то теперь — всего несколько дней. Исследование Google показало: в 2018–2019 годах эксплойты появлялись в среднем через 63 дня после патча, в 2020 — через 44, в 2021 и 2022 — уже через 32, а в 2023 году — всего через 5 дней. А с развитием ИИ этот срок может сократиться ещё сильнее.

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

Уже существуют реестр отечественного ПО (ведется под патронажем Минцифры), реестр сертифицированных средств защиты ФСТЭК России, реестр ФСБ России, реестр отечественных ПАК (ведётся Минпромторгом). Чтобы попасть туда в ближайшие годы, разработчики должны будут не просто заявлять о безопасности, а доказывать на практике — в процессах, документации и архитектуре. Это станет драйвером роста: инструменты для безопасной разработки будут развиваться, а вместе с ними — и культура DevSecOps.

Больше новостей — в нашем тг-канале Типичный программист

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

Основные элементы языка

Кольца (Rings)

Ключевая структура Mystical — кольца. Они могут быть трех типов:

• Исполняемые массивы — соответствуют { } в PostScript, изображаются простыми кругами со звездочными символами внутри.
• Неисполняемые массивы — соответствуют [ ] в PostScript, изображаются кругами без звезд.
• Словари — соответствуют << >> в PostScript, изображаются многоугольниками с двойной внешней и одинарной внутренней границами.

Примеры:

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

Текст и сигилы

На границах колец размещаются текст и сигилы — символы, заменяющие операторы, переменные или другие ключевые слова. Например:

• Имена переменных (в PostScript пишутся как /name) отображаются в виде треугольников.
• Строки (в PostScript пишутся в скобках ()) обрамляются в символы, напоминающие египетские картуши.
• Основные операторы, такие как dup, add, mul, if, имеют собственные символы, вдохновленные начальной буквой команды или смыслом операции.

Примеры:

Пользовательские сигилы

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

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

Примеры алгоритмов

Mystical поддерживает основные алгоритмы, такие как быструю сортировку (quicksort) и алгоритм Евклида для нахождения наибольшего общего делителя (GCD). Пример реализации GCD:

Проблемы и планы

На данный момент Mystical — это скорее язык для рисования программ PostScript, чем полноценная интерпретируемая платформа.

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

Перспективы

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

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

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

Вместе с экспертами Kursfinder я изучила около 100 вариантов обучения No-code разработке, чтобы отобрать самые качественные программы. В результате получилась подборка из 36 курсов, где первые 10 — это платные предложения от топовых школ, а остальные — программы для продвинутых пользователей и бесплатные варианты. Полный список курсов по No-code можно найти на сайте Kursfinder.

ТОП-10 лучших курсов по No-Code в 2026 году

1. Основы NoCode: быстрый старт от ProductStar — интенсив для самых мотивированных.
2. Профессия «No-Code разработчик» от Skillbox — объемная программа с крутым портфолио на выходе.
3. Управление зерокод-разработкой от ZeroCoder — для тех, кто хочет создать свою студию веб-разработки.
4. Профессия «No-code разработчик» от Cyberband Academy — прохождение связанных общей темой мини-курсов в своем темпе.
5. No-Code разработчик от Code Breakers — многообразие инструментов и практика на реальных кейсах.
6. Быстрый старт в No-code от Cyberband Academy — мини-курс для тех, кто спешит.
7. Голосовые и чат-боты в no-code от TWIN — обучение созданию чат-ботов.
8. Создание сайтов на WordPress/ВордПресс без кода от Stepik — верстка сайтов без HTML.
9. Легендарный онлайн-курс по no-code разработке от HSE Inc — запись популярного курса с вечным доступом.
10. No-code. От идеи до продукта без программиста от Product University — изучение 10 No-code инструментов.

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

Онлайн-курсы по No-Code

1. Основы NoCode: быстрый старт | ProductStar

Экспресс-курс создан для тех, кто хочет освоить профессию No-code разработчика с нуля и получить практические навыки создания цифровых продуктов без написания кода. Автор программы — команда ProductStar, которая специализируется на обучении современным IT-профессиям. Курс подойдет новичкам, предпринимателям и фрилансерам, которые стремятся быстро войти в профессию и научиться создавать приложения, сайты и автоматизировать бизнес-процессы.

• Стоимость: 45 540 ₽
• Длительность: 9 уроков
• Формат обучения: видеоуроки, практика на реальных кейсах, сопровождение ментора, защита финального проекта
• Сертификат: электронный сертификат об успешном прохождении курса

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

Преимущества:

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

Недостатки:

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

Программа обучения:

• базовые инструменты для разработки без кода;
• освоение платформы Directual: от основ до реальных задач;
• создание приложений в Bubble и запуск интернет-магазина;
• настройка чат-ботов для автоматизации взаимодействия с клиентами;
• построение систем расписаний и работа с визуализацией данных;
• создание сайтов на Tilda с нуля;
• разработка и защита собственного проекта для портфолио.

Полную программу вы найдете на сайте

2. Профессия «No-Code разработчик» | Skillbox

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

• Стоимость: 4 250 ₽/месяц
• Длительность: 8 месяцев
• Формат обучения: несколько учебных модулей с видеоуроками и практикой
• Сертификат: нет информации

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

Преимущества:

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

Недостатки:

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

Программа обучения:

• Bubble;
• Flutter Flow;
• тильда;
• общий итог и знакомство с профессией.

Ознакомиться с полной программой на сайте

3. Управление зерокод-разработкой | ZeroCoder

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

• Стоимость: 18 750 ₽/месяц
• Длительность: бессрочно, при желании можно пройти за 2 месяца
• Формат обучения: записи уроков, воркшопы, консультации
• Сертификат: не предполагается

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

Преимущества:

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

Недостатки:

• очень высокая стоимость;
• программа не для всех.

Программа обучения:

• общие понятия no-code;
• продажи;
• разработка, проекты;.
• как масштабировать свою деятельность;
• собственная веб-студия.

Ознакомиться с полной программой на сайте

4. Профессия «No-code разработчик» | Cyberband Academy

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

• Стоимость: 49 900 ₽
• Длительность: бессрочный доступ к программе, обучение в своем темпе
• Формат обучения: уроки, общение и ОС в чате, домашние работы
• Сертификат: электронный сертификат

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

Преимущества:

• помогают с трудоустройством;
• сессии с вопросами и ответами, качественная ОС;
• 14 работ в портфолио;
• более 200 подробных лекций.

Недостатки:

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

Программа обучения:

• введение;
• первые кейсы на Тильде, Creatium+;
• модуль про бизнес;
• мобильные приложения, + кейс;
• Bubble, + кейс;
• общие сведения про фриланс.

Ознакомиться с полной программой можно здесь

5. No-Code разработчик | Code Breakers

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

• Стоимость: нет информации
• Длительность: нет информации
• Формат обучения: Уроки трижды в неделю, практика, обсуждения в чате
• Сертификат: нет информации

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

Преимущества:

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

Недостатки:

• нет информации о цене и сроках;
• нет глубокой проработки специализированных тем.

Программа обучения:

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

Ознакомиться с полной программой здесь

6. Быстрый старт в No-code | Cyberband Academy

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

• Стоимость: 29 900 ₽
• Длительность: 1 месяц
• Формат обучения: лекции, задания с ОС
• Сертификат: нет

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

Преимущества:

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

Недостатки:

• недостаточно глубины;
• интенсивный тем, подходит не всем.

Программа обучения:

• основы IT;
• веб-сервисы;
• мобильные приложения;
• реализация собственных мини-проектов.

Ознакомьтесь с полной программой можно на сайте

7. Голосовые и чат-боты в no-code | TWIN

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

• Стоимость: 31 100 ₽
• Длительность: 40 часов
• Формат обучения: 40 лекций, доступ на год
• Сертификат: да

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

Преимущества:

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

Недостатки:

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

Программа обучения:

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

Ознакомиться с полной программой здесь

8. Создание сайтов на WordPress/ВордПресс без кода | Stepik

Небольшой курс по одному из самых популярных инструментов для No-code веб-разработки, WordPress. За чисто символическую стоимость вы узнаете, как создавать лендинги и многостраничные сайты. Очень полезный навык во многих профессиях, и он может стать началом новой карьеры.

• Стоимость: 499 ₽
• Длительность: 1,5 часа
• Формат обучения: уроки, тестирования, задания
• Сертификат: нет

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

Преимущества:

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

Недостатки:

• только один инструмент;
• поверхностное знакомство с темой.

Программа обучения:

• хостинг и движок WP;
• шапка и первый экран;
• блочные темы;
• итог.

С полной программой можно ознакомиться на странице

9. Легендарный онлайн-курс по no-code разработке | HSE Inc

Это курс, который в настоящий момент уже не ведется живым потоком, но продается в качестве записи всех занятий. Огромное количество полезных материалов по теме No-code, много реальных примеров, разбор 20 полезных инструментов. Цена ниже, чем была раньше, а вся польза осталась прежней.

• Стоимость: 22 900 ₽
• Длительность: бессрочный доступ к материалам без дедлайнов
• Формат обучения: лекции, воркшопы, инструкции, словарь
• Сертификат: нет

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

Преимущества:

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

Недостатки:

• нет обратной связи;
• много самостоятельной работы.

Программа обучения:

• MVP;
• чат-боты;
• автоматизация;
• приложения;
• большие проекты.

Ознакомиться с полной программой курса вы можете здесь

10. No-code. От идеи до продукта без программиста | Product University

Этот курс представляет собой No-coding обучение в сжатые сроки. Два месяца вы будете интенсивно изучать и пробовать на практике самые полезные для зеро-кодера инструменты, а потом еще в течение четырех месяцев сможете консультироваться с куратором, чтобы отточить приобретенные навыки. Бонусом вы получите несколько хороших кейсов в свое портфолио.

• Стоимость: 1 625 ₽/месяц
• Длительность: 2 месяца
• Формат обучения: теория, практика и обратная связь
• Сертификат: есть

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

Преимущества:

• возврат денег в течение первой недели, если не понравится;
• удобная ОС в чате Телеграм;
• вечный доступ к материалам;
• бюджетно.

Недостатки:

• общие сведения, без глубины;
• нет помощи в трудоустройстве.

Программа обучения:

• введение;
• интернет-магазин;
• Тильда;
• чат-боты;
• мобильные приложения.

Вы можете ознакомиться с полной программой курса на этой странице

Еще 8 курсов No-Code

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

1. Фриланс и NO-CODE от ITGIRLS — за 4 месяца вы получите новую, востребованную профессию. Первые заказы с версткой на Тильде или созданием макета на Фигме вы сможете получать уже во время учебы. Менторы ответят на ваши вопросы и помогут с созданием первых проектов для демонстрации работодателям.
2. Разработчик на Bubble от Skillbox.ru — в программе курса освещаются основные принципы работы с Bubble — мощным конструктором, который позволяет разрабатывать MVP для стартапов и масштабные корпоративные системы управления. Помимо технических аспектов, студенты узнают о практических применениях платформы и современных тенденциях в сфере No-code разработки. Этот курс подойдет тем, кто хочет быстро войти в IT или автоматизировать бизнес-процессы без глубоких знаний программирования.
3. No-code. От идеи до продукта без программиста от Product University — курс разработан для новичков и позволяет освоить создание функциональных продуктов с помощью готовых инструментов, таких как конструкторы и сервисы. Участники научатся быстро и дешево собирать минимально жизнеспособные продукты (MVP), что особенно полезно для стартапов и автоматизации бизнес-процессов. По окончании курса выдается сертификат, подтверждающий полученные навыки.
4. Разработчик web приложений на Bubble от Cyberband Academy — программа обучает созданию приложений без необходимости владения навыками программирования, используя No-code сервисы. Программа включает более 100 лекций и бизнес-модуль, где разбирается стратегия запуска IT-продуктов, а также делается акцент на практическую часть — 80% практики и 20% теории. Среди преимуществ курса отмечается поддержка преподавателей и возможность реализовать проекты, которыми можно гордиться уже во время обучения.
5. Зерокодер на Bubble от ZeroCoder — за два месяца участники смогут разработать маркетплейс на примере Яндекс.Маркета благодаря уникальной методологии обучения, которая помогает легко освоить материал и довести проект до результата. Программа ориентирована на практические задачи, позволяя студентам быстро применять полученные знания для создания реальных приложений за короткий срок..
6. Zero coding от Уральского федерального университета — программа ориентирована на развитие практических навыков для автоматизации бизнес-процессов и разработки приложений с использованием современных платформ. Обучение подходит как для начинающих специалистов, так и для предпринимателей, желающих оптимизировать свои процессы без привлечения программистов. Этот курс — часть дополнительного профессионального образования, направленная на повышение квалификации в сфере IT-технологий.
7. Создание сайтов на Webflow от Uprock School — программа включает освоение основ HTML и CSS, что делает ее одной из самых объемных и насыщенных на рынке. Обучение проходит в комфортном темпе с последовательным изложением материала и поддержкой практики под присмотром опытных преподавателей. Школа также известна тем, что демонстрирует тысячи качественных проектов своих учеников, подтверждая эффективность обучения.
8. Своя зерокод-студия от ZeroCoder — это индивидуальная программа менторства для создания и масштабирования AI-студии премиум-класса. Участники получают доступ к эксклюзивным модулям по нейросетям, промпт-инжинирингу и no-code инструментам, а также консультации с юристами, бухгалтерами и психологами для комплексного развития проекта. Программа подходит тем, кто хочет войти в трендовую нишу AI-разработки с высоким доходом, минимизируя риски за счет экспертного сопровождения.

5 курсов по мобильной разработке на No-code

1. Онлайн-курс по зерокодингу от Onskills — курс по зерокодингу предлагает онлайн-обучение созданию сайтов и приложений без необходимости знания программирования, что делает его доступным для начинающих. Обучение проходит в дистанционном формате с поддержкой квалифицированных наставников, которые помогают освоить материал с нуля. По завершении курса участники смогут претендовать на высокооплачиваемые вакансии в IT-сфере.
2. Мобильные приложения на No-code от Cyberband Academy — курс по разработке мобильных приложений без кода учит создавать приложения уровня Airbnb и Delivery Club за 2 месяца, используя No-code инструменты. В программе студенты работают над реальными проектами, включая запуск приложений в App Store и Google Play, что позволяет им формировать конкурентоспособное портфолио. Обучение проходит под руководством опытных менторов, которые помогают освоить процесс создания MVP за 2–5 недель.
3. Зерокодер мобильных приложений от ZeroCoder — обучающая программа поможет освоить создание мобильных приложений без необходимости писать код, что делает процесс доступным даже для новичков. Курс помогает участникам запустить собственные проекты в App Store и Google Play за 3 месяца, используя популярные no-code инструменты и платформы. Особое внимание уделяется практике: студенты работают над реальными кейсами под руководством экспертов, что позволяет им сразу применять полученные знания на практике.
4. Мобильный разработчик без кода от Code Breakers — программа ориентирована на тех, кто хочет быстро войти в IT-сферу, предлагая практические навыки для разработки приложений, которые могут конкурировать на мировом рынке. Участники курса получают доступ к экспертным материалам и поддержке опытных менторов, что помогает им успешно реализовать свои проекты уже в процессе обучения.
5. Продвинутая программа по мобильным приложениям на FlutterFlow от ZeroCoder — обучение подходит как для начинающих, так и для тех, кто уже имеет базовые знания в No-code разработке, предлагая погружение в процесс создания интерактивных приложений без необходимости углубленного изучения программирования. Участники работают над реальными проектами, которые можно опубликовать в App Store и Google Play, формируя портфолио и развивая навыки, востребованные на рынке IT. Под руководством опытных наставников студенты учатся эффективно комбинировать дизайн, функционал и технологии для запуска качественных мобильных решений.

Бесплатные курсы по No-Code

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

1. Tilda. Как создать впечатляющий сайт без программирования — Bang Bang Education

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

Главное о курсе:

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

2. Зерокодер: разработчик веб и мобильных приложений — Содействие занятости

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

Главное о курсе:

• Фокус на разработку мобильных приложений через No-Code платформы;
• Практические кейсы и примеры из реальной жизни;
• Подходит как для предпринимателей, так и для начинающих разработчиков.

3. NOCODE на Creatium — Creatium

Программа будет полезна тем, кто только начинает свой путь в мире No-Code и хочет освоить базовые навыки создания сайтов и приложений без программирования. На практических примерах вы научитесь работать с платформой Creatium и создадите свой первый проект, который можно использовать для портфолио или бизнеса.

Главное о курсе:

• Погружение в основы работы с Creatium — интуитивной платформой для No-Code разработки;
• Пошаговое создание сайта или лендинга с нуля;
• Акцент на простоту и доступность для новичков.

4. Зерокодинг — новая нефть! — ZeroCoder

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

Главное о курсе:

• Основы создания сайтов на популярных No-Code платформах;
• Практические примеры и пошаговые инструкции для новичков;
• Бесплатный доступ к материалам для самостоятельного изучения.

5. Webflow: Старт — Uprock School

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

Главное о курсе:

• Погружение в платформу Webflow с нуля;
• Создание адаптивных и кросс-браузерных сайтов;
• Практические задания для закрепления навыков.

6. Специалист по zerocoding — Future Prof

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

Главное о курсе:

• Введение в No-Code разработку для начинающих;
• Обзор ключевых платформ и их возможностей;
• Практические примеры для старта в создании проектов.

7. Управление проектами на зерокоде — ZeroCoder

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

Главное о курсе:

• Основы управления проектами с использованием No-Code решений;
• Лайфхаки по организации работы и командной координации;
• Практические советы для реализации проектов любой сложности.

Видеоуроки по No-code

1. No code. Программирование без кода — Клуб дедов-программистов

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

Главное о курсе:

• Просто и понятно для новичков;
• Полный обзор основных технологий;
• Разбор примеров.

2. Все возможности NoCode в одном видео — Игнат Егоров | AppBusters

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

Главное о курсе:

• Краткое обзорное видео;
• Вдохновляющие примеры;
• Описание инструментов.

3. Webflow. Обзор возможностей, подводные камни — Я — зерокодер

Это часовое видео посвящено разбору одного из самых популярных инструментов у ноу-кодеров — Webflow. Много практики и нюансов работы для тех, кто собирается плотно заняться разработкой. Будет полезно как начинающим, так и тем, кто уже изучал предмет самостоятельно.

Главное о курсе:

• Наглядная работа в Вебфлоу;
• Рассказ о возможностях и ограничениях;
• Кейсы использования.

4. Сборка топового сайта на Tilda, без кода — Buddilov | Веб-дизайн Без Воды

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

Главное о курсе:

• Коротко и полезно;
• Не очевидная возможность инструмента;
• Для практиков.

5. Серия вебинаров «Low-code вместо разработки» — ELMA

Небольшой плейлист из пяти обучающих видеоуроков по Low-code. Достаточно подробная проработка сложных тем, таких как документооборот low-code, интеграция бизнес-процессов и кастомизация ECM. Эти вебинары помогут вам глубже погрузиться в тему.

Главное о курсе:

• Длинные подобные видео;
• Просто о сложном;
• Для продолжающих.

Профессия No-Code Разработчик: Создавай Будущее без Кода

No-code разработчик — одна из самых быстро растущих профессий в IT, которая позволяет создавать приложения, сайты и автоматизировать бизнес-процессы без единой строчки кода. Интересный факт: по данным Gartner, к 2026 году более 70% новых приложений будут разрабатываться с использованием no-code/low-code технологий. Это значит, что специалисты, освоившие Zero-coding курсы, становятся ключевыми фигурами на рынке труда.

Деятельность

No-code разработчик создает цифровые продукты, используя визуальные инструменты и платформы. Это могут быть мобильные приложения, лендинги, CRM-системы, чат-боты или даже сложные автоматизированные процессы для бизнеса. Например, вы можете помочь ресторану настроить систему бронирования столов через Telegram-бота или создать маркетплейс для стартапа за пару недель.

Навыки

Для успешной работы важно уметь:

• Работать с популярными no-code платформами (Bubble, Adalo, Airtable, Tilda и др.).
• Понимать основы UX/UI, чтобы создавать удобные интерфейсы.
• Владеть навыками аналитики и автоматизации бизнес-процессов.
• Быть гибким и быстро обучаться новым инструментам.

Где учиться

Освоить профессию можно на zero coding курсах от проверенных онлайн-школ. Например, программы от Skillbox, ProductStar или HSE Inc предлагают как базовые знания, так и углубленные треки для продвинутых специалистов. А если бюджет ограничен, есть бесплатные варианты, которые могут быть не менее полезны для упорных и целеустремленных людей.

Уровень дохода

Зарплаты No-code разработчиков зависят от опыта и сложности проектов:

• Начинающий специалист может получать до 80 000 рублей.
• Опытный разработчик может рассчитывать на зарплату от 100 000 до 150 000 рублей.

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

Заключение

No-code разработка становится одной из самых востребованных профессий в IT-сфере, позволяя создавать приложения и сайты без написания кода. Средняя зарплата специалистов в этой области составляет 120–180 тысяч рублей. No-code курсы открывают доступ к высокооплачиваемой профессии даже для тех, кто не имеет технического образования. При выборе курсов важно обращать внимание на практическую составляющую обучения и отзывы выпускников. Рекомендую начинать с базовых программ, постепенно углубляя знания.

Подборки по схожим темам:

1. Лучшие курсы веб-разработчика
2. Лучшие курсы iOS-разработчиков
3. Лучшие курсы Android-разработчиков
4. Лучшие курсы Golang-разработчиков

А какие No-code курсы проходили вы? Поделитесь своим опытом обучения и результатами — ваш отзыв поможет другим читателям сделать правильный выбор.

А вот несколько статей про C++:

• Модель памяти в языках программирования
• Электронные часы, мультимедийная библиотека SFML для разработки игр на C++
  
• Инструкция к погружению в С++ и более 10 бесплатных ресурсов для начинающих
  

Visual Studio Code. Лидер среди редакторов кода

Бесплатный, универсальный IDE от Microsoft. Поддерживает все языки программирования и Git. Главная особенность — тысячи расширений. Заточен под разработку программных продуктов небольшой и средней сложности, отлично подходит для начинающих разработчиков.

JetBrains IntelliJ IDEA / WebStorm / PyCharm — лучшие IDE для Java, JS, Python

Несколько продуктов в виде профессиональных IDE для конкретных языков: Java, JavaScript, Python. Здесь есть умный анализ кода, который находит ошибки для запуска, много конкретных плюшек для Java, JavaScript, Python. Отлично подходит для больших проектов и тех, кто занимается командной разработкой.

Neovim — для любителей Vim с мощными плагинами

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

Системы контроля версий

Git + GitHub / GitLab / Bitbucket

Git — бесплатный инструмент, который помогает следить за изменениями в коде и работать над проектом вместе с командой. GitHub добавляет удобную автоматизацию (Actions) и популярен для открытых проектов. GitLab хорош для закрытых задач благодаря встроенным инструментам и приватности. Bitbucket легко дружит с JIRA для командной работы. Базовые версии бесплатны, платные — от 3 до 19$ в месяц. GitHub выбирают для опенсорса, GitLab — для секретных проектов, а Bitbucket — для тех, кто уже использует JIRA.

Git Kraken

Удобный интерфейс для работы с Git, где все изменения показаны в виде дерева. Помогает разбираться с конфликтами в коде и видеть историю. Бесплатен для личных проектов, командная версия — 5$ в месяц. Отличный выбор для новичков и тех, кто любит визуальные подсказки.

Лучшие CLI-утилиты для Git

Набор помощников, которые упрощают разработку с Git через терминал. Например, git-extras работает с рутинными задачами, tig показывает историю изменений, а git-flow помогает организовать ветки кода. Всё бесплатное и работает без интернета. Подходит тем, кто хочет ускорить работу и не боится командной строки.

Инструменты для CI/CD

GitHub Actions, GitLab CI/CD — встроенные пайплайны

GitHub Actions помогает автоматизировать сборку и запуск кода — например, чтобы тесты проходили сами после каждого изменения. Бесплатно до 2 тыс. минут для открытых проектов. GitLab CI/CD встроен в GitLab и делает то же самое с 400 бесплатными минутами, плюс больше контроля над процессом. Оба работают прямо с вашим кодом, без лишних программ. GitHub Actions проще для новичков, GitLab CI/CD — для тех, кому важна приватность. Отлично для команд, которые уже сидят на этих платформах.

Jenkins, CircleCI, Travis CI — обзор популярных решений

Jenkins — бесплатный инструмент с открытым кодом, где можно настроить всё под себя. Нужен свой сервер, зато без ограничений. CircleCI ускоряет автоматизацию, но стоит от 15$ в месяц. Travis CI дружит с GitHub: бесплатно для открытых проектов, от 69$ для закрытых. Jenkins берут для сложных задач, CircleCI — для скорости, а Travis — для простых опенсорс-проектов.

ArgoCD и FluxCD — CI/CD для Kubernetes

GitOps-инструменты для Kubernetes. ArgoCD синхронизирует код с кластерами через GUI и поддерживает откаты ошибок. FluxCD легче настраивается и автоматически обновляет образы. Оба бесплатны и работают с Helm. ArgoCD предпочтительнее для команд с опытом в Kubernetes, FluxCD — для небольших проектов с минимальными настройками.

Средства тестирования

Selenium, Cypress — тестирование фронтенда

Selenium — инструмент для автоматизации браузеров через WebDriver. Поддерживает все языки программирования, но требует дополнительных библиотек. Cypress — современное решение на JavaScript с упором на простоту и стабильность тестов. Выполняет тесты в том же цикле событий, что и приложение. Selenium универсальнее, Cypress быстрее и интуитивнее для фронтенд-разработчиков.

JUnit, PyTest, Mocha — тестирование кода

Набор инструментов для тестирования кода. JUnit — популярный выбор для Java, особенно в больших компаниях, где используют Spring; он простой и надёжный для старта. PyTest делает тестирование на Python удобным и понятным, без лишних сложностей. Mocha (часто с Chai) подходит для JavaScript: гибкий, лёгкий, и отлично работает с проектами на фронтенде или бэкенде. Все три встраиваются в автоматизацию и хороши для новичков, которые хотят проверять код без головной боли.

Postman, Newman — API-тестирование

Postman — удобный инструмент, который начинался как способ тестировать API, а теперь помогает создавать запросы, проверять их и даже автоматизировать работу. Newman — его версия для командной строки, чтобы запускать тесты без интерфейса, например, вместе с другими автоматическими задачами. Оба бесплатны для базовых вещей, а командные функции стоят от 12$ в месяц. Postman подойдёт новичкам для ручной проверки API или создания прототипов, а Newman — для автоматического тестирования API в проекте.

DevOps и контейнеризация

Docker и Podman — контейнеры в 2025 году

Docker — стандарт контейнеризации в 2025 году. Упаковывает код с зависимостями в переносимые образы. Бесплатен для локальной работы, командная разработка обойдется в 5$ в месяц. Ограничен в РФ из-за санкций. Podman — безопасная альтернатива без центрального домена, полностью совместим с Docker-командами. Поддерживает rootless-режим и работу с systemd, но имеет меньше обучающих материалов.

Kubernetes — главный инструмент оркестрации

Платформа для оркестрации контейнеров, незаменима для микросервисной архитектуры. Бесплатная, работает локально через Minikube или в облаке (от 10$). Управляет десятками контейнеров через YAML-манифесты, обеспечивает масштабирование и обновление без простоев. Требует опыта и мощного железа, но остаётся лидером для продакшн-окружений.

Terraform и Pulumi — инфраструктура как код

Terraform — бесплатное программное обеспечение, помогает настроить инфраструктуру (серверы, сети, кластеры) через код. Работает локально без платы, а облачная версия стоит от 20$. Подходит для любых облаков и нравится тем, кто хочет держать всё под контролем. Pulumi делает то же самое, но вместо специального языка использует привычные JavaScript, TypeScript или Python. Удобнее для тех, кто уже умеет программировать, хотя сообщество поменьше. Оба хороши для новичков, которые хотят проще управлять инфраструктурой.

Базы данных и инструменты для работы с ними

PostgreSQL, MySQL, MongoDB — что выбрать?

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

MySQL — простая и быстрая база данных, которая хорошо подходит для небольших и средних проектов. Есть бесплатная версия. Легко работает с языками вроде PHP, Python и Node.js, а начать с нее может любой новичок. У MySQL огромное сообщество, где можно найти готовые ответы. По сравнению с PostgreSQL, слабее в сложных задачах, но для старта — отличный выбор.

MongoDB — бесплатная NoSQL-база данных, которая хранит данные в виде JSON-документов, а не таблиц. Облачная версия Atlas стоит от 9$. Она гибкая — не нужно перестраивать структуру, если что-то меняется и запускается одной командой. По сравнению с SQL-базами хуже справляется с транзакциями, зато идеально подходит для быстрых прототипов и стартапов, где требования часто меняются.

Prisma и TypeORM — работа с БД в коде

Prisma — удобный инструмент для работы с базами данных в JavaScript и TypeScript. Поддерживает PostgreSQL, MySQL и MongoDB, помогая быстро писать код для бэкенда. Автодополнение упрощает жизнь, но на сложных задачах может немного тормозить. Отличный выбор для небольших команд, которые делают бэкенд на Node.js.

TypeORM — бесплатный инструмент с открытым кодом для работы с базами данных в JavaScript и TypeScript. Легко дружит с NestJS и Express, помогая связать код с базой. Подходит для средних проектов, где требования могут меняться. Документация не всегда полная, а некоторые функции работают не идеально, но для гибких задач на JS/TS — хороший выбор.

DBeaver, TablePlus — удобные GUI-клиенты

DBeaver — удобный интерфейс для работы с более чем 80 базами данных. Бесплатная версия (Community) доступна всем, платная (Enterprise) — от 11$ в месяц. Есть редактор для запросов с подсказками, возможность видеть структуру базы и выгружать данные. Программа ресурсоёмкая и не работает в РФ без средств обхода. Подходит разработчикам и аналитикам, которые не хотят использовать командную строку.

TablePlus — лёгкий и удобный интерфейс для работы с более чем 10 базами данных. Бесплатная версия позволяет подключаться к двум базам, а полная стоит 59$ единоразово. Интерфейс простой, данные можно выгружать, а старт занимает пару минут. В России для покупки платной версии нужны посредники. Подходит для тех, кто хочет быстро подключиться к базам без лишних наворотов.

Фреймворки и библиотеки

React, Vue, Angular, Svelte — выбор фронтенд-разработчиков

React — бесплатная библиотека для создания динамичных интерфейсов, например, сайтов, которые быстро реагируют на действия пользователя. Она с открытым кодом и включает в себя популярные инструменты вроде Redux и Next.js. У неё огромное сообщество, что даёт гибкость, но новичкам может быть непросто разобраться. Подходит для больших проектов, где команда готова потратить время на обучение.

Angular — фронтенд-фреймворк от Google для создания продуктов со сложными интерактивными интерфейсами. Бесплатный, с открытым кодом, идёт с TypeScript из коробки, что упрощает работу с большими проектами. Встроенные инструменты вроде Angular CLI ускоряют старт, а двусторонняя привязка данных (two-way binding) экономит время на синхронизации. Сообщество большое, документация подробная, но новичкам может быть тяжело из-за обилия концепций. Подходит для тех, кто работает в команде и создает корпоративные приложения, где важны структура и масштабируемость.

Vue — фронтенд-фреймворк с простым и понятным кодом, который помогает быстро создавать интерфейсы. Он лёгкий (всего 20 КБ), включает удобные инструменты вроде Vuex, Pinia и Nuxt для разных задач. Начать с ним проще, чем с React, хотя библиотек поменьше. Отлично подходит для быстрой разработки веб-продуктов.

Svelte — современный фреймворк, который превращает код в быстрый JavaScript. Он простой, не требует лишних сложностей и работает быстрее многих других. Есть SvelteKit для дополнительных возможностей. Код получается компактным, но сообщество и экосистема пока небольшие. Подходит для стартапов и приложений, где важна скорость.

Node.js, Deno, Bun — что актуально в бэкенде

Node.js — классика серверного JavaScript. Он быстро обрабатывает запросы и имеет огромный набор готовых решений через NPM, плюс Express для создания API. С его помощью разрабатывают приложения, где всё обновляется в реальном времени, например, чаты. Экосистема большая, но для задач с высокой нагрузкой процессор может быть слабоват. Отличный выбор для API и реалтайм-проектов.

Deno — безопасная альтернатива Node.js. TypeScript из коробки, изолированный доступ, встроенный пакетный менеджер, Web API. Безопасность по умолчанию, но меньше экосистема. Для современного бэкенда с акцентом на безопасность.

Bun — сверхбыстрый JavaScript-рантайм, в 3—5 раз быстрее чем аналогичные продукты от конкурентов. Встроенные пакетный менеджер и тест-раннер, поддержка TS и NPM. Скоростной, но молодой проект с багами. Для экспериментов и микросервисов.

Spring Boot, Django, FastAPI — лучшие серверные фреймворки

Spring Boot — java-фреймворк для масштабируемых проектов. Автоконфигурация, REST API, JPA, Security, встроенный Tomcat. Spring Cloud для микросервисов. Промышленный стандарт, но требует знания Java и ресурсов. Подходит тем, кто создает enterprise-приложения.

Django — мощный Python-фреймворк, который даёт всё нужное для разработки: от работы с базами до защиты и создания API. Он ускоряет процесс и делает проекты безопасными. Подходит для сайтов и приложений на Python, но для маленьких независимых сервисов может быть сложноват. Хороший выбор для быстрого старта.

FastAPI — современный Python-фреймворк для разработки быстрых API. Он простой, автоматически генерирует документацию к коду и работает шустро. Подходит для задач, требующих высокой производительности, и поддерживает асинхронные запросы, что делает его подходящим для работы с реальным временем (real-time). Админки тут нет, а для работы с реалтайм-функциями лучше иметь небольшой опыт. Отличный выбор для лёгких API и микросервисов на Python.

Приложения с инструментами для командной работы

Slack, Discord, Mattermost — коммуникация в командах

Slack — стандарт для командного общения. Бесплатно можно чатиться с историей сообщений за 90 дней, а платная версия стоит от 7$ в месяц за пользователя. Есть каналы для разных проектов и удобная связь с GitHub, JIRA или Google Drive. Настройка лёгкая, можно даже общаться с клиентами, но в России платные функции недоступны без обхода блокировок. Подходит командам, которые любят чаты и хотят всё держать в одном месте.

Discord — платформа для общения и сообществ. Базовое использование бесплатно, Nitro от $10/месяц. Текстовые и голосовые каналы, боты для модерации, стриминг и шеринг экрана. Отличное качество звука, но мало деловых интеграций. Доступен в виде веб-версии и приложения для всех основных платформ. Подходит для удалённых команд с частыми созвонами.

Mattermost — бесплатный мессенджер с открытым кодом для безопасного общения. Можно установить на свой сервер, облачная версия — от 10$ в месяц. Похож на Slack, но данные хранятся у вас, и есть плагины для связи с другими сервисами. Настройка требует усилий, зато приватность на высоте. Для компаний, которым важно держать всё под контролем.

Notion, Confluence, Obsidian — управление документацией

Notion — гибкий инструмент для хранения документации. Бесплатно до 5 гостей, безлимит — от 8$ в месяц. Можно делать заметки, таблицы и доски задач в одном месте. Удобно для стартапов, работает на всех устройствах, но большие проекты могут тормозить. Есть версии приложения под Android, Windows и IOS. Подходит для команд, которым нужна вся информация в одном месте.

Confluence — корпоративная платформа для документации от Atlassian, стоит от 6$ в месяц за пользователя, бесплатной версии нет. Хорошо дружит с JIRA и помогает организовать записи по проектам. В России оплата через посредников. Для больших команд с чёткими процессами.

Obsidian — бесплатное ПО для заметок. Работает локально, синхронизация — от 4$ в месяц, но тратить на неё средства не обязательно, можно настроить через сторонние плагины. Данные хранятся у вас, есть плагины для допфункций. Не подходит для командной работы. Хорош для личных записей и аналитики.

JIRA, ClickUp, Trello — управление задачами

JIRA — Инструмент для управления задачами, стоит от 7$ в месяц за пользователя, бесплатной версии нет. Подходит для планирования с досками и отчётами, но новичкам может быть сложно. Для профессиональных команд, которые работают по Agile.

ClickUp — универсальный сервис для выполнения задач с бесплатной версией до 100 МБ, полная — от 7$ в месяц. Есть доски, списки и автоматизация. Прост вначале, но функций так много, что можно запутаться. Для команд, которым нужен гибкий инструмент без сложностей JIRA.

Trello — простая система для задач с досками. Бесплатно до 10 досок, дальше — от 5$ в месяц с автоматизацией. Перетаскивайте карточки от «Сделать» к «Готово». Легко и наглядно, но для больших процессов не подходит. Для маленьких команд и простых проектов.

Новые и перспективные инструменты для разработки

AI-кодогенераторы: GitHub Copilot, Codeium, ChatGPT API, Cursor AI, Claude Code, Claude API, Cloud Code от Google

GitHub Copilot — ИИ-помощник, который подсказывает код и проверяет его. Бесплатно для студентов и открытых проектов, иначе — 10$ в месяц. Работает с кучей языков в популярных редакторах, ускоряя работу. Не работает в РФ. Подходит всем, кто хочет писать код быстрее.

Codeium — бесплатная альтернатива Copilot, где безопасность на первом месте. Для бизнеса — от 15$ в месяц. Помогает с кодом и тестами, данные обрабатываются локально. Отличный выбор для команд, которым важна конфиденциальность.

ChatGPT API — инструмент от OpenAI для создания своих ИИ-помощников. Стоит недорого, доступен в России и понимает много языков. Может писать код, объяснять ошибки, но нужно уметь его подключать. Для тех, кто готов копаться в настройках.

Cursor AI — редактор кода с ИИ, похожий на VS Code, но умнее. Подсказывает код, исправляет ошибки и ускоряет работу. Под капотом разные ИИ-продукты от Open AI, Google, Antropic. Простой и быстрый, идеален для новичков, которые хотят писать код без лишней головной боли.

Claude Code — терминальный помощник от Anthropic для автоматизации кодирования. Необычный подход к разработке в сравнении с конкурентами. Работает через командную строку, ищет код, правит файлы и пушит в GitHub. Бесплатен в preview, безопасен. Подходит тем, кто хочет ускорить рутину и не боится терминала.

Claude API (3.7 Sonnet) — лучший ИИ для кодинга по мнению автора статьи. Версия 3.7 Sonnet пишет код, чинит баги и думает над задачами. Во многих сценариях превосходит Chat GPT. Стоит от 3$ за миллион токенов, не работает в России. Для тех, кто хочет мощный ИИ в своём проекте, но готов разобраться с подключением.

Cloud Code от Google — плагин для VS Code от Google, чтобы писать код для их облака. Помогает с настройкой серверов и приложений, вроде Kubernetes. Бесплатен с аккаунтом Google Cloud. Подходит новичкам, которые начинают с облачных проектов и хотят всё делать в одном месте.

Инструменты Low-Code / No-Code для ускорения разработки

Betty Blocks — Low-Code платформа для создания своего программного продукта. Всё делается через визуальный редактор с готовыми шаблонами, плюс есть упор на безопасность. Её используют большие компании вроде Clifford Chance. Подходит для сложных задач, стоит от 1050$ в месяц, не очень дружелюбна для новичков. В основном для корпораций с хорошим бюджетом.

Bubble — No-Code инструмент для разработки веб-приложений. Можно перетаскивать элементы, использовать шаблоны. Есть бесплатный тариф. Легко начать, но большие проекты могут тормозить. Отличный выбор для стартапов и одиночек, которым нужен прототип.

Zapier — No-Code для автоматизации. Соединяет 7000+ приложений через простой конструктор, стоит от 19.99$ в месяц. Удобно для экономии времени, но дополнительные настройки могут поднять цену. Для тех, кто хочет объединить разные сервисы.

Softr — No-Code платформа с привязкой к Airtable. Шаблоны простые, настройка быстрая, цена от 49$ в месяц. Дружелюбный для новичков, есть поддержка, но сложные приложения не потянет. Подходит фаундерам и менеджерам без технических навыков.

Glide — No-Code для разработки приложений из таблиц, вроде CRM или дашбордов. Стоит от 69$ в месяц, быстро собирается. Удобно для малого бизнеса, но для продвинутых задач слабоват. Хорош для простых нужд.

Caspio — Low-Code с ИИ, в котором создают облачные приложения. Большой акцент на защите данных, цена от 100$ за пользователя в месяц. Подходит для больших систем, но стартапам будет не по карману. Для профессионалов, которым важна безопасность.

UiPath RPA — Low-Code для автоматизации рутины. Упрощает разработку благодаря ИИ. Цена индивидуальная, зависит от запроса. Хорошо подходит для ниш со здравоохранением и финансами. Настройка сложная и недешёвая. Понадобится отраслям, где много повторяющихся задач.

OutSystems — Low-Code для корпоративных проектов. Поддерживает визуальную разработку ПО для крупных систем. Цена индивидуальная. Для разработчиков и больших компаний.

Лучшие новые технологии, которые могут выстрелить в 2025 году

BlueQubit

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

Блокчейн: Polkadot, Solana, Truffle

Платформы для приложений без центра управления. Polkadot и Solana делают их быстрыми и масштабируемыми, Truffle упрощает работу с кодом. Безопасно и прозрачно для финансов или логистики, но нужен опыт. Хорош для финтеха и стартапов, которые смотрят на Web3.

Edge-вычисления: Apache Edgent, Azure IoT Edge

Обработка данных прямо там, где они появляются. Edgent — лёгкий и простой, Azure IoT Edge — для умных устройств. Быстро работает, например, для беспилотных машин, но настройка требует времени. Для разработчиков IoT и небольших сервисов.

IoT: Arduino, Raspberry Pi

Популярные платформы для разработки умных устройств. Они поддерживают современные технологии для связи (например, Wi-Fi, Bluetooth) и обеспечивают базовые механизмы защиты данных. Arduino и Raspberry Pi доступны по цене, гибки в настройке и отлично подходят для проектов умного дома. Однако для сложных систем с высокой нагрузкой они могут быть недостаточно мощными. Эти платформы идеальны для энтузиастов, хоббистов и небольших IoT-проектов.

Кибербезопасность: SAST, DAST

Инструменты для защиты кода. SAST ищет ошибки до запуска, DAST — во время работы с помощью ИИ. Спасают от атак и нужны в продакшене, но требуют частых обновлений. Для всех, кто работает с данными.

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

«Я думаю, что могу смело утверждать: квантовую механику не понимает никто».

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

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

Определения и квантовая путаница

Кубиты

Квантовые вычисления строятся на основе кубитов. Они существуют как физические объекты. Законы квантовой механики проявляются на фотонах, электронах, ионах, атомах.

Самое интересное — если обычный бит принимает значение 0 или 1, то кубит находится в суперпозиции. Его состояние описывают диапазоном от 0 до 1, и оно непрерывно меняется.

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

Квантовая запутанность

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

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

Квантовый брутфорс

Битами классических компьютеров управляют логические операторы — И, ИЛИ, НЕ.

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

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

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

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

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

Он — компьютер, но квантовый

Есть мнение, что квантовый компьютер (КК) вовсе не компьютер, потому что выдает не точный, а приблизительный ответ.

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

Справедливое замечание: без классического компьютера квантовые вычисления — бесполезны.

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

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

Как квантовые вычисления повлияют на программирование

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

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

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

Машинное обучение тоже выигрывает от развития квантовых вычислений. Скорость обучения нейросетей увеличится в разы.

Классические алгоритмы vs квантовые алгоритмы

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

Например, алгоритм Шора. Он раскладывает числа на множители, но работает только на квантовом компьютере.

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

• Для числа размером 2 цифры — очень легко.
• Для числа размером 10 цифр — сложнее, но реально.
• Для числа размером в 300 цифр (как в RSA-криптографии) — может занять тысячи лет.

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

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

В списке из 1000 элементов обычный компьютер проверит до 1000 записей. Алгоритм Гровера проверит всего √1000 ≈ 31 запись.

Нужны ли новые языки программирования?

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

Qiskit

Разработчик: IBM

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

Cirq

Разработчик: Google

Библиотека на Python для создания и тестирования технологий квантового вычисления. Cirq чаще используют для работы с алгоритмами Гровера, Шора и др. Программу можно протестировать на симуляторе.

Q#

Разработчик: Microsoft

Q# — это часть Microsoft Quantum Development Kit (QDK). Он содержит инструменты для симуляции, разработки программ и интеграции квантовых вычислений с кодом на C# или Python.

Какая математика потребуется разработчикам?

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

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

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

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

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

Когда начинать изучать квантовые вычисления?

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

Уходить сегодня из фронтенда в разработку квантовых программ — это как создавать ИИ в 80-х годах.

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

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

Какие компании уже инвестируют в квантовые вычисления?

IBM — лидер в разработке квантовых технологий. Их платформа IBM Quantum Experience предоставляет доступ к настоящим квантовым компьютерам через облако.

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

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

Microsoft раньше других взялась за развитие языка программирования для квантовых вычислений — Q#. Вместе с этим доступен Quantum Development Kit, который моделирует квантовые программы и тестирует на симуляторах.

Amazon тоже не осталась в стороне. Компания предлагает облачный сервис AWS Braket, интегрирующий работу с квантовыми симуляторами.

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

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

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

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

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

Инструменты и платформы для начала работы

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

IBM Quantum Experience и Qiskit

IBM Quantum Experience — это облачная платформа. Она поддерживает запуск кода на реальном квантовом компьютере — 5-кубитном IBM Quito. Платформа содержит учебные курсы, в том числе серию статей по основам квантовой механики.

Чтобы программировать кубиты, зарегистрируйтесь на IBM Quantum Experience и познакомьтесь с библиотекой Python Qiskit.

Пример квантовой схемы:

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

Google Cirq

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

Особенности:

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

Пример квантовой схемы:

Чтобы использовать физический процессор, нужно подключиться к облаку Google Quantum.

Microsoft Q#

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

Для работы с Q# понадобится Quantum Development Kit, .NET, расширение для Visual Studio или VS Code.

Простая программа на Q#:

Код выполняется через симулятор, встроенный в QDK.

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

Симуляторы

Чтобы лучше понять работу квантовых вычислений, стоит начать с симуляторов:

• IBM Aer. Входит в состав Qiskit, имитирует шумовые и идеальные квантовые процессы.
• Google Cirq’s Simulator. Интегрирован в библиотеку Cirq, поддерживает широкий спектр квантовых операций.
• Microsoft Quantum Simulator. Разработан для работы с Q#, позволяет запускать программы и тестировать квантовые алгоритмы.
• QuTip. Библиотека Python для работы с квантовыми системами, поддерживает симуляцию квантовых состояний, унитарных операций и вычислений.

Если вы новичок — используйте Qiskit + IBM Aer.

Любите низкоуровневое программирование? Google Cirq — ваш выбор.

Чувствуете, что вам нужен язык высокого уровня с интеграцией в классические приложения? Тогда изучайте Q# + Microsoft Quantum Simulator.

Что в итоге?

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

IBM, Microsoft и Google развивают экосистемы для новых специалистов. Есть симуляторы и обучающие материалы. Они немного облегчают вход в эту сферу.

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

Рекурсия: что это такое и зачем нужна

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

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

В виде кода это выглядит так:

Здесь функция F вычисляет факториал числа n, умножая его на факториал n-1, и так до тех пор, пока не дойдёт до 1, после чего начнёт возвращать результаты вверх по цепочке вызовов. Этот пример как раз о том, что нужно выполнить несколько одинаковых действий.

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

Принципы работы рекурсии

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

Базовый случай

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

Один из самых простых примеров — факториал, о котором мы писали выше. Другой — возведение числа в степень до тех пор, пока значение не станет равно искомому.

Так это выглядит в виде кода:

То есть, базовый случай — если exponent == 0, то возвращаем 1.

Рекурсивный вызов

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

Числа Фибоначчи — это последовательность, где каждое число равно сумме двух предыдущих: 0, 1, 1, 2, 3, 5, 8, 13, 21, …

Если вызвать fibonacci(5), то увидите следующее:

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

Кстати, на примере чисел Фибоначчи можно разобрать одну из проблем рекурсии — плохая производительность при отсутствии мемоизации.

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

Так, функция в задаче с числами Фибоначчи имеет экспоненциальную сложность O(2^n), так как она многократно вычисляет одни и те же значения. Например, чтобы вычислить fibonacci(5), функция вызывает сама себя 15 раз, хотя уникальных вычислений всего 6.

Чтобы улучшить производительность, нужно использовать мемоизацию, чтобы сохранить результаты:

Здесь сложность уменьшается до O(n), так как каждое значение вычисляется только один раз.

Стек вызовов и управление памятью

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

Например:

Так, когда мы вызываем сountdows(3), в стеке появляются новые вызовы:

call countdown(3) # → печатает 3

call countdown(2) # → печатает 2

call countdown(1) # → печатает 1

call countdown(0) # → печатает "Старт" и выходит

Затем стек начинает разворачиваться:

• countdown(0) завершился → удаляется из стека
• countdown(1) завершился → удаляется из стека
• countdown(2) завершился → удаляется из стека
• countdown(3) завершился → удаляется из стека

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

Вот пример бесконечной рекурсии:

В Питоне есть ограничения до 1000 вызовов, чтобы не перегружать стек, но этот лимит можно увеличить:

Рекурсия на реальных задачах

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

Обход структуры данных

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

1. Прямой обход (Pre-order): Корень → Левый узел → Правый узел.
2. Симметричный обход (In-order): Левый узел → Корень → Правый узел.
3. Обратный обход (Post-order): Левый узел → Правый узел → Корень.

Запишем в виде кода:

Дерево будет выглядеть так:

1

/ \

2 3

/ \

4 5

• Прямой обход: 1 → 2 → 4 → 5 → 3.
• Симметричный обход: 4 → 2 → 5 → 1 → 3.
• Обратный обход: 4 → 5 → 2 → 3 → 1.

Обходить можно и графы, особенно в глубине (DFS). Вот пример:

Сам граф:

Результат обхода: A → B → D → E → F → C.

Разбиение

Разбить можно массив или строку. Давайте разбираться на примере строки. Так, рекурсия может разбить строку на слова или разделить ее по конкретным символам. Выглядит это так:

Что такое хвостовая рекурсия

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

Вот пример:

Кстати, с помощью хвостовой рекурсии тоже можно решать задачи с числами Фибоначчи:

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

Давайте посмотрим, как это работает в Scala. Вот обычная рекурсия, чтобы понять принцип:

А вот рекурсия с оптимизацией:

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

Это пример итеративного решения факториала.

Рекурсия vs. итерация

Основные различия между рекурсией и итерацией заключаются в следующем:

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

Итерацию лучше использовать в следующих случаях:

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

• Задачи с большой глубиной рекурсии, чтобы стек не переполнялся. Вот как итеративно обойти дерево:

Еще один пример: задача «Ханойские башни»

«Ханойские башни» — классная головоломка, которую часто решают с помощью рекурсии. Считайте, что это еще одна классика.

Есть три стержня: A, B и C. На стержень A нанизано несколько дисков разного размера, причем диски упорядочены по размеру в виде пирамидки — вниз от маленького к большому. Суть в том, чтобы переместить все диски со стержня А на С, при этом: за один раз можно перемещать только один диск, нельзя класть больший диск на меньший, можно использовать стержень B как вспомогательный.

Рекурсивное решение задачи «Ханойские башни» основано на следующей идее:

1. Переместить (n−1) дисков с A на B, используя C как промежуточный.
2. Переместить оставшийся самый большой диск с A на C.
3. Переместить (n−1) дисков с B) на C, теперь используя A как промежуточный.

Следовательно, если количество дисков n=1, просто переместите его с А на С (базовый случай). В остальных случаях при n–1 повторить то, что указано выше.

А теперь решение с помощью кода:

Вывод:

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

Мы собрали топ-10 малоизвестных и относительно новых языков программирования, которые с высокой долей вероятности могут стать популярными в профессиональной среде.

Критерии отбора языков

Каждый язык остается востребованным, пока им пользуются для написания кода. Например, COBOL, который появился еще в середине прошлого века, до сих пор применим в банковской системе США, а Fortran — в прикладной математике.

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

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

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

Технологический прогресс

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

• Искусственный интеллект. Для разработки таких технологий и управления ими нужны языки, способные продуктивно работать со сложными алгоритмами, массивами данных и параллельными вычислениями.
• Квантовые технологии. Новые архитектурные концепции могут «заставить» нас использовать абсолютно непривычные языки.
• Мобильные устройства и IoT. Эта отрасль задает тренд на развитие легких по структуре и более производительных языков, которые работают со встраиваемыми системами.
• Аппараты. Распространение многоядерных процессоров и распределенных по разным компьютерам систем повышает потребность в языках программирования, поддерживающих параллелизм.
• Блокчейн. Да, чтобы проводить смарт-контракты и писать децентрализованные приложения, привычных языков может быть недостаточно.

Отраслевые потребности

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

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

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

Тренды в сообществах разработчиков

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

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

Топ-10 языков программирования

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

Zig

Этот язык в последнее время стал одним из самых обсуждаемых в профессиональном сообществе. В популярных профильных изданиях его даже называют «новой звездой на небосводе современной разработки».

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

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

Основные плюсы:

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

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

Код на Zig выглядит следующим образом:

Пример проекта на Zig — репозиторий Zig-gamedev для разработки игр на этом языке.

Готовый продукт, созданный на основе модулей библиотеки — фэнтезийная игра от первого лица и с открытым миром Tides of Revival.

Crystal

Язык с Ruby-подобным, предельно простым синтаксисом и высокой производительностью. Как и Zig, он статически типизирован и компилируем. Объединяет ясность и простоту Ruby с эффективностью и скоростью C.

В числе главных преимуществ Crystal:

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

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

Примеры сервисов, созданных на Crystal:

• Kinko booking — платформа для бронирования гостиниц в туристических агентствах в режиме реального времени;
• Eat App — облачные приложения автоматизации для ресторанного бизнеса, повышающие эффективность работы предприятий;
• Nabobil.no — европейский каршеринг.

Пример кода наглядно демонстрирует лаконичность Crystal:

puts “Hello World!”

Elixir

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

Главные плюсы:

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

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

Код тоже предельно лаконичен:

IO.puts(“Hello, World!”)

На Elixir создан фреймворк Phoenix, который содержит модули для разработки быстро масштабируемых приложений.

Nim

Этот статически-типизированный и компилируемый язык развивает концепции Ada, Modula, Python, но стремится превзойти их по эффективности и выразительности.

Основные преимущества:

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

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

Код на Nim с последующим компилированием:

Самые известные фреймворки на Nim — это Jester и Karax. Первый используется для серверной разработки, второй — для клиентской. Обе библиотеки есть в свободном доступе на GitHub.

F#

Функционально ориентированный язык, работающий на базе экосистемы .NET — кроссплатформенной среды для разработки приложений.

Преимущества F#:

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

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

В плане лаконичности F# вполне сравним с предыдущими примерами:

printfn “Hello, world!”

Giraffe — популярная библиотека на F# для разработки веб-приложений с высокой производительностью и безопасностью.

Еще один полезный фреймворк на этом языке — Saturn.

Julia

Высокопроизводительный и высокоуровневый язык с динамической типизацией. Изначально создавался для сложных математических вычислений и анализа данных. Объединяет скорость C++ и простоту Python.

Плюсы Julia:

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

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

Простой сценарий на Julia выглядит так:

Примеры библиотек на Julia для научных разработок по астрофизике JuliaAstro, JuliaSpace, по биологии и химии: JuliaBio, Molecular simulations, по экономике: QuantEcon, JuliaQuant.

Scala

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

Преимущества:

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

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

Код на Scala:

@main def hello() = println(“Hello, World!”)

Библиотека Scala.js компилирует этот язык в JavaScript. Этого инструмента достаточно, чтобы начать разработку с объектно-ориентированным подходом.

Red

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

Ключевые преимущества:

• простота синтаксиса, легкость в освоении и использовании делают Red идеальным инструментом для начинающих программистов;
• несмотря на минималистичность, язык обладает мощью и гибкостью, что позволяет использовать его для приложений любого уровня сложности;
• есть множество GUI-библиотек, которые существенно упрощают написание кода на Red.

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

Код на Red:

На Red написан проект SmartXML, предназначенный для хранения и передачи структурированных данных. Он также поддерживает вычисления с большими числами и используется в прикладной математике.

Ballerina

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

Плюсы Ballerina:

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

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

Код на Ballerina выглядит следующим образом:

На языке, в частности, написано расширение Choreo для создания, развертывания и тестирования облачных приложений непосредственно из редактора Visual Studio Code.

Solidity

Высокоуровневый язык, разработанный для виртуальной машины Ethereum. Функционирует на основе блокчейна и смарт-контрактов. Синтаксис Solidity напоминает Python, при этом язык основан на принципиально иных концепциях.

Плюсы Solidity:

• позволяет быстро и эффективно создавать смарт-контракты, не испытывая технических сложностей;
• относительно прост для освоения для тех, кто знаком с Python и Java.

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

Создание смарт-контракта на Solidity выглядит так:

На Solidity работают децентрализованные проекты типа Uniswap и Compound, где можно брать кредиты в крипте без посредников, а также NFT-маркетплейсы OpenSea и Rarible.Игра Cryptokitties для покупки, разведения и продажи виртуальных кошек тоже написана на этом языке.

Как выбрать язык для изучения

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

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

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

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

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

А если хотите изучить хотя бы один из языков (или просто присматриваетесь) — все самые полезные инструменты тут

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

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

Проблемы BorrowedBuf

Однако BorrowedBuf вызывает множество нареканий. Основные из них:

1. Совместимость с существующим кодом: BorrowedBuf требует поддержки со стороны API, таких как read_buf. Если её нет, Rust будет заполнять буфер нулями, сводя на нет всю оптимизацию. Это вызывает проблемы с библиотеками, которые не обновлялись или больше не поддерживаются, например hex или base64.
2. Отсутствие универсальности: функция работает только с u8. Это ограничивает его использование в библиотеках, таких как rand, которые оперируют разными типами данных.
3. Сложность использования: BorrowedBuf требует глубокого понимания, чтобы избежать ошибок. Например, неправильное использование может привести к тому, что буфер всё равно будет инициализироваться, несмотря на видимую оптимизацию.
4. Логическая путаница: Модель BorrowedBuf разделяет память на инициализированные и неинициализированные части, что делает её сложной для понимания. Аналогия с Vec могла бы сделать API более интуитивным.

Возможные альтернативы

Идеальная альтернатива BorrowedBuf пока не найдена. Одно из предложений — замораживание (freeze) неинициализированной памяти, что позволило бы безопасно работать с ней, как с инициализированной.

Однако это потребовало бы изменений в языковых семантиках Rust, включая механизмы управления страницами памяти (например, MADV_FREE).

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

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

После голосования в LinkedIn, он выбрал тему и за 5 месяцев создал книгу.

Почему самиздат

Автор решил не обращаться к издательствам, а выпустить книгу самостоятельно. Такой подход позволил сохранить творческую свободу и получить больше дохода с продаж — до 80-90% от электронных книг.

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

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

Что получилось

С момента публикации книга была продана в количестве 810 копий, из которых 728 — электронные. Автор заработал более $11 000, потратив около $1 000 на редактирование и ещё немного на маркетинг. Читатели высоко оценили труд, поставив ему рейтинг 4.83 на Goodreads.

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

Мир 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 или С++ (последний особенно актуален для проектов в сфере интернета вещей).

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

Однако, по словам эксперта, это ощущение — всего лишь иллюзия, которая мешает профессиональному развитию.

Главное — не обесценивать свои успехи

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

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

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

Сравнивайте себя с собой, а не с другими

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

Автор подчёркивает: нужно обращать внимание на собственный рост, а не на достижения окружающих.

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

Ошибки — это нормально

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

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

Я у мамы не программист (и не смог бы за 7 дней): Почему?

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

Объем изучаемого материала ну очень велик

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

Например, в спецификации Python 3.9 описано более 30 различных операторов, 15 встроенных типов данных, 25 ключевых слов, более 70 встроенных функций и множество других элементов. Более сложные языки, такие как C++, Java или Rust, имеют еще больший объем материала.

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

P.s. Не забываем, что спецификации языков периодически обновляются (не Python, конечно, но все же). Это также накладывает временной отпечаток на обучении.

Нужна практика не только в кодинге (но и в нем тоже)

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

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

Фундаментальные концепции (WHAT?)

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

Например, при изучении ООП программист должен разобраться в таких понятиях, как классы, объекты, наследование, полиморфизм, инкапсуляция. Это не просто запоминание синтаксиса, а понимание фундаментальных принципов. В функциональном программировании важно освоить концепции — чистые функции, иммутабельность данных, рекурсия и т.д.

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

Нужно не тыкать в небо, а понимать контекст языка

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

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

Java, в свою очередь, применяется для разработки приложений, распределенных систем, игр. Понимание особенностей этих сфер и соответствующих инструментов (Spring, Android SDK, JEE) важно для эффективного использования Java.

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

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

Как реально выучить язык программирования за 7 дней? Запоминаем

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

День 1:

– Подъем в 5 утра, ледяной душ.

– 6:00-8:00 — установка Python и IDE, чтение 100 страниц документации.

– 8:00-8:30 — завтрак стоя, параллельно повторяем изученное.

– 8:30-13:00 — интенсивное изучение синтаксиса, типов данных, операторов. Ни минуты отдыха.

– 13:00-13:10 — обед всухомятку.

– 13:10-18:00 — практика написания алгоритмов с использованием циклов и условий. Перерывы только в туалет.

– 18:00-18:05 — ужин за 5 минут, не отходя от компьютера (надо решить заранее, кто приготовит или доставит вам столько еды)

– 19:00-22:00 — просмотр 10 видеоуроков на скорости 1,5x.

– 22:00-23:00 — повторение, закрепление материала.

– 23:00 – 04:30 — сон

День 2:

– Подъем в 4:30 утра, обливание ледяной водой (можно почистить зубы).

– 5:00-10:00 — изучение коллекций данных, не отвлекаясь ни на что.

– 10:00-10:10 — завтрак всухомятку.

– 10:10-16:00 — погружение в ООП, написание множества маленьких проектов.

– 16:00-16:30 — обед у компьютера. Повторяем изученное.

– 16:30-22:00 — изучение модулей и стандартной библиотеки. Перерывы — 5 минут каждый час.

– 22:00-23:00 — просмотр дополнительных видео.

– 23:00-0:00 — повторение, закрепление.

– 0:00-4:00 — сон.

День 3:

– Подъем в 4 утра, обливание ледяной водой.

– 4:30-10:00 — изучение работы с файлами, обработкой исключений.

– 10:00-10:02 — завтрак в 2 минуты.

– 10:02-16:30 — погружение в Numpy, Pandas, Matplotlib. Ни минуты отдыха.

– 16:30-17:00 — обед у компьютера.

– 17:00-22:00 — практика применения библиотек в своих программах. Перерывы — 2 минуты каждый час.

– 22:00-23:00 — повторение, закрепление.

– 23:00-3:30 — сон.

День 4:

– Подъем в 3:30 утра, обливание ледяной водой.

– 4:00-10:00 — изучение работы с базами данных (SQLite, PostgreSQL). Перерывы — 1 минута каждый час.

– 10:00-10:20 — завтрак у компьютера.

– 10:20-16:30 — практика CRUD-приложений для работы с БД. Перерывы — 30 секунд каждый час.

– 16:30-16:31 — обед в 1 минуту.

– 16:31-22:00 — создание простого Web-приложения на Flask. Никаких перерывов.

– 22:00-23:00 — повторение, закрепление.

– 23:00-3:00 — сон.

День 5:

– Подъем в 3 утра, обливание ледяной водой.

– 3:30-10:00 — углубление в работу с Flask, создание RESTful API. Перерывы — 30 секунд каждый час.

– 10:00-10:20 — завтрак у компьютера.

– 10:20-16:30 — изучение asyncio и aiohttp. Ни минуты отдыха.

– 16:30-16:50 — обед у компьютера.

– 16:50-22:00 — практика написания асинхронных приложений. Никаких перерывов.

– 22:00-23:00 — повторение, закрепление.

– 23:00-2:30 — сон

День 6:

– Подъем в 2:30 утра, обливание ледяной водой.

– 2:30-10:00 — погружение в тестирование (unittest, pytest). Перерывы — 15 секунд каждый час.

– 10:00-10:30 — завтрак на скорую руку.

– 10:30-16:30 — практика написания тестов для своих приложений. Никаких перерывов.

– 16:30-16:30 — обед в 30 секунд.

– 16:30-22:00 — рефакторинг и оптимизация написанных программ. Ни минуты отдыха.

– 22:00-23:00 — повторение, закрепление.

– 23:00-2:00 — сон

День 7:

– Подъем в 2 утра, обливание ледяной водой.

– 2:30-10:00 — создание итогового проекта, применение всех изученных навыков. Перерывы — 10 секунд каждый час.

– 10:00-10:10 — завтрак у компьютера.

– 10:10-16:30 — доработка и тестирование итогового проекта. Никаких перерывов.

– 16:30-16:30 — обед в 20 секунд.

– 16:30-22:00 — подведение итогов, планирование дальнейшего обучения. Ни минуты отдыха.

– 22:00-23:00 — финальное повторение, закрепление.

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

Советы по изучению языков программирования

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

Читайте документацию

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

Например, при изучении JavaScript, почитайте документацию MDN Web Docs, где подробно описаны все возможности языка, от основ синтаксиса до продвинутых API. Это поможет вам найти ответы на любые вопросы, которые могут возникнуть в процессе обучения.

Начинайте с небольших задач

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

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

Используйте отладчики и инструменты

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

Например, в Visual Studio Code есть встроенный отладчик, который позволяет пошагово выполнять код и наблюдать за переменными. А линтер pylint поможет находить стилистические и логические ошибки в Python-коде.

Нетворкайте

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

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

Используйте техники запоминания

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

Так, для запоминания основных принципов ООП в Java (инкапсуляция, наследование, полиморфизм) можно использовать акроним «ИНП».

Читайте качественный код

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

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

Следите за новостями

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

Например, подпишитесь на блоги ведущих разработчиков или почитайте новости на сайтах, посвященных программированию (Habr, DEV, Medium, ну и Tproger, конечно).

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

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

Что можно найти на распродаже?

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

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

В подборку попали такие проекты, как Autonauts, The Signal State и Alan's Automation Workshop, каждый из которых предлагает уникальный подход к механикам автоматизации и инженерии.

Тематическое мероприятие в честь Ады Лавлейс

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

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

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

Цель и назначение

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

ЖС был испытан на детях. Дети 12+ лет легко осваивают этот язык приблизительно за три месяца, занимаясь два раза в неделю и создавая на нем сайты или 2D-игры.

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

Название ЖивоСкрипт (JivoScript) происходит от предыдущего названия языка JavaScript — LiveScript. На стороне сервера JavaScript по задумке авторов должен был называться LiveWire. В ЖивоСкрипте реализована изначальная идея разработчиков — на нём можно писать код для клиента и сервера.

Эту статью можно использовать как краткий самоучитель визуального программирования. Преподаватели визуального или веб-программирования легко поймут, как всё это работает.

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

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

Структура программы, терминология и дизайн

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

Операторы выполняются сверху вниз.

Пример визуального кода:

Программа состоит из четырёх типов операторов:

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

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

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

Также есть возможность группировать операторы в отдельную именованную последовательность и писать комментарии. Но это не операторы:

Пустой комментарий используется как разделитель абзацев кода.

Именованная последовательность — не настоящая последовательность (внутри настоящей есть своя область видимости адресов), а просто группа, папка, которую можно раскрыть или скрыть как этот спойлер-аккордеон:

При выделении последовательности её граница окрашивается в белый цвет.

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

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

Редактор можно использовать на большом сенсорном экране (но не на смартфоне). Всё управление производится через клик мыши или прикосновение пальца и через внешнюю клавиатуру. Для редактирования текста курсор не используется.

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

Адреса и значения

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

В текстовом виде оператор связывания это знак =

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

При нажатии на кнопку со знаком = в операторе связывания, этот оператор изменяется на оператор сложения, вычитания, деления и тд. При этом адрес, указанный в левой части, изменяется на указанное в правой части значение.

Специальные слова (литералы) это:

• да (true)
• нет (false)
• ничего (null)
• неопределённо (udefined)

Адреса бывают пользовательские — их создаёт программа, и готовые системные.

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

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

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

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

Адреса могут быть короткими однословными, как например адрес s, или длинными многословными, например s.w[0]('r').d

Для создания многословных адресов используйте эти кнопки:

Для вызова подпрограммы используйте элемент Выполнить

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

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

Множество адресов могут ссылаться на одно значение.

В этом примере адрес s связан с подпрограммой. Адрес w связан со значением адреса s

При вызове подпрограммы показать_объявление показывается одно единое значение для адресов w и s

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

В выражениях используются следующие операторы:

• или: ||
• '+' сложение строк: + в JavaScript или . в PHP
• плюс: +
• минус: -
• деление: /
• остаток от деления: %
• умножение: *
• возведение в степень: **
• скобки: ( )

При использовании оператора ИЛИ в правой части оператора связывания, адрес в левой части связывается с первым истинным значением из перечня значений.

Истинные значения это:

• не нулевое число
• непустая строка
• да (true)
• объект, массив, подпрограмма

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

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

При повторном нажатии на оператор «создать адрес» тип адреса изменяется. Есть три возможных варианта: let const var

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

Оператор const похож на let, но используется для неизменяемых значений.

Оператор var — адрес для всей подпрограммы, он создаёт адрес внутри последовательности операторов подпрограммы из любого места этой подпрограммы, или если он используется в основной последовательности операторов программы, то он создаёт адреса в глобальной области видимости.

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

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

Удалить адрес в объекте или массиве можно через оператор Удалить

Удалить можно только адреса внутри объектов или массивов.

Область видимости адреса

Адрес, созданный операторами let или const, доступен внутри последовательности и из вложенных в неё последовательностей.

Из последовательности невозможно обратиться к адресу, который создан операторами let или const внутри вложенной в неё последовательности. При выполнении этой программы будет показано сообщение об ошибке:

При использовании оператора var в этом случае такой ошибки не будет.

Оператор var можно использовать повторно для того же адреса, в отличие от let и const

Подпрограммы

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

При запуске подпрограммы вызвавшая её программа приостанавливается на время выполнения вызываемой подпрограммы.

Подпрограмма может завершиться в любой момент при выполнении оператора выхода из подпрограммы — для этого используется оператор Выйти

Процедуры и функции

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

Если оператор Выйти возвращает значение то он превращается в оператор Вернуть

Подпрограмма может иметь входящие адреса (параметры), и при вызове подпрограммы ей передаются значения (аргументы).

Объекты и массивы

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

Внутри объекта есть своя последовательность операторов связывания.

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

Массив похож на объект, но в нём доступ к значениям производится не через имена, а по индексу (номеру), начиная с нуля.

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

Ветвление

Ветвление — исполнение или не исполнение одной из последовательностей операторов в зависимости от условия.

Логическое ветвление

Логическое ветвление исполняет или не исполняет одну из двух или единственную последовательность операторов в зависимости от условия. Если в условии истинное значение то исполняется последовательность операторов:

В тексте логическое ветвление обозначается словами if (если) и else (иначе).

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

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

Условий может быть несколько и между ними располагаются операторы И ИЛИ

При использовании оператора И все условия должны быть истинными, а при ИЛИ хотя бы одно условие должно быть истинным.

Ветвление вариантов

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

Попытка

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

Циклы

Цикл — многократное повторное исполнение одной последовательности операторов.

Цикл «Делай пока»

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

Цикл «Пока делай»

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

Цикл числа

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

Число должно быть целым и положительным.

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

Цикл объекта

В этом цикле последовательность операторов исполняется столько раз, сколько свойств в объекте связанном с адресом объект

В этой программе в объявлениях показываются значения свойств объекта:

В этой программе показываются все адреса объекта. Адрес s, используемый в цикле, содержит имена свойств объекта.

Цикл массива

В этом цикле последовательность операторов исполняется столько раз, сколько элементов в массиве, связанном с адресом массив

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

В этой программе в объявлениях показываются значения элементов массива:

Чем различаются JS и PHP в ЖивоСкрипте

В PHP не нужно использовать операторы создания адреса let var const — достаточно просто указать адрес. Он соответствует адресу, созданному оператором var

В тексте PHP-программы все адреса должны начинаться с символа $, но в ЖС не нужно это прописывать каждый раз — редактор сделает все автоматически.

В PHP обращение к многоcловным адресам производится только через квадратные скобки, например, так:

Знак для соединения строк в текстовом виде в JavaScript это символ +, а в PHP это .

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

Практика

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

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

При нажатии на кнопку «выполнить js-программу» в верхнем меню на экране появится это:

Добавим поле, в котором будут располагаться строки:

Теперь интерфейс выглядит так:

Добавим подпрограмму, которая будет исполняться при нажатии на кнопку:

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

Каждому новому созданному элементу будет назначена подпрограмма для события нажатия на него.

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

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

В этой подпрограмме создаются JSON-данные из содержимого поля и вызывается подпрограмма запрос_на_сервер (request_to_server), которая пытается отправить данные на сервер. На её вход подаются: адрес php-файла в интернете, данные и адрес подпрограммы, которая будет обрабатывать ответ от сервера или подпрограммы запрос_на_сервер

Если не будет связи с сервером, то пользователь увидит объявление offline. В противном случае, если ответ от сервера не будет равен ок, то пользователь увидит объявление доступ запрещён

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

Если аутентификация есть, то создаются адреса для логина и пароля. Далее проверяется, есть ли на сервере файл логин_админа.txt, и если он есть, то проверяется совпадение логина и пароля, введённых клиентом, с логином и паролем, сохранёнными в файлах логин_админа.txt и пароль_админа.txt на сервере. Если нет полного совпадения, то клиенту отправляется слово отказ и программа завершается.

Если логины и пароли совпадают, то создаётся адрес для полученных данных и эти данные сохраняются в файл данные.txt и клиенту отправляется слово ок

В начале клиентская программа выполняет подпрограмму получить_данные

В ней выполняется запрос на сервер с вызовом программы получить_данные.php

Первая часть этой подпрограммы повторяет код из программы сохранить_данные.php

Но если файлы логин_админа.txt и пароль_админа.txt отсутствуют, то они создаются.

После этого проверяется наличие файла данные.txt

Если данные есть, то они оправляются клиенту. Если нет, то клиенту отправляется слово нет

В подпрограмме получить_данные ответ сервера обрабатывает соответствующая подпрограмма. Она заполняет элемент поле элементами, преобразуя строку innerHTML в элементы. И назначает каждому элементу подпрограмму для события нажатия на элемент.

Документу назначается подпрограмма для события нажатия на клавишу клавиатуры. Клавишами Delete и Backspace пользователь может удалять элементы в поле, а стрелками вверх и вниз перемещать элементы относительно друг друга.

Эта подпрограмма при запуске получает через адрес событие объект события нажатия на клавишу.

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

Далее адрес код_клавиши связывается с кодом нажатой клавиши.

В первом ветвлении если нажаты клавиши для удаления, удаляется элемент через вызов его подпрограммы удалить_элемент

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

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

После каждого изменения данные сохраняются.

Чтобы собрать клиентскую часть этого приложения, нужно создать файл index.html, в котором есть: базовый стиль оформления (сброс_css), используемая подпрограмма (request_to_server), и ссылка на клиентскую js-программу (index.js).

На сервере должны быть такие файлы:

Как видите, всё очень просто и понятно.

Ещё есть два свободных редактора с ЖивоСкриптом — Двадэшки для 2D-игр с библиотекой matter.js и ВебКодер для создания сайтов. В ВебКодере также визуализированы языки HTML и CSS.

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

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

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

Впервые упоминание о Cangjie появилось в октябре 2021 года. Huawei собиралась выпустить этот язык программирования в 2022 году, но по каким-то причинам запуск отложился на целых два года.

Основная аудитория Cangjie — разработчики, работающие с экосистемой Huawei, включая мобильные устройства, облачные сервисы и IoT (Интернет вещей). Если вы уже знакомы с языками вроде Java или C++, освоить Cangjie будет проще, потому что у них есть некоторые общие черты. Huawei нацелена на то, чтобы привлечь разработчиков из разных сфер, предлагая им мощный и гибкий язык для создания приложений.

Стратегические цели Huawei: только ли ответ на санкции?

Компания разработала Cangjie с несколькими стратегическими целями. В первую очередь это ответ на санкции: появилась необходимость постепенно объединять Harmony OS и OpenEuler. Harmony OS — мобильная ОС, представленная в августе 2019 года как альтернатива iOS и Android. OpenEuler — продукт для облачных сервисов. Это дистрибутив Linux, запущенный в январе 2020 года, основанный на EulerOS, который является форком CentOS. Так компания будет меньше зависеть от других уже существующих технологий.

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

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

Преимущества Cangjie: безопасность, производительность и гибкость

Что интересного есть у Cangjie:

• Интеграция с аппаратным и программным обеспечением Huawei. Теперь разработка приложений под устройства Huawei станет более эффективной.
• Интеграция с Agile DSL. Можно объединять обычное программирование с конструкциями, близкими к естественному языку. Это упрощает взаимодействие между техническими и нетехническими участниками проекта, улучшая коммуникацию и совместную работу.
• Встроенные инструменты для статической проверки кода, которые помогают выявлять уязвимости и ошибки на этапе написания кода. Это улучшает качество создаваемого программного обеспечения и позволяет разработчикам исправлять проблемы до того, как они попадут в конечный продукт. А еще повышает безопасность кода.
• Улучшенное управление памятью и сборка мусора. Обеспечивает более эффективное выполнение кода и минимизирует вероятность утечек памяти. Разработчики могут сосредоточиться на бизнес-логике, не беспокоясь о низкоуровневых задачах, связанных с управлением ресурсами.
• Высокое быстродействие. Можно создавать приложения с высокой нагрузкой, например, для работы с большими данными или машинного обучения.
• Гибкость синтаксиса. Можно писать код с минимальным количеством строк. Это актуально для новичков, которые только начинают путь в программировании.

Какие перспективы у российских разработчиков

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

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

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

Ключевые тенденции в программировании

JavaScript и Java также продолжают занимать важные позиции в мире программирования.

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

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

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

Растущие звезды: Go и Rust

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

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

Рекомендации по выбору языка

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

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

JavaScript и TypeScript идеально подходят для веб-разработки, особенно если вам важна современная типизация.

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

Важность владения несколькими языками

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

Например, разработка веб-приложений может потребовать комбинации JavaScript, SQL и PHP. Поэтому важно не только осваивать один язык, но и расширять свои навыки, чтобы оставаться конкурентоспособным на рынке труда.

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

Ограниченные ресурсы и время

У каждого специалиста есть ограниченное количество времени для развития.

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

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

Глубина важнее широты

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

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

Развитие основных навыков

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

Эти навыки остаются востребованными вне зависимости от того, какие тренды доминируют на рынке в данный момент.

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