Продемонстрирована возможность разработки частей Linux на Rust

Покажи эти другие системы в которых гаранитируется отсутствие data races.

Ну вот кстати, о data races. Пример из доклада «Rust: Hack Without Fear!»:

fn qsort(vec: &mut [i32]) {
  if vec.len() <= 1 { return; }
  let pivot = vec[random(vec.len())];
  let mid = vec.partition(vec, pivot);
  let (less, greater) = vec.split_at_mut(mid);
  rayon::join(|| qsort(less),
              || qsort(greater));
}

Кстати, RazrFalcon — это же просто C++ный код, ведь правда? Синтаксис так просто 1-в-1 скопировали.

кто и как здесь гарантирует отсутствие data races?

Ну, очевидно что сигнатура метода join:

pub fn join<A, B, RA, RB>(oper_a: A, oper_b: B) -> (RA, RB)
    where A: FnOnce() -> RA + Send,
          B: FnOnce() -> RB + Send,
          RA: Send,
          RB: Send

Она не позволит тебе отстрелить ноги.

Она не позволит тебе отстрелить ноги.

Как она не позволит, если, скажем, vec.split_at_mut вдруг вернет перекрывающиеся диапазоны?

ООП придумали, по большому счёту, чтобы моделировать сущности реального мира.

Несбывшиеся маняфантазии. В современной реальности ООП моделирует, в основном, элементы гуйни, структуры данных и сущности программной архитектуры. Из всего этого более-менее близки к реальному миру только элементы гуйни.

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

Раст решил сам себя ограничить, ну ладно, практика покажет.

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

Например, если Ваш тип поддерживает типаж Display, то этот тип автоматически может быть использован в форматирующих макросах, таких как print! и format!. И Вам не нужно знать ни чего об этом типе, кроме того что у него есть реализация типажа Display, если её нет, то компилятор не соберёт код и объяснит почему.

Ну т.е. когда говорят о гарантиях отсутствия data races нужно понимать, что временами эти гарантии на уровне «мамой клянусь».

когда говорят о гарантиях отсутствия data races нужно понимать, что временами эти гарантии на уровне «мамой клянусь»

Ну так, стопроцентную гарантию даёт только страховой полис.

Т.е. когда говорят, что в программах на Rust не бывает data races, то это, мягко говоря, звиздешь. Ведь 100% дает страховой полис, а не Rust, правильно? ;)

Т.е. когда говорят, что в программах на Rust не бывает data races, то это, мягко говоря, звиздешь.

Равно как и любые другие гарантии :)

Впрочем, как по мне, лучше иметь нестопроцентную гарантию, чем не иметь никакой.

Впрочем, как по мне, лучше иметь нестопроцентную гарантию, чем не иметь никакой.

Как по мне, так лучше говорить, что Rust существенно упрощает борьбу с data races или что в Rust есть языковые механизмы предотвращения data races. А не о гарантиях отсутствия этих самых data races.

Ну вот например, недавно на лоре: Года бегут, а все-равно ваш C++ - ...

Сможет ли кто с уверенностью сказать («мамой поклясться») что этот C++ код не содержит гонок?

А вот аналог на Rust: https://is.gd/YaOadc

Там используется только стандартная библиотека, и нет слова unsafe, значит можно смело утверждать, что этот код не содержит data races. (а против багов в компиляторе заполни страховой полис)

Сможет ли кто с уверенностью сказать («мамой поклясться») что этот C++ код не содержит гонок?

А что, там гонки таки нашли?

(а против багов в компиляторе заполни страховой полис)

Разговоры с адептами серебрянных пуль вымораживают тем, что вместо конструктива разговор зачастую сводится к «а у вас негров линчуют».

Ок, можно согласиться с тем, что в стандартной библиотекой количество багов сведено к минимуму и обычный программист с ними никогда не столкнется. Ладно.

Только вот в стандартной библиотеке никогда не будет всего, что нужно для всех ситуаций. Рано или поздно придется взять стороннюю библиотеку. Кто будет проверять, есть ли unsafe у нее внутри, особенно если эта библиотека на 1.5MLOC? Снаружи она будет выглядеть как безопасная, но кто обеспечивает гарантии отсутствия гонок? Rust или разработчик сторонней библиотеки?

