Comments 29
Что такое "правила времени"?
Гугл транслейт такой транслейт…
Управление временем жизни надо полагать. В rust есть возможность такое указать для некоторых штук.
Например возьмём динамический массив в куче. Потом берём ссылку на один из элементов массива. И мы можем доказать, что ссылка на элемент массива не переживёт сам элемент массива. А самое главное — это проверяется на этапе компиляции. Это важно, поскольку если у нас получится невалидная ссылка, то она в какой-то момент может указывать не только на другой элемент, но и вообще на не связанную с массивом память.
Это лишь простой пример, но это работает для всего в Rust.
Я знаю про lifetime rules в Rust, но тогда остается загадочной фраза "правилами времени, написанными на C"
Сама концепция lifetime существует вне контекста Rust. Равно как и проблемы, связанные с несоблюдением этих штук. В Rust просто есть возможность проверять это всё на этапе компиляции.
Нет не об этом. Раст обещал разрешить технические проблемы с памятью, а не проблемы в логике приложения.
Если, например, вы возьмите коллекцию (вектор, мапу и т.д.) и будете заполнять её данными, которые вам не нужны, то это вполне себе утечка памяти — ведь вы продолжаете хранить данные, которые не собираетесь использовать. Но это проблема с логикой приложения, а не техническая проблема с памятью.
С другой стороны, создать ссылку на невалидный (неинициализированный или уже освобождённый) участок памяти в безопасном подмножестве раста не получится. Такой код просто не скомпилируется
С другой стороны, создать ссылку на невалидный (неинициализированный или уже освобождённый) участок памяти в безопасном подмножестве раста не получится. Такой код просто не скомпилируется
Правда?
Это не единственный баг в компиляторе Rust: https://github.com/rust-lang/rust/labels/I-unsound%20%F0%9F%92%A5
Нет. Была даже эпичная история с утечкой, вызванной библиотечным кодом, не помеченным unsafe, вследствие чего комитет сделал вывод, что утечка не является критичным с точки зрения безопасности состоянием, и даже убрал ансейф с метода явной утечки mem::forget.
Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees in the same way that disallowing data races at compile time is, meaning memory leaks are memory safe in Rust.
doc.rust-lang.org/book/ch15-06-reference-cycles.html
и пример модуля ядра с драйвером символьного устройства
Всего одна строчка оттуда:
let data = Pin::from(Box::try_new(unsafe { Mutex::new(0) })?);
Потому что Mutex::new() — unsafe. А он unsafe, потому что после new() и перед использованием надо обязательно вызвать init() — который тоже unsafe, потому что сгенерирован из кода на Си и ещё не обёрнут.
Это другой Mutex — kernel::sync::Mutex.
копия на Осях нет возможности превзойти
квантовый язык возможно конкурент Си++
Линус Торвальдс рассказал о том, где Rust впишется в Linux«Линус Торвальдс согласился, что можно проверить обещания rust на драйверах, от которых ничего не зависит».
Первая цель для Rust — это драйверы просто потому, что там вы найдете множество различных возможных путей реализации
драйверы, вероятно, являются первым местом для подобных попыток, поскольку они зависят от функциональности ядра, но от них ничего не зависит
То бишь, в цепочке зависимостей драйверы находятся на самом краю и с точки зрения рефакторинга это проще всего. Что значит будущее linux ядра это переписывать драйверы на rust, а основные подсистемы оставить на С. Может быть когда-нибудь дойдут руки переписать и их.
Вне контекста эту формулировку можно понять несколько иначе — будто Линукс говорит о драйверах, на судьбу которых всем плеватьэтого я конечно же не подразумевал. Я сетую на то, что заголовок натянуто-додуманный и что журналистика в общем всё дальше и дальше скатывается из донесения фактов в продажу фальсификаций.
Линус Торвальдс рассказал о том, где Rust впишется в Linux