Rust в Linux: разница идеологий

https://felipec.wordpress.com/2025/02/13/rust-not-for-linux/
https://rust-unofficial.github.io/too-many-lists/
Автор статьи рассуждает о Rust в Linux: что это, в первую очередь,
спор идеологий. Автор трогал Rust и заявляется что в нём нельзя сделать
связанные списки. А в Linux их 10k+. Если Rust нацеливается заменить Си,
то он должен мочь выполнять те же самые задачи. Rust люди постоянно
любят говорить другим что им надо делать, как что-либо надо делать. И
они говорят о том, что просто не надо использовать связанные списки. Вот
так вот просто.

Ещё приводит пример простой структуры на Си и Rust:

    C:
        struct person {
            char name[50];
            int age;
            struct person *boss;
        };

        struct person john = { .name = "John Doe", .age = 25 };

    Rust:
        struct Person<'a> {
            name: &'a str,
            age: u32,
            boss: Option<&'a Person<'a>>,
        }

        let john = Person { name: "John Doe", age: 25, boss: None };

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

Си-шники обычно предлагают какое-то рабочее решение, которое после
оценок, если годится и хорошее, начинает внедряться в Linux. Типа снизу
вверх внедрение идёт. Rust хотят услышать слово подтверждения от Линуса,
и только после этого начинать вносить правки в ядро. Типа сверху вниз
внедрение. Последователи Rust ведут себя точно также как и всякие борцы
за "they" вместо "she", "main" вместо "master" (думаю, что можно и не
сомневаться в том, что эти множества борцов сильно пересекаются между
собой) -- агрессивно и активно продавливают (включая угрозы, шантаж) эти
изменения в конечный софт/инструменты, вместо того, чтобы люди плавно
самостоятельно понимали, принимали и использовали что-то более корректно.

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

    * The following pointer types: &, &mut, Box, Rc, Arc, *const, *mut, NonNull(?)
    * Ownership, borrowing, inherited mutability, interior mutability, Copy
    * All The Keywords: struct, enum, fn, pub, impl, use, ...
    * Pattern matching, generics, destructors
    * Testing, installing new toolchains, using miri
    * Unsafe Rust: raw pointers, aliasing, stacked borrows, UnsafeCell, variance

комментарий 0:

From: kmeaw
Date: 2026-01-14 22:04:31Z

На мой взгляд, очень сомнительная статья.

Аргументы Линуса против C++ в Git, на которые она ссылается, мне гораздо более
понятны - он считает, что C хорош тем, что принуждает людей быть более
дисциплинированными, больше внимания уделять низкоуровневым аспектам, а идиоты
просто не смогут испортить его код.

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

  let mut person_heap = Box::new(Person { name: "John Doe", age: 25, boss: None });
  dbg!(&person_heap);

Причём используя очень похожий синтаксис для записи:

  *person_heap = Person { name: "Jane Doe", age: 19, boss: None };
  dbg!(&person_heap);

Чего нельзя сказать про его же пример на C:

  struct person *person_heap = malloc(sizeof(struct person));
  static const struct person john_static = { .name = "John Doe", .age = 25 }; /* (1) */
  *person_heap = john_static; /* (2) */

где я не знаю способа записать (1) и (2) в одну строку, как в исходном примере.

Потом он ссылается на учебное пособие "Learn Rust With Entirely Too Many Linked
Lists", цель которого - показать, как работают разные механизмы в языке, как
устроена стандартная библиотека, и объяснить, какие у разных подходов пределы
применимости.

> they say two things 1) “yes you can” (untrue)

Конечно же, сишный список можно практически дословно переписать на Rust с
помощью raw pointers, причём с полноценным контролем типов и без засорения
окружения негигиеничными макросами препроцессора.

  #[derive(Debug, Default)]
  struct ListHead<T> {
      next: *mut ListHead<T>,
      prev: *mut ListHead<T>,
  }

  #[derive(Debug, Default)]
  struct Inode {
      list: ListHead<Self>,
      refcount: u32,
  }

И потом ещё написать немного unsafe кода, чтобы описать итератор (без каких-либо
дополнительных накладных расходов, его sizeof будет равен ширине указателя),
после чего по такому списку можно будет шагать обычным for inode in i.list.iter()

Автору предлагают так не делать, и использовать более безопасные конструкции.

> The moment somebody tells me “you shouldn’t want that”, I stop using their
> software. Period.

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

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

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

комментарий 1:

From: Sergey Matveev
Date: 2026-01-15 09:28:27Z

*** kmeaw@kmeaw.com [2026-01-14 22:06]:
>На мой взгляд, очень сомнительная статья.

Да её нормально так критикуют уже в первом комментарии (на странице
самой статьи) :-)

>Аргументы Линуса против C++ в Git, на которые она ссылается, мне гораздо более
>понятны - он считает, что C хорош тем, что принуждает людей быть более
>дисциплинированными, больше внимания уделять низкоуровневым аспектам, а идиоты
>просто не смогут испортить его код.

Это могу понять, да.

Про Rust особо ничего не смогу прокомментировать: я его не смог осилить
даже на простой задаче, и уже забыл всё что успел потрогать. C++ хотя бы
приходится читать/видеть и иногда чуточку править.