Помните, как долго выполняется сложение на бумаге?

¹¹ ¹
6876
+ 3406
------
10282

Начиная с единиц, мы складываем 6 + 6 = 12, записываем 2 и переносим 1. Затем пошагово двигаемся влево, пока складываемые разряды не закончатся.

При реализации сложения больших чисел (например, от 2⁶⁴ и выше) обычно пишут код, похожий на этот алгоритм. Любопытно здесь то, что существует простой трюк, позволяющий существенно ускорить этот процесс на современных CPU.

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

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

Вы знаете, что такое прогрессивный JPEG? Можете почитать хорошее объяснение. Идея заключается в том, что вместо загрузки изображения сверху вниз оно сначала грузится размытым, а потом постепенно становится чётче.

Что, если мы применим тот же принцип к передаче JSON?

Программисты на Go уже давно и долго жалуются на слишком многословную обработку ошибок. Все мы близко (а иногда и болезненно) знакомы со следующим шаблоном кода:

x, err := call()
if err != nil {
// обработка err}

Проверка if err != nil встречается настолько часто, что может становиться объёмнее остального кода. Обычно это происходит в программах, выполняющих много вызовов API, в которых обработка ошибок рудиментарна и они просто возвращаются. Некоторые программы в итоге выглядят примерно так:

func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return err
}
y, err := strconv.Atoi(b)
if err != nil {
return err
}
fmt.Println("result:", x + y)
return nil }

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

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

Было бы легко сказать, что Stack Overflow убил искусственный интеллект, но больше похоже на то, что ИИ лишь нанёс последний удар. Произошедшее можно считать притчей о человеческом обществе и о том, как эксперименты с самоуправлением привели к непредсказуемо плохим результатам.

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

Stack Overflow был не первым и не единственным подобным сайтом. Он стал частью волны нового поколения форумов по программированию, появившихся в начале века; некоторые из таких сайтов живы и по сей день. А сами такие форумы были потомками user groups и Usenet. С переходом к эпохе больших языковых моделей (large language model, LLM) все эти форумы сталкиваются с экзистенциальным кризисом. Нужны ли они нам вообще?

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

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

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

В посте я расскажу, как он устроен внутри.

Некоторые языки программирования, например Rust, Go и TypeScript, считаются крутыми. Другие, в том числе Cobol и Java, «скучны». Однако пусть Java, которому 23 мая этого года исполнилось тридцать лет, может, и не самый захватывающий язык, он остаётся одним из самых важных. 

Путь Java начался 23 мая 1995 года, когда его выпустила компания Sun Microsystems. За прошедшее время благодаря удачному видению разработчиков и адаптивности он превратился из нишевого проекта для потребительской электроники в мощный фундамент энтерпрайз-, облачной и веб-разработки.

Хоть Java исполнилось тридцать, его история гораздо дольше. Корнями этот язык уходит в 1991 год, когда инженеры Sun Джеймс Гослинг, Майк Шеридан и Патрик Ноутон приступили к созданию языка для интерактивного телевидения и встроенных устройств. Этот проект назвали Green Project. Его цель заключалась не столько в написании нового языка, сколько в создании того, что бы мы сегодня назвали контроллером Интернета вещей. Ещё один разработчик Java Тим Линдхольм, описал его как «своего рода гибрид между КПК и универсальным пультом дистанционного управления».

Глава 1: мой коллега, программист

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

«Постой-ка. У меня появилась идея. Дай мне клавиатуру.»

Идея. Ага. Как у младенца появляется «идея» засунуть вилку в розетку. Я почти доделал нечто прекрасное; стройную, изящную логику, пронзающую сложность подобно ножу, режущему масло. И тут появился он — бьёт по клавиатуре, как будто она ему деньги должна, копипастит код-франкенштейн из комментария на StackOverflow, написанный последователем Дяди Боба в 2014 году.

Знает ли он, что делает наша система? Нет.

Прочитал ли он тикет? Разумеется, нет.

