Комментарии 36
Раньше, чтобы уточнить что делается в ядре, приходилось вчитываться в Сишный код.
Теперь, по-видимому, придётся ещё и в Rust ковыряться. Посмотришь на такое:
```
let str_bytes: &'static [u8] = (const { "abcdefg".into_ascii() }).to_bytes();
```
и становится грустно-грустно (а это всего лишь объявили указатель на строку в памяти).
Как они собираются реализовать " привлечёт к разработке ядра новых участников ", если вместо профессионального знания одного языка потребуется знать два? Видимо, со стороны Грега это снизит порог входа.
Сарказм:
Они так беспокоятся за безопасность памяти - так почему им сразу питон не вкрячить в ядро и драйвера? Будет работать медленно, но безопасно (наверное).
Тут про это прояснено от команды ментейнеров ядра тоже.
Но тем не менее это объявление вообще ни разу ни эквивалентно
const char *str_bytes = "abcdefg";
Как минимум:
гарантируется что в строке только ascii и его можно итерировать побайтно подразумевая "посимвольно"
объявлено четкое время жизни, а не просто "пришел const char*, угадай где он лежит и сколько можно им пользоваться"
не получится просто и легко приведением типа превратить его во что угодно, нужно открывать unsafe, который сразу орет всем "внимание, на нас хотят напасть"
То есть да, Rust выглядит куда более зубодробительно, но проясняет в разы больше деталей в моменте.
тоесть проверка будет во время компилирования
а может изменится код или произойти сбой, слинкованная программа на расте поведёт себя забаговано?
очень пугает строка напротив языка сейфти все это очень уверенно пытаются доказать
Да. Ещё если EXE-шник открыть редактором и от балды пару символов поменять, тоже может упасть. Плохой язык, короче.
Скрытый текст
struct Foo<T>(T);
impl<T> Foo<T> {
fn new(t: T) -> Self {
println!("(1) {:p}", &t);
let this = Self(t);
println!("(2) {:p}", &this.0);
this
}
}
fn make_foo<T: Default>() {
let t = 0xF000000;
println!("(0) {:p}",&t);
let foo = Foo::new(0xF000000);// let foo = &Foo::new(0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000);
println!("(3) {:p}", &foo);
}
fn main() {
println!("=== String ==="); // Not Copyable
make_foo::<String>();
println!("==============");
println!("=== i32 ==="); // Copyable
make_foo::<i32>();
println!("==============");
}почему не сейфти? ) почему компилятор пропустил это?
компилятор ничего не сказал, что какоето число не то там просто 0 наверно, а в С++ есть предупреждения
например указатель на строку со строкой (const char* d="abcd";) в вектор С++ не даст отправить ) компилятор выдаст предупреждение
И что сей суслик должен нам символизировать? Что трейт Copy существует? Или что компилятор может определить ещё до конца области видимости, что переменная более не используется, и переиспользовать её место, чтобы экономить стек?
С припиской всё равно ничего не понятно. Кто кого куда пропустил?
компилятор Раст с нулями не показал даже предупреждение только если вначале f вставить он скажет какой лимит, а в С++ лимит указывает если переполняется )
Но 0xF000000 помещается же в i32?
а те примеры с С++ тоже никто не использует кроме самих примеров
//-std=c++23
#include <vector>
#include <cstring>
#include <iostream>
int main()
{
const char *tesdata="abcd";
std::vector<uint8_t> vec(tesdata, std::next(tesdata, strlen(tesdata)));
tesdata=NULL;
for(auto a:vec)
{
std::cout<<a;
}
}а что тут не так?
тоесть Раст там гдето всё прокинутое имеет или реализованное? а тут надо просто тоже самое самому делать? в этом проблема?
https://fosdem.org/2025/schedule/event/fosdem-2025-6507-rust-for-linux/
fn f(a: &i32,b: &i32 ) -> bool {
*a==*b;
}такой пример еще
Они так беспокоятся за безопасность памяти - так почему им сразу питон не вкрячить в ядро и драйвера? Будет работать медленно, но безопасно (наверное).
Ну так собственно в этом и разница: в случае с пайтоном получите кучу оверхеда в рантайме, а Rust свои "безопасные" делишки делает в compile-time.
Очень странный код. Наверно я чего-то не понимаю. Почему не написать
let str_bytes: &'static [u8] = b"abcdefg";
?
Вот я точно не понимаю (т.к не пишу на Rust).
Но один из последователей Rust-а очень топил за такой синтаксис, почему-то ему проще не написать (это не претензия, действительно не знаю). Подробнее в этом комментарии:
https://habr.com/ru/companies/ruvds/articles/882474/comments/#comment_27932412
Меня в этой всей rust-движухе напрягает, что появится второй язык, в котором нужно знать много тонкостей (Ваш комментарий это подтверждает). Полностью переходить на rust пока, наверное, смысла нет. А изучать его "на лайтах", так это смысла мало.
Посмотришь на такое [...] и становится грустно-грустно (а это всего лишь объявили указатель на строку в памяти).
И правда жуть какая-то. Можно же написать вот так:
let str_bytes: &'static [u8] = b"abcdefg";Как они собираются реализовать " привлечёт к разработке ядра новых участников ", если вместо профессионального знания одного языка потребуется знать два?
Учитывая, что С и Rust разнятся не настолько сильно, то знать придётся примерно 1.2 языка. Для не глупых людей уровня "меинтейнер ядра" задача должна быть выполнимой. Это не фулстеком каждый день наворачивать HTML/CSS/JS и сверху ещё какой-нибудь PHP, Python или Ruby намазать.
Они так беспокоятся за безопасность памяти - так почему им сразу питон не вкрячить в ядро и драйвера? Будет работать медленно, но безопасно (наверное).
Первый прототип драйвера для Apple GPU был написан как раз на Python. А потом его переписали на Rust.
Rust или не Rust, но Си уже объективно устарел. В нем просто нет многих концепций таких как синтаксические макросы, рефлексия или даже пространства имен.
а почему раст не конкурирует с ассемблером?
Раст высокоуровневый синтетический синтаксис, С по сути наследник ассемблера, поидее просто бинд ассемблера, отсюда море вопросов к этим моментам, да и не будет ли линукс работать как виндовс сейчас? с Растом и llvm и безопасностью
А должен?
ну учитывая как собирается генту или линукс (опыт винды, которая пришла к базе компиляторов и ввела С шарп ), пусть лучше тогда ОС пишется на Расте сразу, ставить 10 компиляторов утрировано ни в какие допуски не влезает, тоесть цена Раста велика для того кто собирает, он будет собирать все эти исходники часами!
и это еще не выкатывали ошибки Раста
да в статье с с на с++ чего-то перепрыгнули - как будто статья не против с а против ++
Yeah. It's an ironic thing...
unsigned long total = nr * size;
if (nr > ULONG_MAX / size)
return -EINVAL;
In an ideal world, people who write code like that should receive a
permanent ban from promoting Rust.Бгг.
Интересно, а он сам уже много написал ядерного кода на rust?
А ведь альтернативных вариаций C довольно немало изобретено, и есть успешно развиваемые (как примеры можно вспомнить Zig или Hare). Конечно по популярности им очень далеко не только до прародителя, но и до того же Rust. Однако, в сравнении с Rust, они значительно понятнее разработчикам на C, так как исходная "база" языка оставлена, при этом дают современный тулинг (то чем хорош Rust), при этом быструю компиляцию и главное, устраняют основные проблемы, за которые ругают оригинальный С с неоднозначным синтаксисом, мутным препроцессингом и пр. Тут опять же не стоит прямо сравнивать с Rust, где логику программы приходится переосмысливать, чтобы уложить в сильно отличающуюся модель владения памятью и прочие особенности Rust. Вот в том же Hare код выглядит прям очень близко к C, но с более однозначным синтаксисом, более строгой обработкой ошибок и т.п. вроде как мелочами, но код как-то приятнее пишется и легче воспринимается (тут субъективно конечно). Жаль, что пока такие языки далеки от мейнстрима и маловероятно, что в ближайшем будущем их будут рассматривать как варианты для языка Linux kernel.
По-моему в Ziglang слабее гарантии защиты по памяти и защиты памяти в многопоточности
а вас не пугает что Линукс это не ОС? ( тут разве всё очевидно? Линукс и вот это вот всё )
учитывая все эти прошедшие года вопрос в силе остаётся даже сегодня, тоесть купить виндовс нормально действительно( пользование ОС, поддержка инженеров ).
Могли быть другие ОС возможно лучше Линукс подхода - а он не сделал нормально только Линукс делает, и создал море самокопий неявно что привело к утечке памяти, теперь дофига Линукса с его софтом, а нормальные инженеры должны быть в сторонке если они не пишут под Линукс
Они за эти года кроме кусковых самокопий не сделали свою ОС, что они поддерживают не понятно, на что были потрачены 30 милионов строк кода тоже не понятно до сих пор ОС нету
тоесть купить виндовс нормально действительно( пользование ОС, поддержка инженеров ).
Есть точно такие же дистрибутивы и на основе линуха (в смысле с платной поддержкой).
только там не ОС а куски Линукс и гну и частные возможно реализации
вопрос исторически глубже потомучто сегодня много Линукса и на нём почти всё внимание, типо кажется круто, а потом иногда задумываешься, не очевидно
может я бы хотел Солярис десктоп(под текущее оборудование простого ПК), а у меня из выбора виндовс, (бсд подобные), линукс(стотыщекземпляров)
причем все линуксы уникальные если начать скептически сегодня проводить ревизию и сопоставлять с 30 миллионами строк кода, и нет единого подхода, и проект Линукс так и не сделал ОС, а всё на каких-то договорённостях, нет единения хотябы даже 1 примера, только модуль-ядро и всё
тоже не ок вообще-то
при этом нарушается что-то(а ядро поставляется в дефолтной конфигурации допустим, и вот я начинаю уже думать что я должен всё это знать) при моменте если начать компилировать ядро, но преподносится как нормально, хотя документация на ядро в тот же момент есть, моментов очень много, почему не линукс, при этом нет никаких гарантий если черный екран будет у ПК пользователя он будет с этим сталкиваться, и всё же тем не менее поставляется всё вот так и по факту ничего не изменилось за всё существование Линукса, но почему нельзя сделать нормально уже неужели такой и будет Линукс? типо качаешь софт собираешь, а в чем проблема просто поставлять нормальный Линукс 1 и в тот же момент иметь договорённость
мне еще нравится требования растут, а пользователь до сих пор сам собирает Линукс, пользователь вообще не должен открывать эту документацию разработчика
мне еще нравится требования растут, а пользователь до сих пор сам собирает Линукс
Это где так? Минимум лет 10 устанавливается через «Установить – Далее – Далее – ...».
но ведь дистрибутивы уникальные проект Линукс позиционируется как ядро, и .... больше ничего - тоесть переводя на язык пользователя это текущие умения, но это не умения это даже не знание, это просто костыль, который не меняется в лучшую сторону, это могло быть частью ОС, но проект не про ОС вот в чем проблема
требования к знаниям и навыкам растут повсеместно - профессиональным в том числе и знания такие как пойти собрать что-то не исключение, и проблема в том что в поставке линукса не решен этот вопрос, нафига вообще нужен Линукс такой, в чем его уникальность помимо того что обходя какието проблемы он создаёт тоже проблемы для конечного пользователя, это как с играми с 1ой историей, потом будет точка когда конечный пользователь не будет хотеть знать всей той документации и почему какаято утилка не собирается, когда централизованная ОС успешно справляется с этим к примеру тот же Виндовс
Грег Кроа-Хартман привёл убедительные доводы в пользу написания новых драйверов ядра Linux на Rust