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

И написал статью об этом, конечно. Кратко перескажу причины.

Шаблоны. Tera, Handlebars — нет type-safety между моделью и вьюхой. Maud, Askama — type-safe, но через макросы, а макросы — это ещё больше компиляции

i18n. Node.js из коробки даёт полный ICU + Intl API + i18next с автокомплитом. В Rust i18n до сих пор незрелый.

CI/CD. 14 минут от push до деплоя (12 из них на компиляцию Docker-образа). На Node.js это 5 минут, включая линт и тесты. Автор признаётся: игнорировал баги в Sentry, потому что фикс = ждать компиляцию

Динамика веба. Бесконечные .ok_or().map_err(), десятки кастомных error enum'ов ради обработки (де)сериализации. sqlx проверяет SQL в compile-time, но динамические запросы то ещё мучение. kysely в Node делает то же без подключения к БД

Итог: проблемы в динамических вещах (шаблоны, i18n, SQL). Для API-сервиса без вьюх выбрал бы Rust снова. Для фулстек-веба соло Node.js хватает.

@prog_stuff

Давно пора выпустить новую версию cd

Уве Фридрихсен (немецкий IT-архитектор и технический писатель с многолетним опытом) написал хороший антифомо-пост про ИИ. Суть: нет, вы не отстаёте, если не знаете наизусть все промпт-трюки и агентные фреймворки. Но полностью игнорировать тему тоже нельзя.

Про текущее состояние инструментов. Agentic AI пока ведёт себя как стажёр с СДВГ: задачу надо дробить, контекст давать многократно, и всё равно иногда что-то идёт не так. Это не катастрофа — это просто молодая технология в ранней стадии.

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

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

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

@prog_stuff

Пару недель назад Андрей Карпаты написал скрипт MicroGPT — полноценную языковую модель с нуля на чистом Python, без единой внешней зависимости или библиотеки. В 200 строк уместился весь алгоритм, на котором работают большие модели вроде ChatGPT.

Разработчик GrowingSWE сделал из этого скрипта потрясающий интерактивный лонгрид. Он разобрал код по кусочкам и визуализировал каждый шаг прямо в браузере.

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

— Подвигать ползунки логитов и посмотреть, как Softmax превращает их в вероятности.

— Пройти по шагам backpropagation и увидеть, как модель понимает, куда крутить веса.

— Изучить матрицу Attention: как разные «головы» учатся обращать внимание на разные части слова.
​
Разница между этим скриптом и ChatGPT — только в масштабах (вместо триллионов токенов тут имена, а вместо сотен слоёв — парочка). Базовый цикл абсолютно тот же.

Интерактивный разбор: https://growingswe.com/blog/microgpt

@prog_stuff

Никого не повышают за простоту

Инженер A делает фичу за два дня: пишет 50 строк понятного кода, тестирует, выкатывает.

Инженер B берёт ту же задачу, но строит «масштабируемую архитектуру»: добавляет pub/sub, новые абстракции и фреймворк для конфигурации. Тратит три недели.

На performance review работа B звучит как готовый кейс: «спроектировал масштабируемую событийно-ориентированную архитектуру, внедрил переиспользуемый слой абстракций». Работа A звучит как «сделал фичу X». Никто не получает повышение за ту сложность, которой он избежал.

Индустрия системно поощряет оверинжиниринг:

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

— На код-ревью простые решения обрастают абстракциями из-за вопросов коллег «а не стоит ли заложиться на будущее?»

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

Автор даёт совет: решение не строить сложную систему — это важное инженерное решение. Его нужно документировать. Вместо «сделал фичу X» пишите: «Оценил три подхода, включая event-driven архитектуру. Определил, что простое решение покрывает все текущие требования. Выкатил за 2 дня, 0 инцидентов за полгода».

Статья целиком: https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/

@prog_stuff

Разработчик из Mozilla Габриэле Свельто поделился технической статистикой о причинах падений Firefox. Некоторое время назад команда инженеров внедрила в браузер алгоритм для анализа краш-репортов, который умеет выявлять одиночные искажения битов в памяти.

Собранные данные показали неочевидную картину:
— система точно зафиксировала битфлипы в 5% всех отчётов об ошибках;
— по расчётам команды реальная доля таких инцидентов доходит до 10%.

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

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

@prog_stuff

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

Как это реализовано технически:
— эмулятор исполняет реальный машинный код для процессоров 8086;
​— тактовый генератор построен на CSS-анимациях, поэтому система работает автономно и не требует от пользователя постоянно водить курсором по экрану;
​— логика работает благодаря новым спецификациям CSS, таким как условные операторы if(), стилевые запросы и кастомные функции

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

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

@prog_stuff

Как эволюционировали OCR-программы

Инструменты для распознавания текста (OCR) появились еще в 1960-х, но только последние 20 лет они используются для чтения документов и облегчают нашу с вами жизнь.

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

Если вы когда-нибудь работали в кровавом энтерпрайзе на Java, этот репозиторий может вызвать у вас флешбеки и легкую панику. Разработчики создали пародийный проект FizzBuzz Enterprise Edition — ту самую задачу с собеседований про деление чисел на 3 и 5, но написанную «серьёзными бизнесменами для серьёзных бизнес-целей».
​
Вместо десяти строк кода авторы наворотили гигантскую архитектуру. Внутри бесконечные вложенные папки, десяток фабрик, интерфейсы для интерфейсов и классы с названиями в духе FizzBuzzOutputGenerationContextVisitor.
​
Отдельный вид искусства в этом проекте — раздел Issues. Пользователи активно подыгрывают авторам и создают гениальные тикеты. Например, кто-то пожаловался, что код написан слишком качественно и потребовал ухудшить его, чтобы соответствовать реальным индустриальным стандартам. Или предлагают уволить бизнес-аналитика, потому что он слишком понятно объяснил задачу, и требуют добавить больше уровней абстракции, чтобы никто не смог найти, откуда импортируется код.

@prog_stuff

Scientific American собрали свежую статистику о том, как нейросети влияют на жизнь разработчиков. Изначально все надеялись, что ИИ разгрузит инженеров, но реальные цифры показывают обратную картину: программисты стали работать больше и чаще перерабатывать по вечерам.
​
Главные причины такого парадокса:

— Падает стабильность релизов. Нейросети выдают код мгновенно, но его нужно тщательно проверять. Отчёт DORA подтверждает, что активное использование ИИ напрямую связано с ростом откатов и горячих фиксов на проде.
​
— Растут ожидания руководства. Бизнес замечает ускорение и требует закрывать больше задач. В итоге инженеры берут дополнительный объем, а количество их коммитов в нерабочие часы выросло почти на 20%
​
— Усложняется отладка. Инженеры объективно хуже понимают сгенерированную логику. Когда такой код ломается, на поиск причин и исправление багов уходит гораздо больше сил.
​
Получается, что инструменты действительно ускоряют написание новых блоков, но вся экономия времени полностью сгорает на этапах тестирования и ревью. А если вы начинаете писать код быстрее, в качестве награды менеджеры просто накидывают вам больше новых тикетов.

Полная статья: https://www.scientificamerican.com/article/why-developers-using-ai-are-working-longer-hours/

@prog_stuff