В последние годы язык Rust активно продвигается в качестве инструмента для системного программирования. Самый яркий символ этого процесса - официальное добавление Rust в исходный код ядра Linux, одного из ранее неприступных бастионов языка C. Это событие встряхнуло сообщество разработчиков на C, где десятилетиями царила уверенность: «да, C небезопасен, но так всегда было и всегда будет».

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

Проект Fil-C - одна из самых необычных и смелых попыток ответить «да».

Это перевод классической статьи 1995 года одного из титанов теории разработки программного обеспечения - профессора Никлауса Вирта (если найдется некто, кто не знает его, то можно ознакомится, не выходя с habr, со статьями о нем здесь и здесь а небольшая ретроспектива итогов предсказаний Вирта из этой статьи доступна здесь). Текст имеет больше историческое значение, но написан ясным и доступным языком, и, возможно, побудит кого-нибудь пересмотреть подходы к созданию программного обеспечения.

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

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

Если вам надоело слушать проповеди про «безопасность памяти» — эта большое эссе именно для вас, усталых скептиков. Эндрю Лилли Бринкер — ведущий инженер компании MITRE в области безопасности программного обеспечения — спокойно разбирает факты и доказывает: безопасность памяти — не прихоть и не религия Rust‑евангелистов, а экономически оправданный шаг в сторону надёжного, дешёвого и безопасного софта.

Rust, Java, Go и им подобные языки не делают программистов «лучше» — они просто предоставили ремни безопасности в сам процесс разработки. И, как в случае с автомобилями, это спасает тысячи «жизней» приложений.

Nano для меня one love инструмент повышения продуктивности работы в консоли, не больше, не меньше. Спорить о достоинствах и недостатках смысла не вижу. Одни защищают Emacs, превращая его в полноценную операционную систему с календарём, почтой и встроенным браузером. Другие восхищаются Vim, где можно писать код, не отрывая рук от клавиатуры, но ведь не даром, дядя, самый популярный запрос про vim в Google до сих пор - «how to exit Vim».

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

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

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

Как мы помним, одним из важных обещаний при переходе с версии 1.0 на версию 2.0 была заморозка API. Карсон Гросс, создатель htmx, гарантировал, что больших изменений больше не будет - никогда. Все изменения и дополнения выносились в расширения.

Несмотря на большой интерес и воодушевление со стороны фронтэнд сообщества (статьи на habr: тут, тут, тут и тут), адаптация htmx затормозилось в последние несколько лет из-за некоторых, скажем так, спорных решений и ригидности API. Однако изменение ситуации было маловероятным, что привело к созданию альтернативных HATEOAS фреймворков разной степени успешности.

И поэтому мне было приятно прочитать, что 1 ноября 2025 года Карсон Гросс признался: «Я говорил, что не будет версии 3. Но ничего не говорил про версию 4». Так с юмором началась история htmx 4.0, получившей подзаголовок The fetch()ening.

Эндрю Келли, создатель и ведущий разработчик языка программирования Zig, недавно рассказал о будущем асинхронного I/O в Zig, его ключевых примитивах, механизмах отмены и тонкости разграничения асинхронности и параллелизма. Он пригласил заинтересованных разработчиков к активному тестированию и формированию будущего интерфейса ввода-вывода Zig.

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

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

Вы слышали про 996? Если нет, то вам крупно повезло, честно. А если да –  сочувствую. Если вкратце, то 996 - это социальный феномен, когда ты пашешь с 9 утра и до 9 вечера, 6 дней в неделю, как раб на галере. И гордишься этим. Вот, например, недавно статья в ленте хабра была. А на фото к статье - спящая в офисе одна из директоров Twitter, Эстер Кроуфорд (которую, кстати, это не спасло от увольнения).

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

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

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

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

19 октября прошла очередная (некруглая) годовщина первого издания книги 451 градус по Фаренгейту американского классика фантастики Рея Брэдбери. Чем не повод стряхнуть пыль с небольшого томика на книжной полке и посмотреть, как состарились идеи, талантливо отражённые на его страницах?

Почти никак. Изменилась лишь температура и способ сжигания - буквы заменили биты, огонь - юридические предписания. Сегодня вместо пламени на экране персонального устройства появляется холодное сообщение: 451 Unavailable For Legal Reasons. Ваш документ недоступен по юридическим причинам. Не из-за ошибки сети, а потому что кто-то, где-то решил: вам этого знать не нужно.

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

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

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

Мнение после десяти лет в производственных окопах от Джастина Кормака, бывшего CTO Docker.

Несколько лет назад я провёл немало времени, отвечая на вопросы Федеральной торговой комиссии (FTC) по поводу покупки VMware компанией Broadcom. Их интересовало, можно ли считать контейнеры конкурентами виртуальных машин - они пытались разобраться в конкурентной среде вокруг VMware.

