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

У меня есть ощущение, что мне приходится общаться с малолетними дебилами (c), которые позволяют себе ссылаться вот на это:

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

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

Малолетний дебил (c) в силу скудоумия и отсутствия опыта даже не может себе вообразить ситуацию, когда некий условный Федя Иванов пишет на безопасном Rust-е свой вариант распараллелиного qsort-а. В котором задействует стороннюю библиотеку от условного Васи Пупкина. В библиотеке этой, для обхода контроля borrow checker-а, Вася Пупкин задействовал unsafe (ну вот почти так же, как это сделано в упомянутом выше split_at_mut). Но Вася ошибся и иногда у него возникают перекрывающиеся диапазоны, параллельный доступ к которым из qsort-а приводит к порче данных.

Федя Иванов доволен как слон, у него же безопасный Rust, компилятор ему все проверил. А вот пользователь программы Феди Иванова сталкивается с тем, что иногда эта программа выдает муть.

Виноват, по мнению малолетнего дебила (с), конечно же, Вася Пупкин. Ну еще и некто eao197, который говорит какой-то бред на счет «гарантий отсутствия data races в Rust». Так победим!

Вася Пупкин задействовал unsafe

Но Вася ошибся

Виноват, по мнению малолетнего дебила (с), конечно же, Вася Пупкин. Ну еще и некто eao197

Все сходится :)

Ну, я бы добавил еще и «Rust гарантировал». Тогда точно все сходится :)

eao197

Уже лучше, читай дальше следующую главу. А то пока в целом ни чего не изменилось, как ты не понимал что такое гарантии так и не понимаешь

Ну, я бы добавил еще и «Rust гарантировал». Тогда точно все сходится :)

Раст гарантировал Феде что это точно не его косяк. И опираясь на эту гарантию, Федя знает кому пойдет бить морду.

Федя знает кому пойдет бить морду.

XD

Ну я же говорю, пешеход, ты был прав.

Их разработка началась где-то около 2011-го. Практически в одно время. Доступные для использования превью Kotlin-а появились вскоре после Ceylon 1.0.

Не столько в контексте Kotlin/Ceylon, но вообще дата начала разработки может мало о чём говорить. Если один язык делается силами большой корпорации без всяких анонсов, а потом сразу выпускается 1.0 в более-менее финальном виде и с кучей батареек - это одно. А если вначале (и хорошо если только вначале) вся работа ведётся одним человеком по выходным - совсем другое. Ну и до кучи до «релиза» руки, в принципе, развязаны и язык может сильно меняться, как это и было с растом.

Чем раст дебажить? Там только ir можно дебажить? Без наездов, просто мне нужно.

Чем раст дебажить?

gdb 7.12

так или иначе связанном с растом откладываете кирпичи с завидным упорством?

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

так или иначе связанном с растом откладываете кирпичи с завидным упорством?

Тезка, не путайте настоящих троллей с косящими под них самозванцами!

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

Контроль качества на основе выборки (одна из любимых задач в теорвере) — не, не слышал.

Контроль качества на основе выборки

Хотите сказать, что в Rust-е контроль за лайфтаймами и отсутствием гонок на вероятностном подходе основан?

При разработке приложения на С++ у тебя будет 1000 проблем, из них 500 - состояния гонки. При разработке приложения на Расте у тебя будет 501 проблема, и состояние гонки случится только в одной из них. Т.е. статистически таких проблем практически не существует.

Т.е. статистически таких проблем практически не существует.

Даже если не рассматривать сейчас ситуации, когда статистически таких проблем нет, а на практике они есть, в чем вы видите противоречие вот с этим?

Хотите сказать, что в Rust-е контроль за лайфтаймами и отсутствием гонок на вероятностном подходе основан?

Нет, я хотел сказать именно то, что сказал. Не нужно пытаться натужно прочитать между строк.

ЗЫ:к ответившему выше тезке отношения не имею.

Нет, я хотел сказать именно то, что сказал. Не нужно пытаться натужно прочитать между строк.

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

Для нескольких unsafe примитивов на пару тысяч строк можно формально доказать корректность. С целой либой на миллион ничего кроме «мамой клянусь» не прокатит.

Ну так и в чем же я не прав?

Для нескольких unsafe примитивов на пару тысяч строк можно формально доказать корректность.

Смотри тему _этого_ топика и что там внутри :) А внутри там неонка, да :)))) Любая програма на ржавом, которая делает что то полезное, а не считает сферических коней в вакууме выглядит так: начало Вывод ЧСВ аффтара и ссылка на ***оно репку в гитхабе unsafe { код } конец

С целой либой на миллион ничего кроме «мамой клянусь» не прокатит.

Ну то есть преимуществ перед С\С++ нет?

Растишки такие забавные карапузы (правда надоедливые и назойливые) :)

Нет такого проекта на гитхабе который растишки не кинулись бы переписывать на ржавеньком :)

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

А потом тихий слив :-D :))))

Типо:

