Очередного обсуждения Rust тред

Вектор - один и тот же, ни разу не копируется. То же самое будет и с Box. Какой-нибудь Arc<T> можешь хоть в static запихнуть

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

fn caller() {
let mut a = Arc::new(Mutex::new(vec![1, 2, 3, 4, 5]));

std::sync::Arc — это один сплошной unsafe.

Только если эта unsafe операция не является распространённой вещью, которую уже завернули в safe обёртку. Если не нравится once_cell, можешь взять lazy_static. Во втором так мало кода, что даже человек с одним полушарием сможет провести аудит, если вдруг мучает паранойя по поводу крейтов.

use std::sync::Arc;
use std::sync::Mutex;
use std::thread;

use once_cell::sync::Lazy;

static GLOBAL_A: Lazy<Mutex<Vec<i32>>> = Lazy::new(|| {
   let a = vec![-2, -1, 0];
   Mutex::new(a)
});

fn callee1() {
    let mut a = GLOBAL_A.lock().unwrap();
    a.push(6);
    a.push(7);
}

fn callee2() {
    let mut a = GLOBAL_A.lock().unwrap();
    a.push(8);
    a.push(9);
}

fn caller() {
    {
        let mut a = GLOBAL_A.lock().unwrap();
        a.extend(vec![1, 2, 3, 4, 5]);
    }
    
    let thread1 = thread::spawn(callee1);
    let thread2 = thread::spawn(callee2);
    
    thread1.join();
    thread2.join();
    
    let a = GLOBAL_A.lock().unwrap();
    for i in a.iter() {
        print!("{} ", i);
    }
    println!();
}

И что? Внутри есть unsafe, да, но что это меняет? Он же работает корректно, скорее всего - в 100% случаев, и мне не приходится самому выяснять и разбираться насколько (un)safe моя операция. Это ли ни хорошо?

Не-отравляющий unsafe.

Мне нравится эта цитата из книжки Александреску про D:

Ожидаемая реакция программиста, заметившего на полке книжного магазина издание «Язык программирования XYZ» - «Даю себе ровно 30 секунд, чтобы найти в нём что-нибудь, что мне не понравится». Изучение языка программирования требует времени и усилий, а результаты появляются не сразу. Попытка избежать этого - проявление инстинкта выживания. Ставки высоки, вложения рискованны, так что лучше уметь принимать быстрое решение «против».

Вот если говорить о быстром «против», то проблема Rust (а также D и Nim) в том, что его делали плюсовики. Эти языки могут притворяться питоном, шарпом, окамлом, но на самом деле это опять плюсы, у которых есть две особенности: любовь к садомазохизму и стремление усидеть на нескольких стульях. Но плюсы хотя бы это особо не скрывают.

Кроме того, неясно какой язык хочет заменить Rust. C++ более высокоуровневый, более мощный, хоть и за счёт костылей. Си - более простой, низкоуровневый.

Неясно, почему вместо unsafe просто не использовать сишные библиотеки, как это делают другие языки. Всё равно же используете gtk, значит не осилили вытеснение Си. А Си не сможете вытеснить, потому что убеждены, что недостаток Си в том, что у него недостаточно ФП. Наоборот же, в Си избыток ФП. Ибо если главная сила Си в том, что он кроссплатформенный ассемблер, то убийца Си должен быть больше похож на ассемблер, а не на окамл.

И что? Внутри есть unsafe, да, но что это меняет? Он же работает корректно, скорее всего - в 100% случаев

дамы и господа, знаменитые гарантии безопасности раста

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

а что вообще подразумевается под «знать раст»? Там же в принципе нет нифига заслуживающего изучения - знай себе хреначь кашу из трейтов с лайфтаймами, пока кукуха не поедет)

дамы и господа, знаменитые гарантии безопасности раста

Тебе никто и не обещал никаких 100% гарантий. Когда сможешь доказать что в std есть решето - тогда и приходи.

а что вообще подразумевается под «знать раст»? Там же в принципе нет нифига заслуживающего изучения - знай себе хреначь кашу из трейтов с лайфтаймами, пока кукуха не поедет)

Подразумевается что прежде чем заявлять «небезопасно»/«криво»/etc ты находишь конкретные грабли, а не агрессивно несёшь бессвязный бред, состоящий из домыслов. Твоё мнение, в общем-то, тоже не заслуживает внимания ¯\_(ツ)_/¯ Да и подобную дичь можно вывалить в сторону любого языка.

