В чем смысл Rust?

Чтобы через закладки удаленно контролировать софт

Потому что пердолить PDP-11 в 2к26 никто не хочет.

На Си и безо всяких валгриндов можно писать софт без битья памяти. Я например даже не знаю как этот валгринд запускать.

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

Уверен, что битья памяти и утечек в твоем софте нет? Valgrind позволяет в этом удостовериться.

Можно, но очень осторожно. Хотя и на Java можно писать так, что память течь будет.

Даже Valgrind не является гарантией. Хотя и снижает риски утечек значительно.

Получается куча разработчиков до сих пор не пользуется valgrind’ом и пишет с утечками?

Ну, Rust тогда тоже не является гарантией. Странно доверять на все 100% компилятору Rust’а, но не доверять valgrind’у, хотя, насколько я понимаю, он заменяет через динамическую библиотеку функции malloc и т. д. в программе на свои для определения утечек после конца работы программы и битья памяти, а Rust действует на уровне исходного кода, что менее надежно.

Ну, valgrind гарантирует на 99% отсутствие проблем с памятью. Без него тоже можно, но valgrind дает возможность все знать.

Кажется вы не совсем хорошо понимаете как работает боров в Rust’е, и почему его гарантии вполне надёжны.

(Если чо, я не настаиваю, что ошибки обращения к памяти единственный или главный класс ошибок в ПО)

В том-то и дело, что боров даёт 100%.

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

...В чем смысл Rust?

«В чём сила, брат?» ©

«Извините, товарищи, переволновался.» © 😁

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

выравнивание рельефа

Тут прям мем напрашивается: «Можно, а зачем?». Если это удобно будут пользоваться, нет - умрет. Вон тут фанат PureBasic бегает. Его любимый язык - то еще чудо.

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

В его евангелистах

В чем смысл коряво вбрасывать с аккаунта-однодневки - вот вопрос.

За тем же, зачем и Java.

Чтобы писать более-менее нормальный софт в прод, условному джуну на Rust/Java нужно 6 месяцев обучения, а на С/С++ - минимум год.

Правда чтобы стать синьором на Rust/Java нужно ещё лет 5-7, а на С/С++ - плюс пару лет. Потому как о безопасности кода программист на С думает каждый день, а на Rust/Java - раз в год, когда словит утечки памяти там, где обещали что их нет, и пару неделек побъется головой о стенку.

Я знаю как обмануть borrow_checker, но это не его вина, а вина программиста, так как borrow checker такие проверки не делает.

///Если это конечно не исправили
let mut a = vec![1,2,3,5];
let n: usize=100; // тут условность n должна вычислятся в рантайме
a[n]=1000;

вариант классика описан в документации

let a =Rc::new(RefCell::new(10));
let b = a.borrow_mut();
b=100;
let c = a.borrow();// здесь захватить не получится будет ошибка, так как предыдущий захват не отпущен 

Но все это рантайм

насколько я понимаю, он заменяет через динамическую библиотеку функции malloc и т. д.

Точнее, так делает Memcheck, но Valgrind это не только этот инструмент.

Чтобы похоронить GPL и перетащить всех на MIT

Ну нет конечно. Давай вот о чём подумаем: пусть у нас есть БД с которой мы как-то работаем и какой-то коннектор к ней. ЯП пусть ООП с кучей защит от утечек памяти. Соединение с БД программист не закрывает, а когда ему надо к БД подключиться создаёт коннекторы и коннекты к базе. Внимание вопрос - будет ли течь память (ответ - да, а ещё и СУБД будет держать коннекты и там тоже будет всё пухнуть, правда СУБД по таймауту будет отваливать их, но если создавать их быстрее чем таймаут, то и СУБД прилечь сможет в теории, может и удалённый компьютер ляжет на котором СУБД работает, но на практике у взрослых СУБД как правило есть параметр на максимальное количество подключений, но может у каких-то маленьких и малоизвестных СУБД его и нет, например у встраиваемых субд вроде H2 я не припомню о таком.)

Хорошо, фиг с ними с СУБД. Программист читает файлы с диска и не закрывает их за собой (тут ОС начинает течь, у неё ресурсы на это неризиновые, в какой-то момент она не даст открывать новые файлы, или оперативка кончится, будет развесёлый краш, потому что скорее всего безалаберный программист не закрывающий файлы даже не мог подумать что ОС ему фигу на открытие файла может показать). Потому всякие with open придумали в современных ЯП, чтоб люди не понимающие и не слышавшие даже про ulimit не творили дичь.