Я мог бы Rust добавить, проект очень крутой
Вот человек уже пытался, даже рантайм написал, но в итоге не осилил: https://github.com/kaitai-io/kaitai_struct/issues/22

Растишки сейчас начнут свою любимую песню о том, что этот мол не смог, не заржавел ещё достаточно, но мы де - подхватим упавшие труселя знамя и тыгыдым-тыгыдым :)

Но факт остаётся фактом:

• Нет такого проекта на гитхабе который растишки не кинулись бы переписывать на ржавеньком
• И нет такого проекта изЪ - который бы они успешно доделали! :)))

Сам по себе Rust - язык не хуже (и не лучше) других. Но растишки - это что-то! :)

И нет такого проекта изЪ - который бы они успешно доделали! :)))

Наглое 4.2

https://github.com/BurntSushi/ripgrep

https://github.com/RazrFalcon/svgcleaner :)

Но с неадекватом спорить бесполезно.

О я-я! Нацюрлих! Целых __два__ примера сомнительной полезности :-)

О чем и спичЪ :)

Но тут другое интересно: несколько привлекателен бы был Rust, если бы в нем поддержку ООП сделали

ООП не ООП, а вот если бы исключения сделали, я бы на Раст обратил серьёзное внимание.

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

Имеется такой стек вызовов A -> B -> C. C кидает исключение, А его ловит, все хорошо.

Теперь пришел новый программист Вася, почитал код функции B, как там все красиво и не возникает никаких ошибок, и притянул вызов B к себе в код. Получилась цепочка D -> B -> C. Теперь если С кинет исключение, то D его уже не словит, и программа упадет.

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

А дальше начинаются костыли вида checked exceptions или catch(Throwable e), один не лучше другого.

Во-первых, все вовсе не так печально, как вы пытаетесь изобразить. По крайней мере вне мира Java.

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

Во-вторых, в Rust-е есть и Result, и паника.

В руководсте от гугла написано:

The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!

Это как раз то что рекомендуется в расте. Исключения только для исключительных ситуаций.

Исключения не гарантируют полноценную инициализацию переменных, что недопустимо в Safe Rust.

Звучит, как бредятина. Как раз исключения и убирают лишний геморр при инициализации сложных объектов и агрегатов.

Исключения не гарантируют полноценную инициализацию переменных, что недопустимо в Safe Rust.

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

Он наверное имел в виду такой кейс

let mut a = A::new();

panic::catch_unwind(|| {
    a.do_smthng();
}).ok();

println!("{:?}", a);

В последней строке `a` может содержать логически неверное состояние.

Паника приведёт к завершению проги, если её не ловить. То есть это не способ сообщить об ошибке.

Логические - да. Но в C++ мы можем получить неинициализированную переменную, которая будет содержать мусор. В rust такого не будет.

Если посреди конструктора будет брошено исключение, то мы получим не до конца инициализированный объект.

Еще раз,

Исключения не гарантируют ..., что недопустимо в Safe Rust.

Так что будет недопустимого если сделать исключения такими же безопасными как сейчас panic?

Если посреди конструктора будет брошено исключение, то мы получим не до конца инициализированный объект.

o_O

Это вы про какой язык? Про Rust?

eao197

https://news.ycombinator.com/item?id=14517335

Про C++.

Про C++.

Пруф или не было.

По ссылке чел предлагает разрешить переключать варианты enum не перемещая совпадающие поля, на что ему ответили что такая фича будет не безопасна в присутствии panic.

Не вижу тут ничего особенного.

Что это было? Какое отношение метод init имеет к инициализации объекта?

Разве это было концептуально невозможно сделать?

Концептуально — возможно было и раньше. Часть вещей с тех пор как стабилизировали фичу no_std (т. к. в пространстве ядра нет необходимых для libstd вещей), часть до сих пор только в nightly. Например, макрос asm! до сих пор формально нестабилен, т.е. может поменять синтаксис.

Просто пример.

Просто пример.

Пример того, что вы не знаете C++?

Еще раз: какое отношение метод init имеет к инициализации объекта?

Ок, так и быть, упрощаю:

class Data {
public:
    Data() {
        v1 = 1;
        throw "error";
        v2 = 2;
    }

public:
    int v1;
    int v2;
};

{
    Data *d;

    try {
        d = new Data();
    } catch(...) { }

    std::cout << d->v2 << std::endl;
}

Ну и где вы здесь видите неинициализированный объект типа D?

Неинициализированным осталось поле v2.

В расте же мы может изобразить только:

use std::panic;

#[derive(Debug)]
struct Data {
    v1: i32,
    v2: i32,
}

impl Data {
    fn new() -> Data {
        Data {
            v1: panic!(),
            v2: 2,
        }
    }
}

fn main() {
    let d = panic::catch_unwind(|| {
        Data::new()
    });

    println!("{:?}", d);
}

Ну и инициализируй указатель дефолтным значением до try {} catch, не будет проблемы с неинициализированным указателем.
Что ты пытаешься доказать? Что на Rust такое не скомпилируется? Дак это и ежу понятно