А что первый тред снесли? У кого-то (не будем называть по имени) бомбануло?

Когда сможешь доказать что в std есть решето - тогда и приходи

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31162 - ну вот например, свежая CVE в std. Я уж молчу про всякие молчаливые UB при кастинге флоата к инту и т.п., которые не фиксились годами

Подразумевается что прежде чем заявлять «небезопасно»/«криво»/etc ты находишь конкретные грабли, а не агрессивно несёшь бессвязный бред, состоящий из домыслов. Твоё мнение, в общем-то, тоже не заслуживает внимания ¯_(ツ)_/¯

а, понятно, очередная бездарность скатилась до личных оскорблений. Хотя чего я ожидал, в раст-комьюнити только такие и обитают :)

Ну он сейчас не отравляющий. Надо чтобы был отравляющий? Или оба? Если только отравляющий, то зачем такое если на нем делается стандартная библиотека by design?

Дыры в якобы безопасной модели.

Какие дыры? Утечка памяти? Насколько вероятно наткнуться на эти дыры в реальном коде без намерения это сделать?

double free can occur in the Vec::from_iter function if freeing the element panics

Наступают на те же грабли, которые в С++ уже лет так 20 назад прошли.

Отвратительный, нечитабельный синтаксис, даже по сравнению с плюсами. Один компилятор. Отсутствие возможности lock-free программирования в safe моде. Наличие unsafe мода.

хаскелль

минимум 5-10 лет сидеть на C++/Java/C#

Вы так говорите, будто это плохо.

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

Это только один критерий, который вы только что выдумали.

Как же старичьё корёжит от одного существования Раста, прямо как чёрта от свечки) Собаки лают, караван идёт)

Куда идет?

В светлое будущее.

Только если эта unsafe операция не является распространённой вещью, которую уже завернули в safe обёртку

use once_cell::sync::Lazy;

https://docs.rs/once_cell/1.7.2/src/once_cell/lib.rs.html#498

            // Note that *some* forms of reentrant initialization might lead to
            // UB (see `reentrant_init` test). I believe that just removing this
            // `assert`, while keeping `set/get` would be sound, but it seems
            // better to panic, rather than to silently use an old value.

https://docs.rs/once_cell/1.7.2/src/once_cell/lib.rs.html#860

        /// It is an error to reentrantly initialize the cell from `f`.
        /// The exact outcome is unspecified. Current implementation
        /// deadlocks, but this may be changed to a panic in the future.

«Г» — гарантии. Чот safe получается ни разу не safe. Гладко было на бумаге, да забыли про овраги. Попадание в дедлок считается безопасной операцией, чо.

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

И что? Внутри есть unsafe, да, но что это меняет? Он же работает корректно, скорее всего - в 100% случаев, и мне не приходится самому выяснять и разбираться насколько (un)safe моя операция. Это ли ни хорошо?

Плохо то, что без unsafe операций в Rust почти ничего нельзя сделать. То есть, иными словами, любая программа на Rust обязана быть построена на unsafe операциях.

И чего тебе не хватает в повседневной жизни без unsafe, не беря в расчёт FFI?

Эти языки могут притворяться питоном, шарпом, окамлом, но на самом деле это опять плюсы, у которых есть две особенности: любовь к садомазохизму и стремление усидеть на нескольких стульях. Но плюсы хотя бы это особо не скрывают

И тут я вспоминаю твою цитату:

Почему все же с++ такой сложный язык? (комментарий)

должен ли язык быть априори настолько сложным для достижения мощи как в с++ Да, должен, если язык один. Но можно пойти и другим путём: комбинацией нескольких языков попроще. В данном случае мощь может даже возрасти

Действительно ли «мощи»? Представь, что мы выкинули из языка последней версии стандарта наследование, оставив RAII, и сделали библиотеки на замыканиях, выкинули всю совместимость с Си, переведя ее на уровень «инлайн ассемблера» (то есть, полностью чужеродного языка). Язык потеряет эдак половину сложности, при этом его мощь почти не изменится. Проблема иллюстрируется цитатой 37-давности — уже тогда роль эффективных манагеров и просто безмозглых потребителей была хорошо видна:

«Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.» — Edsger W. Dijkstra (1930-2002) «On the nature of Computing Science» (EWD896) August 10, 1984

То есть, язык-то можно сделать такой, и будет он эффективнее C++ без потери мощи... но его никто не купит. Покупают фичу. У вас есть фичанейм? Нету? Тогда нам ваш инструмент не нужен? У вас есть молоток, который подкручивает болты при забивании? Нет? Зачем тогда нам нужны ваши инструменты... Что? Отвертка? Шуруповерт? Нас ваши маргинальные технологии не интересуют, у нас серьезный бизнес и мы забиваем болты только проверенными инструментами.

Какие дыры? Утечка памяти? Насколько вероятно наткнуться на эти дыры в реальном коде без намерения это сделать?

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

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

Видимо, именно поэтому с Плюсов слезают на что угодно: на Джаву, Шарп, Гоу, плодятся многочисленные замены. И что им на «проверенных инструментах» плохо?

Это только один критерий, который вы только что выдумали

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

Си спокойно живёт и без огромного количества коммерческого спроса.

О, найдена потенциальная уязвимость в ориентированном на безопасность Раст, ну что ж, тогда так и будем ещё полвека сидеть на кишащем уязвимостями на каждом шагу Си, а что ж делать, а куда деваться

Я первым уйду с сихи, если предложат годную альтернативу. Но где она? Ближайшая адекватная — это кресты, но в моем текущем проекте многопоточки преимущества от крестовых безопасных контейнеров настолько скромны, что ими можно пренебречь. Если бы я писал достаточно сложную высокоуровневую однопоточную логику — тут да, вариантов нет, только кресты. Я уже имел опыт писания логики на Си при разработке Anjuta/Glade, и это был ад, я в ужасе убежал оттуда после окончания GSoC.

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

Но раст в качестве альтернативы? Ололо, как мне это компилировать? Точнее, как пользователю компилировать мою либу у себя на машине. Компилятор Си хотя бы есть для каждого утюга. И даже если допустить, что я все-таки провел пользователя через огонь и лед, смог корректно поставить раст себе на машину — что даст мне, как писателю, раст? Не может дать никаких гарантий при работе с разделяемыми данными — в нем сомнительные гарантии даже для однопоточки. Да, фундамент в виде неизменяемых данных, локализация изменяемых данных, продвинутого вывода типов, да и вообще более современного и развитого синтаксиса — это приятно, но не стоит гемора, который поставляется с растом единым пакетом, без возможности применить плюшки и отказаться от гемора.

Ох, ну тогда и Раст живёт уже 15 лет, и тоже без этого вашего коммерческого спроса😏

Rust компилирует сам себя почти час.

Такое же вонючее дерьмо как C++, тоже мне крестоубивец, яблоко от яблони упало совсем недалеко.

И чего тебе не хватает в повседневной жизни без unsafe, не беря в расчёт FFI?

Я приводил пример Arc — в достаточно кривых руках оно валит программу или приводит к дедлоку. Такого поведения очень много в расте, отличие от C/C++ лишь в том, что вместо UB программа сразу валится — вот и вся «безопасность». А без unsafe я не могу работать с разделяемыми данными. Если же мне действительно нужно работать с ними и стандартной либы не фатает, то я бегу искать еще одну либу, в которой за меня написали нужный мне unsafe.

Си спокойно живёт и без огромного количества коммерческого спроса

Это как минимум линукс и питон. Весьма крупные ниши по состоянию на 2021 год. По этой причине я сам надумал в эти ниши залезть — они еще нескоро исчезнут.

как пользователю компилировать мою либу у себя на машине

Пользователи твоей либы сплошь гентушники? Зачем им компилировать её каждый день?

Компилятор Си хотя бы есть для каждого утюга

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

что даст мне, как писателю, раст?

Да много чего. Единый репозиторий пакетов, единую систему сборки проекта и документации, единую систему тестирования, хорошо оптимизированный паттерн-матчинг, офигенные перечисления, единую систему типов, мощный вывод типов, гибкие типажи, благодаря которым можно с литералами обращаться, как в скриптухе - вызывая методы и вот это всё. Я даже молчу про куда большие гарантии компилятора. Например, целочисленное переполнение или куда более строгое приведение типов. Сишники считают, что они за всем уследят, но человеческий фактор играет роль даже в значительно более автоматизированных системах.

