🦀 Что удивляет в C, если первым языком был Rust?

Обычно разработчики переходят от C к Rust. Автор C for Rust Programmers пошёл в обратную сторону и собрал нюансы, которые легко пропустить.

Например, такая функция выглядит как принимающая массив из трёх элементов:

void inspect(char data[3]) {
    printf("%zu\n", sizeof(data));
}

Но параметр здесь становится указателем. На платформе с 64-битными указателями увидите 8, а не 3. Длина массива в функцию не передаётся.

Ещё несколько сюрпризов:

• C-строки заканчиваются \0, а strlen() ищет этот байт, проходя по памяти.
• long обычно занимает 64 бита в 64-битных Unix-системах и 32 бита в Windows.
• malloc() может вернуть NULL, а язык не заставит проверить результат.
• Вместо ссылок с проверкой заимствований работают сырые указатели.

Полезное чтение для тех, кто пишет FFI или хочет понять, какие гарантии привычно получает от Rust.

https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/

@rust_code

🍃 Добавить реплику MongoDB, не копируя всю базу: что меняет Atlas Infinite

В привычной архитектуре каждый узел replica set хранит полную копию данных. Добавление реплики или изменение размера узла требует перемещения больших объёмов данных.

Atlas Infinite разделяет вычисления и хранение. Узлы выполняют запросы, а общий слой хранения, написанный на Rust, отвечает за журнал, страницы данных и долговечность. Вычислительные ресурсы и хранилище масштабируются независимо.

Самая интересная деталь: два журнала с разными задачами.

• oplog фиксирует логические операции. Запись подтверждается после устойчивого сохранения большинством реплик журнала.
• phylog передаёт физические изменения страниц при checkpoint, сохраняя пакетную обработку WiredTiger.

То есть подтверждение записи отделено от подготовки страниц для чтения.

Новая read replica подключается к общим страницам и догоняет хвост журнала. Ей не нужно сначала копировать всю базу. А данные шифруются на вычислительном узле: общий storage-слой работает с зашифрованным содержимым.

Для приложения сохраняются протокол, драйверы и семантика операций. Меняется инфраструктура под базой. Atlas Infinite пока в public preview.

Хороший разбор для тех, кому интересны внутренности СУБД:

https://muratbuffalo.blogspot.com/2026/10/atlas-infinite-mongodbs-disaggregated.html

@sqlhub

🦀 1,8 млн ошибок из-за одного пробела: как разработчик собирал Kubernetes Ingress на Rust и Go

Автор Silex разделил систему на две части:

• Go-контроллер наблюдает за Ingress и EndpointSlice, отслеживая маршруты и адреса бэкендов.
• Rust-движок на Tokio принимает трафик и ищет маршруты в конкурентной таблице DashMap.

Обработка запросов отделена от взаимодействия с Kubernetes API.

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

Причина оказалась в разборе конфигурации. Вместо JSON-парсера код искал точную подстроку:

Ожидал:  "host":"silex.local"
Получил: "host": "silex.local"

Допустимый в JSON пробел ломал поиск. Обработчик молча завершался и закрывал TCP-соединение. Итог: 1,8 млн ошибок чтения.

После исправления автор сравнил Silex с NGINX Ingress: K3s, HTTP echo-бэкенд, wrk, 400 соединений, 4 потока, 30 секунд.

Silex: 2536 запросов/с. NGINX: 2274. Разница: +11,5%.

Но максимальная задержка у обоих была около двух секунд, таймауты тоже остались. У Silex их даже больше: 302 против 286. По объяснению автора, нагрузка упёрлась в Node.js-бэкенд.

На момент статьи TLS-терминация, активные проверки бэкендов и Prometheus-метрики ещё были в планах.

Самое ценное здесь: увидеть, как устроен небольшой ingress, где ломается взаимодействие компонентов и почему throughput нужно читать вместе с ошибками и задержками.

https://dev.to/sysalchemist/how-i-built-a-custom-kubernetes-ingress-in-rustgo-that-outperforms-nginx-by-11-4iag

@Golang_google

🦀 В Rust нашли баг, который 11 лет обходил гарантии безопасности памяти.

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

В issue есть примеры чтения освобождённой памяти и падения программы. Один из них воспроизводится начиная с Rust 1.4.

Разработчики присвоили ошибке высокий приоритет `P-high`. По оценке команды, случайное проявление маловероятно: для показанного нарушения безопасности нужна специально сконструированная реализация Drop.

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

Гарантии Rust тоже зависят от корректности компилятора. Здесь нашли дыру именно в их реализации.

https://github.com/rust-lang/rust/issues/164250

🦀 Кто должен доказывать корректность реализации трейта в Rust: сама реализация или код, который её использует?

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

Допустим, есть трейт Magic: Copy. Любой тип с Magic обязан реализовывать Copy.

Два подхода:

• Модульный: проверяем обязательства при проверке impl. Поэтому impl Magic for String недопустим: String не реализует Copy.

• Внешний: разрешаем такой impl, но при его использовании требуем отдельно доказать String: Copy. Реализация есть, воспользоваться ей нельзя.

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

Когда автор пишет unsafe impl, остальной код доверяет его гарантиям. Если реализация ошибочно обещает, что Box<T> может содержать нулевой указатель, ответственность лежит на ней.

Выходит странная модель: гарантии безопасности у impl принимаем, а выполнение требований супертрейтов заставляем перепроверять вызывающий код.

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

https://smallcultfollowing.com/babysteps/blog/2026/10/10/modular-vs-external-proofs/

#Rust