В чем смысл Rust?

Давай, я тебе напишу.

Давай я тебе тоже напишу:

use std::io;

fn main() {
    let ar = [5, 6, 4, 3];

    let mut input = String::new();
    io::stdin().read_line(&mut input).unwrap();

    let index: usize = input.trim().parse().unwrap();

    println!("{}", ar[index]);
    println!("OK");
}

2
4
OK
$ ./1
19
thread 'main' (6190) panicked at 1.rs:11:20:
index out of bounds: the len is 4 but the index is 19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Чем паника лучше сегфолта? Более модно и молодёжно?

При этом раст всегда будет чекать в рантайме и тратить время. И вообще все эти безопасные растоперделки годны и быстры только в маленьком растомирке, когда компилятор видит все исходники, когда стат анализатор работает. При масштабировании, когда надо цеплять динамические либы, вся эта безопасность умножится на ноль + потеря производительности неминуемая т.к. стат анализатор не сможет отработать. Растаманы именно поэтому всё переписывают. Короче у раста есть фундаментальный изъян, который не позволит проекты сложнее некоторого порога

Можно не писать код с кучей выходов. Есть так называемое структурное программирование где не приветствуются методы нелокальных переходов вроде break, continue, return. возврат значения функции обязан быть в конце функции.

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

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

Чем паника лучше сегфолта?

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

чекать в рантайме и тратить время.

Ты предлагаешь в этой программе не чекать границы массива?

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

Ну если ты такой напуганный «out of bounds», то компиль в релизе с -fsanitize=address, получишь run time проверки на Си. Видел какой-то проект, который так и собирался в релизе. Можешь написать плагин в шланге, который будет запрещать c-arrays, указатели, что угодно хочешь. Грепать проект на наличие std::/using namespace std, подключать свою безопасную обертку над std - «using my_safe_library», которая делает проверки границ. В ц/цпп хотя бы есть выбор, а у вас никакого выбора нет - всегда безусловный и дорогой runtime check, нужен он кому-то или нет - никого не волнует. Ну и опять повторю в расте очень плохо с динамическими либами, это его родовая травма

И вообще, что лучше - упасть в рантайме или продолжить работу пусть и некорректно - вопрос дискуссионный. А если ты управляешь механизмом, ПО которого упало с ущербом на 100500 денег и трупами, кому будет хорошо от твоей паники в рантайме, которую ты не отлавливал т.к. раст «безопасен»?

Чем паника лучше сегфолта?

«дяденька а вы точно программист?» - тем что случается гарантированно до действительно плохого, например, стреляющего UB; и тем что гарантированно случается, а не как повезёт в случае сегфолта, ну и просто информативно более точна.

При этом раст всегда будет чекать в рантайме и тратить время.

Лол чего, нет, не всегда, и необходимость в этом сильно меньше чем даже в каких-нибудь плюсцах.

И вообще все эти безопасные растоперделки годны и быстры только в маленьком растомирке, когда компилятор видит все исходники, когда стат анализатор работает.

Э Э, как и в прорве других статически типизированных языков, в тех же плюсах HO-библиотеки таскают по тем же причинам. Cтаттипизация она такая, но она того стоит

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

Нет, с чего вдруг, ну и сейфити градуируемая штука и большая степень оной в любом случае лучше

Растаманы именно поэтому всё переписывают

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

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

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

тестить софт перед релизом

Ну, протестируй свою программу с вводом индекса для массива.

раст там у тебя или нет - разницы нет.

Система типов - сама по себе тест. Если типы продуманы, компилятор автоматически проверит все свойства программы, выраженные в типах.

ваша «безопасность» вас и погубит, вспомнишь мои слова.

Как ты себе представляешь себе этот сценарий?

не хочу втягиваться в затяжной спор с очередным растофанатом

Ты не хочешь втягиваться в спор, потому продолжаешь цепляться за нелепые тезисы вроде «когда надо цеплять динамические либы, вся эта безопасность умножится на ноль + потеря производительности неминуемая», хотя так и не можешь объяснить, что такого происходит при подключении функций из динамической библиотеки, что аж код меняется. Такая позиция не выглядит убедительно.

компиль в релизе с -fsanitize=address, получишь run time проверки на Си. Видел какой-то проект, который так и собирался в релизе. Можешь написать плагин в шланге, который будет запрещать c-arrays, указатели, что угодно хочешь. Грепать проект на наличие std::/using namespace std, подключать свою безопасную обертку над std - «using my_safe_library», которая делает проверки границ.

Ну т.е. по сути ты предлагаешь взять плохой язык и костылять поверх него, создавая новый костыльный плохой язык. И всё это вместо выбора другого языка. Зачем, ради мифической привычки к языку?

Ну, протестируй свою программу с вводом индекса для массива.

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

Система типов - сама по себе тест. Если типы продуманы, компилятор автоматически проверит все свойства программы, выраженные в типах.

Раст это сильно больше, чем система типов, это очень глубокий статический анализ, это очевидно любому, кто писал хотя бы хеллоу ворлд на нем. Не может быть никакого стат анализа сквозь разные elf. Ты оглянись вокруг, вы функции из so’шек вызываете в unsafe блоках. Вся ваша безопасность сливается в унитаз на стыках elf, без всяких проверок и гарантий

