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

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

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

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

Его звали Филиппо Брунеллески. Он использовал этот аппарат, чтобы нарисовать расположенный рядом с собором баптистерий. Если его биографы не ошибаются, для этого он применил законы перспективы, открытые им приблизительно в 1415-1420 годах. Использование законов перспективы, поразившее случайных прохожих, изменило курс развития западного искусства более чем на 450 лет. Позже оно привело к математическим открытиям, позволившим реализовать эллиптическую криптографию — схему защиты, лежащую в основе биткойна и других криптовалют; сейчас она становится всё более популярным способом шифрования и на других Интернет-платформах.

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

Глубокое обучение гламурно и ажиотажно. Если обучить трансформер (современную языковую модель) на датасете из 22 миллионов ферментов, а затем использовать его для прогнозирования функции 450 неизвестных ферментов, то можно опубликовать свои результаты Nature Communications (уважаемом научном издании). Вашу статью прочитают 22 тысяч раз и она будет в верхних 5% из всех результатов исследований по оценке Altmetric (рейтингу внимания к онлайн-статьям).

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

Functional annotation of enzyme-encoding genes using deep learning with transformer layers | Nature Communications

Limitations of Current Machine-Learning Models in Predicting Enzymatic Functions for Uncharacterized Proteins | bioRxiv

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

Что такое интервальные повторения

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

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

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

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

BEIR — это бенчмарки поиска информации, ориентированные на сценарии использования в формате «вопрос-ответ».

Мой хобби-проект SearchArray добавляет в Pandas полнотекстовый поиск. Поэтому естественно, чтобы ощутить трепет от моих потрясающих навыков разработчика, я решил использовать BEIR для сравнения SearchArray с Elasticsearch (с тем же запросом + токенизацией). Поэтому я потратил субботу на интеграцию SearchArray в BEIR и измерение релевантности и производительности с корпусом MSMarco Passage Retrieval (8 миллионов документов).

Барабанная дробь...

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

Я считаю, что при работе с Go в контексте нашей отрасли внедрение зависимостей (dependency injection, DI) часто имеет плохую репутацию из-за DI-фреймворков. Но сама по себе DI как техника довольно полезна. Просто её объясняют слишком большим количеством ОО-жаргона, что приводит к ПТСР у тех, кто перешёл на Go, чтобы сбежать из культа банды четырёх.

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

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

В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.

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

Сегодня я решил изучить новую библиотеку Cloudflare OAuth provider, которую, судя по заявлениям, почти полностью написали при помощи LLM Claude компании Anthropic:

Эта библиотека (в том числе и документация по схеме) была по большей мере написана при помощи Claude — ИИ-модели компании Anthropic. Результаты работы Claude были тщательно проверены инженерами Cloudflare, уделившим особое внимание безопасности и соответствию стандартам. В исходный результат было внесено множество улучшений, в основном тоже при помощи промптов Claude (и с проверкой результатов). Промпты модели Claude и созданный ею код можно посмотреть в истории коммитов.

[…]

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

Я и сам в последнее время достаточно много писал подобным образом код при помощи «агентских» LLM. И я тоже специалист по OAuth: я написал API Security in Action, многие годы был членом OAuth Working Group в IETF и ранее работал техлидом, а затем архитектором безопасности в ведущем поставщике решений OAuth. (Также у меня есть степень PhD в сфере ИИ, полученная в группе изучения интеллектуальных агентов, но ещё до возникновения современного ажиотажа вокруг машинного обучения). Поэтому мне было очень любопытно, что же создала эта модель. И сегодня, сидя на паре совещаний, я решил изучить результаты. Дисклеймер: я лишь вкратце просмотрел код и нашёл несколько багов, а не выполнял полный анализ.

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

Команда cargo test запускала выполнение всех тестов в репозитории, но спустя пару миллисекунд все тесты завершались сбоями из-за не очень знакомой мне ошибки:

Io(Os { code: 24, kind: Other, message: "Too many open files" })

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

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

^*тремя

Что ж, ладно, расскажу. Самый ядовитый тритон в мире — это Taricha granulosa, желтобрюхий тритон. Скромное маленькое земноводное, эндемичное для северо-запада тихоокеанского побережья Северной Америки, к западу от Каскадных гор примерно от округа Санта-Круз (Калифорния) до Юго-Восточной Аляски.

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

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

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

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

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

Теперь представьте, что вы продаёте свой дом. Его площадь 1850 квадратных футов (~172 квадратных метра) — больше среднего, но явно не особняк. Вы видели, почём продаются дома в вашем районе, но цены колеблются. Какой будет справедливая цена?

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

¹¹ ¹
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 пикселя уже по вертикали, чем у более новых моделей?

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