Синтаксис так просто 1-в-1 скопировали.

Опять выдумываете?

а у вас негров линчуют

Сравние было в ключе «есть гарантии»/«нет гарантий». Просто C++ очень хорошо подходит на роль языка в котором даже на `a + b` гарантий нет. Не нравится сравнивать с C++, подставь другой язык по вкусу. Какой пример я нашел, такой и показал, других небыло.

Rust или разработчик сторонней библиотеки?

Есть ненулевой шанс что Rust поможет разработчику сторонней библиотеки не совершить ошибок.

особенно если эта библиотека на 1.5MLOC?

Да хоть 100500 MLOC. Достаточно выполнить grep unsafe или посмотреть, указан ли в к корне #![forbid(unsafe_code)].

Rust гарантирует отсутствие data races в безопасном коде. Защитится от unsafe физически невозможно. Тут ничего не поделаешь. Но язык всеми силами старается минимизировать точки отказа.

Сравние было в ключе «есть гарантии»/«нет гарантий». Просто C++ очень хорошо подходит на роль языка в котором даже на `a + b` гарантий нет.

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

void f() {
  A a;
  B b;
  ...
}

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

Это и есть гарантии.

Когда же выясняется, что Rust опирается на обещания разработчика и делает проверку только на основе этих обещаний, то разговоры про «гарантии» — это недобросовесный маркетинговый булшит. Говорили бы про помощь с борьбе с data races, было бы более точно. А так есть ощущение, что пытаются мягко на*бывать.

Rust гарантирует отсутствие data races в безопасном коде.

Есть ощущение, что «безопасный код» в Rust-е — это такой сферический конь в вакууме. Поскольку базируется он на unsafe в стандартных и в сторонних библиотеках.

Можно говорить о том, что программы на Rust-е безопаснее оных на C и на C++. Но вот про наличие гарантий — это из области маркетинга.

Если вы не осилили доку - это ваши проблемы. Там чёрным по белому написано:

https://doc.rust-lang.org/nomicon/races.html#data-races-and-race-conditions

A data race has Undefined Behavior, and is therefore impossible to perform in Safe Rust.

https://doc.rust-lang.org/book/second-edition/ch16-04-extensible-concurrency-...

Implementing the guarantees that these traits are markers for involves implementing unsafe Rust code. ... for now, the important information is that building new concurrent types that aren't made up of Send and Sync parts requires careful thought to make sure the safety guarantees are upheld.

https://doc.rust-lang.org/book/second-edition/ch19-01-unsafe-rust.html

Unsafe Rust exists because, by nature, static analysis is conservative. When trying to determine if code upholds some guarantees or not, it's better to reject some programs that are valid than it is to accept some programs that are invalid. There are some times when your code might be okay, but Rust thinks it's not! In these cases, you can use unsafe code to tell the compiler, «trust me, I know what I'm doing.» The downside is that you're on your own; if you get unsafe code wrong, problems due to memory unsafety like null pointer dereferencing can occur.

Проблема хейтеров вроде вас, что вы придумали какой-то свой раст, который не имеет отношения к реальности.

И если вас смущают громкие заявления - то научитесь их фильтровать. Ведь они есть в любом языке: «в java нет утечек памяти», «write once run anywhere», «go позволяет писать многопоточные приложения без усилий», «гарантии rust можно реализовать в современном C++», «C переносим по умолчанию» и тд.

Если вы не осилили доку - это ваши проблемы.

При чем здесь дока? Речь идет о том, что в данной теме говорят про «гарантии» Rust-а.

И если вас смущают громкие заявления - то научитесь их фильтровать.

Можно не только фильтровать, можно еще тех, кто такие заявления делает, спрашивать в лоб: «а чем докажешь?»

Проблема хейтеров вроде вас

Вот вы же опять ничем не сможете доказать, что я хейтер. Звиздануть на форуме — это вы запросто. Как и слиться потом.