Ну т.е. по сути ты предлагаешь взять плохой язык и костылять поверх него, создавая новый костыльный плохой язык. И всё это вместо выбора другого языка. Зачем, ради мифической привычки к языку?

Не передергивай, я сказал, что если кому-то очень надо гарантированно падать в ран тайме в таких случаях, то это не сложно. Тот же плагин к шланг я костыли за час на коленках, можно исключить из языка любые там небезопасные c-array’ы при желании

В итоге твоя эта проверка в ран тайме не более чем оверхед, это не нужно.

Т.е. ты протестировал, и решил, что проверка ввода пользователя не нужна?

Не может быть никакого стат анализа сквозь разные elf.

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

вы функции из so’шек вызываете в unsafe блоках

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

плагин к шланг

Прикостыливая к шлангу плагин, ты создаёшь новый язык. Уникальный, которого ни у кого нет. Любой пользователь твоего кода попадает в ад с уникальным компилятором для неведомого диалекта си. Ты серьёзно считаешь это хорошим подходом?

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

Нельзя обеспечить работу вашего бороу чекера системой типов. Это серьёзный стат анализ со всеми исходниками в момент компиляции. Мы уже говорили об этом в другой теме.

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

Ты и в пасте ничего не сможешь, ну будет там поток в so’шке, который в рандомный момент времени делает mut ссылку из переданного по ссылке arc. Какой толк от твоей системы типов? У тебя тут два пути - либо дорогие телодвижения в ран тайме, либо серьёзные ограничения при вызове во внешние elf.

Прикостыливая к шлангу плагин, ты создаёшь новый язык. Уникальный, которого ни у кого нет. Любой пользователь твоего кода попадает в ад с уникальным компилятором для неведомого диалекта си. Ты серьёзно считаешь это хорошим подходом?

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

Нельзя обеспечить работу вашего бороу чекера системой типов.

Но это именно так и сделано. Всё, дальнейшие рассуждения на основе ложного тезиса невалидны.

будет там поток в so’шке, который в рандомный момент времени делает mut ссылку из переданного по ссылке arc

Это абсолютно никак не отличается от потока, делающего mut ссылку в рандомный момент, определённого прямо в программе. Добавление .so никак не меняет ситуацию.

программа должна падать в тестах

Ну вот у меня программа упала в тесте, когда юзер ввёл 19. Я добавляю проверку и получаю ровно то же, что мне сделает раст без всяких лишних тестов.

Но это именно так и сделано. Всё, дальнейшие рассуждения на основе ложного тезиса невалидны.

Дёшево это сделано не благодаря системе типов. Бесплатной безопасности при использовании либ у вас не будет. Знаешь, мне это прям не настолько надо, чтобы вот прям сейчас смотреть асм от растоподелок, для меня это и так очевидно. У вас все ок, пока есть исходники

Можно ссылку?

Кажется в расте придумали struct str {size_t size; char* ptr; };. Или std:string_view/std:span.

Это, конечно, рак либц. Тут ничего не поделаешь.

Чем паника лучше сегфолта?

Эм, вы сейчас серьезно? Это буквально разница между успел вытащить или не успел вытащить (между контролируемым падением и неконтролируемым повреждением памяти).

• Паника – гарантированная остановка в определённой точке (или unwind/abort).
• Сегфолт – авария из-за недопустимого доступа к памяти, часто как следствие UB.

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

Сегфолт же обычно случается после того, как где-то уже произошло UB, которое могло тихо испортить данные, сломать кучу или создать уязвимость.

Те паника останавливает выполнение в момент обнаружения ошибки (до превращения в мясорубку), а сегфолт уже после того, как последствия начали расползаться (после превращения в мясорубку).

Поэтому паника лучше чем сегфолт.

https://tsar1997.blogspot.com/2019/11/blog-post.html

https://tsar1997.blogspot.com/2019/10/blog-post_24.html

https://tsar1997.blogspot.com/2019/10/blog-post_19.html

https://tsar1997.blogspot.com/2019/10/1.html

https://tsar1997.blogspot.com/2019/10/3.html

https://tsar1997.blogspot.com/2019/10/2.html

https://tsar1997.blogspot.com/2019/10/blog-post_6.html

И т.д. Можете просто домен открыть, там не так много постов. Ссылки на gitlab ищите там сами. Merge request можно искать по тексту моего сообщения там: Son, I am disappoint.

уже тут ответили достаточно признано конфесионнально

при этом течений много

ваще что паника что сегфолт это нештатное

и опят же зависит от количества слоёв - всёж паника более софтовое

сегфолт впочем тож не предел харда ибо и при сегфолте ожидается что процессор не в halt упал тем более ща когда многопоточное

в целом вопрос о контурах безопасности внутри(исключения там) - между(паника как ябеда)на ходу - в_объемлющей_системе (сегфолт - умерло при исполнении) посмортем

Ссылки на gitlab ищите там сами. Merge request можно искать по тексту моего сообщения там: Son, I am disappoint.

Не удалось(