Это напомнило мне первые пять лет работы в Docker, когда все только и делали, что сравнивали контейнеры с виртуальными машинами. Контейнеры - это просто “облегчённые” виртуалки? Или это небезопасная ерунда, от которой все скоро откажутся и вернутся к старым добрым VM?

Если тебе не нравится Jujutsu - ты не прав.

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

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

Однажды я случайно решил попробовать снова, но на этот раз попросил Claude объяснить, как сделать в Jujutsu то, что я хотел сделать в git. И вот тогда в моей голове наконец сложилась ментальная модель jj - и я понял всё. Даже то, как работает git. Никогда бы не подумал, что система контроля версий может приносить радость, но вот я тут. И я решил, что, может быть, смогу написать что-то, что заставит jj «щёлкнуть» и у тебя.

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

По этой причине я всегда избегал более академических языков вроде OCaml, Haskell, Clojure и тому подобных. Я знаю, что это хорошие языки — люди намного умнее меня строят с их помощью потрясающие вещи, — но к тому моменту, когда я слышу слово «эндофунктор», я теряю всё внимание (и большую часть интереса к вопросу). Мои любимые языки — те, что требуют меньше интеллектуальных усилий: C, PHP, Python и Ruby.

Так что довольно занятно, что я с большим рвением принялся за Rust. Это, безусловно, самый сложный язык, с которым я чувствую себя хотя бы отдалённо комфортно «в бою». Отчасти потому, что я собрал набор принципов, позволяющих почти полностью избегать ссор с ужасающим механизмом контроля заимствования, временем жизни и прочими тёмными, пугающими уголками Rust. А ещё потому, что Rust помогает мне писать лучшее ПО, и я это чувствую (почти) всё время.

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

Если вы работаете с JavaScript, то знаете, что есть несколько способов объявить переменную (let, const). Эти объявления существуют уже давно и имеют адекватные правила блочной области видимости. Возможно, вы также помните времена, когда их не было. У нас был только var. А var - отвратителен. Каждая переменная изменяема, нельзя навязать неизменяемость, и что ещё хуже - var выходит иногда за пределы блока. Поэтому для меня было большим сюрпризом узнать, что код TypeScript (написанный на TypeScript - пока что) усеян var-ами так, будто на дворе 2003-й. В чем же причина?

Безопасная, эргономичная интероперабельность между Rust и C/C++ была популярной темой на RustConf 2025. Чендлер Каррут, создатель языка Carbon и руководитель команд C++, Clang, и LLVM в Google, представил доклад о различных подходах к интероперабельности в Rust и Carbon — экспериментальном языке, позиционируемого как (C++)++. Его конечный вывод заключается в том, что, хотя возможности Rust по взаимодействию с другими языками постепенно расширяются, полного решения для совместимости с C++ в ближайшее время не будет — и поэтому остаётся место для Carbon, который может предложить другой путь постепенного обновления существующих C++‑проектов. Слайды его доклада доступны тем, кто хочет подробнее изучить приведённые примеры кода.

Многие мои собеседники "стопроцентно" уверяли меня, что сама суть функционального программирования заключается в повсеместном использовании map, filter и reduce; что эти функции превосходят циклы for во всём, настолько, что их нужно запихнуть в каждый возможный язык безо всякого анализа затрат и выгод, потому что выгоды настолько несравненно потрясающие, что затраты просто не могут иметь значения. А само сомнение в этих затратах уже доказывает, что я ничего не понял. Поэтому пора задать главный вопрос: действительно ли именно они (map, filter и reduce) и есть ядро функционального программирования?

К чёрту теорию; давайте посмотрим на практику. Давайте взглянем на реальный проект на Haskell. Я знаю два крупных проекта на Haskell, которые вышли за пределы хаскель-экосистемы и стали полезными программами, которые люди скачивают: xmonad и pandoc. Но xmonad - странная программа: она делает массу привязок к библиотекам C и взаимодействует со всевозможными системными сервисами…Что, конечно, неплохо, как говорится, но из-за этого она не очень типична. А вот pandoc - это чистейший Haskell: парсинг, работа с абстрактным синтаксическим деревом, его трансформация и генерация; т.е., по сути, огромный компилятор для документов. Более «хаскельским» код быть не может. Давайте посмотрим на него.

Я попробовал всё. Notion, Todoist, Things 3, OmniFocus, Asana, Trello, Any.do, TickTick. Я даже однажды сам написал своё приложение для задач (спойлер: так и не закончил). После многих лет прыжков по приложениям для продуктивности я вернулся к тому, с чего начинал: простому текстовому файлу под названием todo.txt.

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

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