Давайте я вам объясню как обстоят дела: язык C++ старый и сложный, то, что происходит внутри его комьюнити мне не очень нравится, посему найти какую-то адекватную замену C++ мне бы хотелось. Так уж получается, что в области нативных языков без GC единственная на данный момент альтернатива — это Rust. Но, поскольку острой насущной необходимости выбросить C++ и взяться за Rust нет, то можно приглядываться к нему постепенно. В том числе и переждать, пока Rust на остолопах вроде вас перерастет детские болезни.

Но присматриваясь к Rust-у хочется получать объективную информацию. А не маркетинговый булшит.

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

Если в стандартной библиотеке этих «нормальных языков» будет ошибка, то эта гарантия тоже может пострадать. Чем тогда это отличается от гарантии что в стандартной библиотеке раста не будет гонок?

Чем тогда это отличается от гарантии что в стандартной библиотеке раста не будет гонок?

Если говорить только про стандартную библиотеку, то ничем. Но ведь когда вы, например, говорите про гарантии Rust-а в отношении data races, вы же не только про стандартную библиотеку Rust-а, а вообще про любую программу на Rust-е, которая успешно скомпилировалась и слинковалась. Ведь так?

Тебе никто не гарантирует, что где-то в оперативке рандомно не флипнется один бит и у тебя Hello World не крашнется. Это дурацкая позиция. С точки зрения риск-менеджмента, ошибки, связанные с состоянием гонки, будут встречаться на много порядков реже обычных, при этом их легко локализовать. Т.е. они перестают быть фактором, который может помешать завершению проекта, т.к. вероятность встретить data race меньше, чем того, что главного программиста собьёт машина. Это не маркетинг, а тервер.

Вот вы же опять ничем не сможете доказать, что я хейтер. Звиздануть на форуме — это вы запросто. Как и слиться потом.

Доказывать что? Что вы в КАЖОМ треде, так или иначе связанном с растом откладываете кирпичи с завидным упорством? Ну мне кажется тут нечего доказывать.

Мне кажется на основе ваших споров в растотредах уже можно книгу писать «как тролеть растаманов».

Это не маркетинг, а тервер.

Гарантия, которая обеспечивается теорией вероятности — это что-то новое.

Ну и повторюсь для тех, у кого понимание написанного определяется тервером: речь не о том, помогает ли Rust бороться с data races и имеет ли он какой-то инструментарий для этого, а о том, насколько корректно говорить про «гарантии отсутствия data races» в Rust-овых программах.

Нельзя. Как минимум, потому что компилятор использует системный уровень и тебе никто не сможет 100% гарантировать, что при каких-то странных условиях мьютекс неправильно залочится.

Как по мне, так лучше говорить, что Rust существенно упрощает борьбу с data races или что в Rust есть языковые механизмы предотвращения data races. А не о гарантиях отсутствия этих самых data races.

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

Т.к. система владения не даст тебе использовать из разных потоков один изменяемый ресурс.

А эта система владения базируется на обещаниях, которые дает разработчик. Если разработчик обещал, что slice_at_mut вернет два непересекающихся диапазона, то на основании этих обещаний Rust скажет, что в коде все нормально.

Если разработчик не выполнил свои обещания, то Rust все равно скажет, что в коде все нормально.

Есть ощущение, что «безопасный код» в Rust-е — это такой сферический конь в вакууме. Поскольку базируется он на unsafe в стандартных и в сторонних библиотеках.

Достаточно прочитать про отношения безопасного и не безопасного кода в Rust и всё станет ясно. Если ты в unsafe делаешь что-то не безопасное, например, убиваешь указатель, то при обращении к этому указателю в безопасном Rust может произойти крах программы, но ты будешь знать, что безопасный Rust не мог вызвать проблему и косяк локализуется в unsafe. Даже тупице понятно, что нельзя сделать 100% безопасный код на основе не безопасного. Это всё описано в https://github.com/ruRust/rustonomicon

Вот вы же опять ничем не сможете доказать, что я хейтер. Звиздануть на форуме — это вы запросто. Как и слиться потом.

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

Если в стандартной библиотеке этих «нормальных языков» будет ошибка, то эта гарантия тоже может пострадать. Чем тогда это отличается от гарантии что в стандартной библиотеке раста не будет гонок?

Продемонстрирована возможность разработки частей Linux на Rust (комментарий)