Ну и Раст тупо приятнее разумным сочетанием привычного всем Си-подобного синтаксиса и уместными заимствованиями из функциональных языков.

Только вот эти ниши создало сообщество. Это я к тому, что не корпорации всё решают.

Ну так в Цпп компилятор однопроходный, а в Раст рекурсивный. В Цпп ты никак не сделаешь вывод типов в пределах лайфтайма. Или расположение объявление/определение в произвольном порядке.

В Раст поведение при исключении сильно разнится в зависимости от того, какой режим компиляции выбран, debug или realise. Ты точно это учёл?

Под такие требования C++ будет выше крыши.

Под какие такие? Я просто спросил, я не формулировал требования.

Причем, очень многие разрабы считают точно так же, потому на Rust не переходят.

Это понятно, но даже в лучшем C++ коде в мире периодически находят ошибки при работе с памятью в самых разных местах, которые в Rust были бы невозможны. Поэтому тут C++ даже близко не конкурент Rust-у. По сути C++ уже устарел. А разрабы - ну я знаю разрабов, которые на дельфе пытались до последнего писать, пока их уже ссаными тряпками не погнали.

которые в Rust были бы невозможны.

Опять херню вещаем? В прошлой теме показали, что любую ошибку на С++ можно повторить на Rust. Как например разыменование нулевого указателя.

Только вот на время компиляции забивать полностью не стоит.

Конечно, уже есть даже новая(?) бизнес-модель, как можно зарабатывать деньги, усложняя языки, и следоательно переусложняя компиляторы. https://blog.nelhage.com/post/building-llvm-in-90s/ Хочешь собрать компилятор здесь и сейчас - сегодня это уже 40 центов, а что будет завтра…

Ты сам выбрал путь страданий. Ей богу, ругать язык на время сборки компилятора — это нужно быть гентушником.

Do you have a large C or C++ codebase

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

Ей богу, ругать язык на время сборки компилятора

Компиляции, но не только самого компилятора.

У вас есть молоток, который подкручивает болты при забивании? Нет? Зачем тогда нам нужны ваши инструменты… Что? Отвертка? Шуруповерт?

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

Что касается C++, то я думаю, что у него проблема в изначально неряшливом исполнении. Например, никогда нельзя быть уверенным, сгенерируется ли исключение при ошибке в использовании библиотечной функции. Надо читать подробности по каждой функции. А если исключение сработает, то имя у него может быть типа domain_error. И гадай, что это значит. Почему нельзя было назвать arithmetic_error?

Вот таких мелочей много и потому ещё язык сложный. Можно было бы почистить и получить D. Но D не удержался и зачем-то добавил сборщик мусора. Тогда за дело взялся Rust и просто выкинул все исключения. Зато напихал всякой новомодной ерунды. Swift туда же (возможно, ты на него намекал). Не могут просто почистить плюсы, всё время куда-то заносит.

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

Опять херню вещаем? В прошлой теме показали, что любую ошибку на С++ можно повторить на Rust. Как например разыменование нулевого указателя.

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

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

поучи Rust, вот копия той мути которую писали на С++, только на Rust.

И 0 предупреждений: https://gcc.godbolt.org/z/oqTG8P545

что я все-таки провел пользователя через огонь и лед, смог корректно поставить раст себе на машину

Серьёзно? Откуда такой пафос? Иногда достаточно sudo apt install cargo. Если нужна свежая версия, то взять инсталятор из https://forge.rust-lang.org/infra/other-installation-methods.html#standalone-installers или установить онлайн.

Если хочется проверить все исходники глазами на наличие закладок и потом забутстрапить компилятор из исходников, то, да, придётся очень долго страдать. Просто забутстрапить из исходников, имея только компилятор С, можно с помощью mrustc (см. https://github.com/dtolnay/bootstrap )

Не может дать никаких гарантий при работе с разделяемыми данными

Какие гарантии-то нужны? Есть гарантии отсутствия несихронизированного доступа к разделяемым данным, то есть отсутствие data races. Гарантии отсутствия race conditions? А где они вообще есть?

Надо чтобы был отравляющий?

Да.

то зачем такое если на нем делается стандартная библиотека by design?

Не было бы большей части CVE из списка выше.

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