Ладно, все эти файлы, БД, это внешние ресурсы, там задействованны чужеродные средства к которым ни у компилятора ни у Valgrind-а доступа нет - ОС, СУБД, чужие программы, удалённые компьютеры и иже с ними. Путь наш горе погромист пишет YAGF. Он знает и про лимиты и про то как с файлами работать, а далее принимает гениальное решение - складывать файлы в оперативку. А дальше юзер хочет целую книгу обработать из 100500 больших и тяжёлых сканов. Формально память нигде не течёт, код её почистит когда всё загрузится и обработается. А по факту чтоб оно загрузилось требуется неизвестно большой объём оперативки, больший, чем объём обрабатываемых файлов. Никакой ленивой загрузки там нет, ленивое это у шарпистов, джавистов и прочих высокоуровневых языков, сишники так не пишут. Итог софт весело выжирает всю оперативку, затем приходит OOM killer и убивает зажравшуюся программу? Нет, не тут то было. Из коробки без специальных настроек OOM killer приходит и убивает те программы, которые не работают активно (т.е. софт который активно пытается выжрать всю оперативку читая диск занят с его точки зрения важным делом, вон как странички памяти выделяются и читаются, а какой-то dbus который стартанул 3 часа назад и вяло что-то делает раз в 5 минут неважен). Потом конечно когда OOM killer убъёт всё важное и останется только самое критичное то YAGF будет повержен (возможно, если зависание позволит ему отработать, почему-то на практике это не всегда так), то он убьёт и YAGF, правда юзер может оказаться уже без графики, половины драйверов и в голой консольке с ядром в обнимку. Но формально память не текла, алгоритм выполнял свою работу, просто памяти не хватило. Бывает.

на Си с условным valgrind можно писать код без утечек и битья памяти переполняющимися буферами?

Можно, но почему-то не пишут.

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

Мне все равно, как какой-то боров в Rust работает, . к. я на Rust не пишу и не собираюсь.

Кому нужен 1%? И я думаю, что это даже не 1%, а 0.1%. И Десять лет критической уязвимости в Rust .

Ну, valgrind гарантирует на 99% отсутствие проблем с памятью. Без него тоже можно, но valgrind дает возможность все знать.

Нет. Valgrind работает только в рантайме, и проверяет запущенный код. Если какая-то функция не была вызвана в данной сессии запуска, она и не будет проверена.

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

один cargo уже серьезная заявка

Из-за него Rust без Интернета не работает, поэтому это моя главная претензия к Rust. Про unsafe я уже говорил, Си и так в прямых руках safe. Строки в Си вполне подходят под его концепцию языка без лишних типов. Абстракции идут лесом, параллельный код в Си спокойно и легко пишется в fork(). Вытесненить Си Rust не способен из-за своей ущербности. К тому же, в России писать на Rust легально только потому, что на него всем пофиг, а crates.io вполне может быть заблокирован РКН.

Проверку логической работоспособности программы ты все равно делаешь, вот и пускай программу под valgrind, увидишь все. А Rust принуждает писать тормозной safe код.

На другом языке тебе valgrind во время проверки работоспособности программы все расскажет.

это как здесь любят писать 4.2

Это не аккаунт-однодневка, а серьезный аккаунт, созданный не для вбросов.

Rust гораздо сложнее C (именно C, а не C++). К тому же, Rust нормальному программисту на нормальных языках Rust еще мозг ломает.

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

Просто пояснил. Потому что ваш комментарий можно понимать двояко.

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

Можно трактовать как 100% защита от любых утечек памяти, но не защищает от ошибок вида 2+2=5. Что тоже верно, но речь то не об этом.

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

Работает, но через жопу. А айтишка, внезапно, без интернета не работает нормально. Такие дела. Нет интернета == нет айтишки. А как ты думал то? Где все эти северокорейские самсунги? Нет их.

Зачем нужен Rust

Чтобы был язык с явно выраженной концепцией владения.

если на Си

А зачем нужен Си++, «если на Си можно»? Зачем нужен питон, «если на Си можно»?

на Си с условным valgrind

На ЛОРе в какого сишника ни ткни, о валграйнде не слышал. Большая часть сишного кода никогда не проверялась валграйндом.

можно

Можно - не значит, что так и будет.

Rust гораздо сложнее C

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

сишный код тормознее

Чем какой? Алиасинг - не настолько проблема, тем более средства борьбы с ним есть.

Можно, но почему-то не пишут

Потому что нельзя.

на Rust не пишу и не собираюсь.

Откуда у тебя такое твёрдое мнение о расте? Хорошо его изучил в деле и забросил? Или просто так, протест ради протеста?

Чем на расте.

средства борьбы с ним есть

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

На Си и безо всяких валгриндов можно писать софт без битья памяти.

Нельзя. Это принципиально неразрешимая для Homo Sapiens задача. Человек обречён совершать ошибки на определённом объёме кода. Даже отцы UNIX и авторы Си совершили множество грубых ошибок в коде UNIX.

Ну что вы, firkax никогда не совершает ошибок в своём коде.

Valgrind позволяет в этом удостовериться.

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

Ну, Rust тогда тоже не является гарантией.

Rust даёт 100% гарантию отсутствия порчи память в коде без unsafe на корректно работающем компьютере.

что менее надежно

Обоснуй.