А эта система владения базируется на обещаниях, которые дает разработчик. Если разработчик обещал, что slice_at_mut вернет два непересекающихся диапазона, то на основании этих обещаний Rust скажет, что в коде все нормально.

Эм, нет. Чё за бред? Хотя бы прочти что такое система владения в Rust

Если разработчик не выполнил свои обещания, то Rust все равно скажет, что в коде все нормально.

Что интересно, он будет абсолютно прав, в коде функции qsort ошибок не будет. Ошибка будет в функции slice_at_mut, и именно ее нужно будет править.

Эм, нет. Чё за бред? Хотя бы прочти что такое система владения в Rust

Ну посмотрели бы в код сперва: https://github.com/rust-lang/rust/blob/558cd1e393188a07bda413931aa88e82996d31...

Напоминает эпитафию: пешеход, ты был прав.

Единственный, кто тут сливается - это вы, со своей упёртостью.

Да, rust безопасный на 99%, а не на 100%. Все гарантии подробно описаны в доке. И по сравнению с другими популярными, системными языками их тупо больше.

Но присматриваясь к Rust-у хочется получать объективную информацию. А не маркетинговый булшит.

От вас никто, ничего не скрывает: https://doc.rust-lang.org/book/second-edition/ch01-00-introduction.html

Что из написанного здесь вам не понятно?

Мне не понятно, что не понятно вам.

Вы думаете, что начиная вот с этого сообщения мне что-то непонятно? Впрочем, это риторический вопрос.

Повторяю:

Да, rust безопасный на 99%, а не на 100%. Все гарантии подробно описаны в доке.

Когда я говорю тоже самое, то это получается наезд на Rust и хейтерство.

Вы, растоманы, чего такие нервные и мнительные?

Ну так это же не мы оскорбляем всех подряд.

Что из написанного здесь вам не понятно?

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

Вы написали бред

Значит вот здесь я не прав, правильно?

Ну т.е. когда говорят о гарантиях отсутствия data races нужно понимать, что временами эти гарантии на уровне «мамой клянусь».

Можно подробнее, в чем именно я не прав?

Ну посмотрели бы в код сперва: https://github.com/rust-lang/rust/blob/558cd1e393188a07bda413931aa88e82996d31...

    fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]) {
        let len = self.len();
        let ptr = self.as_mut_ptr();

        unsafe {
            assert!(mid <= len);

            (from_raw_parts_mut(ptr, mid),
             from_raw_parts_mut(ptr.offset(mid as isize), len - mid))
        }
}

что тут не так? Известен указатель, длина памяти на которую он ссылается и получается два изменяемых среза от ptr до mid и второй ptr+mid до ptr+len.

Ну так это же не мы оскорбляем всех подряд.

Далеко не всех, только тех, кто своим скудоумием ворует мое время.

Вот характерный пример. Человек настолько уверен в своей правоте, что не берет на себя труд прочитать, подумать и понять о чем вообще речь.

Вот характерный пример. Человек настолько уверен в своей правоте, что не берет на себя труд прочитать, подумать и понять о чем вообще речь.

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

И ещё 4 звезды, за что!?!?!?

Можно подробнее, в чем именно я не прав?

Всё то о чём вы засираете этот тред описано в rustonomicon, ссылку кинул уже давно

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

В этом смысле eao197 прав, но он не понимает основного смысла unsafe. Unsafe — это механизм описания алгоритмов, которые с точки зрения безопасного Rust не допустимы, но соответствуют всем гарантиям Rust. Из этого следует, что семантика Rust не идеальна, в результате чего и появился unsafe. Почему она не идеальна? Она не может предусмотреть того, что происходит за её пределами. К примеру, Rust понятия не имеет, что такое поток, естественно в нём нет поддержки механизмов синхронизации/взаимодействия потоков на уровне языка, все эти механизмы реализованы в библиотеках. Касательно split_at_mut, то натыкаемся на то, что Rust не реализует поведение среза, он делегирует это библиотеке (в данном случае core), а это не может быть реализовано без unsafe.

Unsafe — неизбежное зло, которое даёт возможность реализовывать свои собственные механизмы в рамках безопасности Rust о которых Rust не может знать.