Ощущает ли он уверенность, когда безрассудно корёжит глобальное состояние? Разумеется, да.

Многие классические Mac поддерживали дисплеи с разрешением 512×384, но компактные Mac, начиная с первой машины 1984 года и вплоть до Macintosh Classic II 1991 года, имели встроенные ЭЛТ-дисплеи размером 512×342 пикселя. Это относится ко всем чёрно-белым компактным «макам» с 9-дюймовым экраном. У более поздних Color Classic и Color Classic II был 10-дюймовый ЭЛТ-дисплей с полными 512×384.

Я решил узнать, почему Apple приняла такое решение. Почему дисплеи ранних Mac на 42 пикселя уже по вертикали, чем у более новых моделей?

Перелопатив кучу источников, должен сказать, что для ответа на этот вопрос нужно принять во внимание множество факторов.

В своей предыдущей статье [перевод на Хабре] я говорил о множестве недостатков C++, которые, по сути, устранил Rust. Благодаря этому код теперь легко использовать правильно и сложно использовать неверно. Я не говорил о безопасности по памяти, просто привёл пример того, что пользователь функции не может случайно поменять местами аргументы количества и цены.

На написание статьи меня вдохновил доклад Мэтта Годболта о том, как можно сделать интерфейсы C++ более надёжными: Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Вам стоит его посмотреть!

В той статье я сказал, что Rust гораздо лучше помогает разработчику, возможно, благодаря тому, что у него были десятки лет, чтобы учиться. В конце концов, первая версия C++ была выпущена в начале 80-х, а Rust — в начале 2010-х. Если дать C++ несколько десятков лет для обучения, то, разумеется, появятся новые структуры, которые будут обладать высоким качеством и которые сложно использовать неправильно.

Но так ли это?

В этом посте я расскажу, как нашёл уязвимость нулевого дня в ядре Linux при помощи модели OpenAI o3. Уязвимость обнаружилась благодаря одному лишь API o3 — не потребовались никакая дополнительная настройка, агентские фреймворки и инструменты.

Недавно я занимался аудитом уязвимостей ksmbd. ksmbd — это «сервер ядра Linux, реализующий в пространстве ядра протокол SMB3 для передачи файлов по сети». Я приступил к этому проекту специально для того, чтобы взять отдых от разработки связанных с LLM инструментов, но после релиза o3 не мог избежать искушения и не использовать в качестве небольшого бенчмарка способностей o3 баги, найденные мной в ksmbd. В одном из следующих постов я расскажу о показателях o3 при обнаружении всех этих багов, а сегодня мы поговорим о том, как в процессе моего бенчмаркинга o3 обнаружила уязвимость нулевого дня. Найденной уязвимости присвоили обозначение CVE-2025-37899 (её патч выложен на Github), это use-after-free в обработчике команды SMB logoff. Для понимания уязвимости необходимо знать о работе конкурентных подключений к серверу и о том, как они в определённых обстоятельствах могут обмениваться различными объектами. Модели o3 удалось разобраться в этом и найти место, где конкретный объект с автоматическим подсчётом ссылок освобождался, но продолжал оставаться доступным для другого потока. Насколько я понимаю, это будет первым публичным рассказом об уязвимости подобного типа, обнаруженной LLM.

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

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

В апреле этого года в блогах, посвящённых кибербезопасности, начали появляться отчёты о новой сложной платформе искусственного интеллекта, созданной исключительно для совершения преступлений. Но несмотря на своё происхождение и пугающее название, Xanthorox не так уж загадочна. У разработчика этого ИИ есть страница на GitHub, а также публичный YouTube-канал с видеозаписями интерфейса и описанием «Этот канал был создан для развлечений и ничего иного». У Xanthorox есть и почтовый адрес Gmail, Telegram-канал, на котором ведётся хроника разработки платформы, а также Discord-сервер, на котором пользователи могут платить за доступ криптовалютой. Не требуется никакой регистрации на криминальных форумах дарк-веба, достаточно лишь одного сообщения предпринимателю, который обслуживает потенциальных преступников с большей прозрачностью, чем многие онлайн-магазины, рекламирующие омолаживающие кремы в Instagram.

Какое-то время назад memorysafety.org объявил о конкурсе по повышению производительности rav1d — порта AV1-декодера dav1d на Rust.

Моя фамилия Равид, совсем как название декодера, поэтому я решил, что будет забавно попробовать (хоть я и, вероятно, не смогу участвовать в конкурсе).

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

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

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

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

Сложность текста: 2-3/5

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

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

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

Естественно, настоящим математикам это надоело. В начале 2017 года на Reddit появился пост с заголовком «Меня утомила вся эта фейсбучная фруктовая математика. Хочет кто-нибудь придумать действительно сложную математическую задачу, чтобы побороться с этим явлением?».

На дворе 2025 год, а я всё ещё продолжаю делать видеоигры. Если верить archive.org, я начал заниматься этим двадцать лет назад! Достаточно долгий срок для одного увлечения...

Когда я рассказываю о том, над чем работаю, люди часто спрашивают меня, как я делаю игры, и их часто удивляет (а иногда и тревожит?), когда я говорю, что не пользуюсь коммерческими игровыми движками. Существует какой-то стереотип, что если ты делаешь игры не в популярном инструменте наподобие Unity или Unreal, это значит, что ты чуть ли не вручную пишешь ассемблерный код.

Я искренне считаю, что создание игр без огромного «многофункционального» движка может быть проще и интереснее, а часто и позволяет оптимальнее тратить вычислительные ресурсы. Я не делаю игру, в которой «есть всё», поэтому мне не нужны 90% фич, предоставляемых движками. Все мои игры обладают конкретным стилем и у меня есть конкретные способы работы с моими инструментами. Часто оказывается так, что используемым по умолчанию реализациям фич в крупных движках наподобие Unity не хватает столь многого, что мне всё равно приходится писать их самостоятельно. В конечном итоге, мои проекты по большей мере оказываются моими собственными инструментами и системами, а движок становится необходим лишь для создания удобного UI и части рендеринга...

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

Вам когда-нибудь хотелось, чтобы можно было написать простой CSS для объявления цвета, после чего браузер сам бы определял, чёрный или белый должен сочетаться с этим цветом? Теперь это возможно благодаря contrast-color(). В статье мы объясним, как это работает.

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

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

TLDR: LLM неплохо справляются с кодингом, но в больших проектах они пишут запутанный сумбур. Я уменьшил объём использования ИИ при кодинге и вернулся к работе головой, ручке и бумаге.

Несколько месяцев назад мне нужно было создать новую инфраструктуру для моего SaaS, потому что связка из PHP+MySQL перестала отвечать нашим требованиям. Мне не терпелось воспользоваться этой возможностью, чтобы максимально задействовать все новые LLM, с которыми я экспериментировал. Поэтому я временно отказался от должности разработчика ПО, став сам себе продакт-менеджером. Я обсуждал с Claude технологии, проводил собственные исследования и спустя много итераций составил план. В итоге я решил использовать Go+Clickhouse.

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

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

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

NumPy — это ПО для выполнения вычислений с массивами на Python. Оно невероятно популярно и очень сильно повлияло на все популярные библиотеки машинного обучения, например, на PyTorch. Эти библиотеки во многом имеют те же самые проблемы, но для конкретики я рассмотрю NumPy.

Показанным ниже кодом вы можете проверить на високосность год в интервале 0 ≤ y ≤ 102499 всего примерно тремя командами CPU:

bool is_leap_year_fast(uint32_t y) {

return ((y * 1073750999) & 3221352463) <= 126976;

}

Как это работает? Ответ на удивление сложен. В статье я объясню процесс; в основном он связан с забавным битовым жонглированием. В конце мы обсудим применение этого кода на практике.