В чем смысл Rust?

Либо какой-нибудь еще вендор-лок внутри компилятора.

Вот именно. Компилятор Rust’а уже года 3 без Интернета и подключения к какой-то их растоманской фигне не собирается никак, с этим ничего поделать нельзя.

потому что вдруг враги в стиральную машину бомбу положат

Удаленно подложить бомбу в стиральную машину нельзя, а в Rust — можно.

Ни размера, ни метаданных, ни операций над элементами.

И правильно, либо терминируй массив чем-то, либо записывай куда-то еще и его размер.

Тогда и в С тоже можно.

sizeof подтвердит

Вы вообще на Си писали хоть когда-то?

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

1. Rust собирали llvm (rustc), а C — gcc (gcc).
2. Одинаковый по логике код на Rust и любом другом нормальном языке (C, например) написать нельзя по определению.

Это как-то оправдывает тормоза С или что?

Да, ибо сравнение некорректно. Там, кстати, плюсы выше Rust’а.

В C нельзя, gcc и llvm+clang собираются без Интернета спокойно, в отличие от rustc.

Какие жалкие оправдания.

gcc и llvm+clang собираются без Интернета спокойн

Исходники вы откуда брать будете?

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

И правильно, либо терминируй массив чем-то, либо записывай куда-то еще и его размер.

Это заявление уровня: сидение на велосипеде не нужно, достаточно хорошенько смазать подседельный штырь и можно ехать.

Нет препятствий патриотам (с)

С флешки,

А на флешку откуда?

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

Ну так то брехня. Из относительно новых языков и стандартов, ориентация уже давным давно идёт на всеми ненавистный паскаль, или ещё более артхаусные штуки по типу Оберона. Вон в последних стандартах плюсов, куча фич которые были в делфи и обжектпаскале ещё 20 лет назад. Голанг это буквально реализация языка оберон. Зиг, раст это вариации на тему вирта, там всего понемножку намешано, и паскаль, и оберон, и модулы. Именно на С никто не ориентируется.

Это особенности базовичков системщиков. Они думаю что они цари горы, ведь они пишут БАЗОВЫЕ ТЕХНОЛОГИИ ууу. На самом деле они занимаются тем что примитивы туда сюда таскают, и среднестатистический формошлёп, крудошлёп делает работу которая является сложнее. Сделать валидацию на форме из 50 полей, это задача комплексно сложнее, нежели гонять на сишке байтики туда сюда.

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

Все базовые технологии уже написаны, системщики не нужны

Скажи это моему начальству

Зачем нужен Rust, если на Си с условным valgrind можно писать код без утечек

Нельзя. Любой malloc - это риск утечки. В коде, где в одном месте malloc, в другом - free ещё можно писать без ошибок. Если код с malloc и с кучей выходов - это генератор ошибок по умолчанию. Можно юзать умные указатели на основе __attribute__((cleanup(__free_func))) в GCC, но А: этой фичи нет в условном MSVC, Б: её сложно юзать без дженериков. А так да, си мне нравится - не так перегружен как C++, но каких то фич не хватает.

А ещё, нафиг тормозной valgrind, когда есть ASan.

У MSVS есть __try/__finally. Правда видел их в С++ коде, но наверное в Си тоже сработают. Ни разу не пользовался.

Основной метод поддержания безопасности – это строгая иерархия выделения памяти и очистки. Есть данные уровня функции. В той функции, где они были созданы, там и должны удаляться. Есть уровнь модуля – тогда работа ведется с функциями модуля. Наподобие классов в С++.

Самодисциплина лучший друг в программировании.

У MSVS есть __try/__finally. Правда видел их в С++ коде, но наверное в Си тоже сработают. Ни разу не пользовался.

Это не совсем то. Чтобы делать «умные» указатели нужен параметр именно как в GCC, который чистит указатели при выходе из функции (деструктор).

Основной метод поддержания безопасности – это строгая иерархия выделения памяти и очистки.

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

Тогда и в С тоже можно.

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

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

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

И которую можно в любой момент выкинуть без вреда для проекта.

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

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

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

Когда добавляешь в проект на С зависимость, то как её интегрировать - зависит от тебя.

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

для некоторых других людей это минус

s/некоторых других людей/всей современной индустрии/ . Пакетный менеджер/централизованный репозиторий/система управления зависимостями есть у всех современных (т.е. разработанных за последние 30 лет) языков. У С этого нет, потому что там вообще нифига нет. Для семидесятых годов прошлого века это было слишком продвинутым решением.

Аналогично со сборками линукса. Как придумали собирать программы в пакеты, которые явным образом зависят друг от друга — так с тех пор каждая сборка общего назначения использует эту технологию. С в программировании это что-то вроде Slackware среди линуксов.

система управления зависимостями, которую можно заместить операциями, выполняемыми человеком.

Слишком сложно для цирка. Достаточно иметь возможность подменять стандартный централизованный репозиторий собственным.

Это же не сложно гарантировать. Не использовать malloc вообще. Или использовать только на этапе инициализации.

Простите, это где строки хорошие?

Safe-подмножесьва есть ведь. MISRA там вмякая….

Вылезть за пределы массива отсутствие malloc не помешает. Но для программ в пару сотен строк действительно несложно проверить все гарантии вручную.

Cargo умеет работать с локальными зависимостями (указываешь path до папки) и с кастомными репозиториями пакетов (аналогами crates.io, в компаниях обычно есть свои репозитории на своих серверах).

Я как-то хотел написать простой парсер html. Чтобы не копировать пямять, можно текстовое содержимое тэгов хранить прямо в исходном html. Для этого нужен тип данных: указатель и длину строки. (вставоять \0 в html - не вариант). И вот когда я начал изучать Rust то оказалось что этот тип данных там есть «из коробки». Там есть String, который «хранит» строку и есть str - который как раз указывает на часть строки внутри String. Это настолько удобно, что я почти сразу перестал скучать по Си/Си++.

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

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

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

В цпп нынче тоже есть std::string_view.

Это жульничество. Заявлялась проблема: «Зачем нужен Rust, если на Си». Получается, когда мы сравниваем простоту, мы сравниваем с С. А когда обсуждаем полноту возможности — с С++.

Я отвечал на «Это настолько удобно, что я почти сразу перестал скучать по Си/Си++.»

И вот когда я начал изучать Rust то оказалось что этот тип данных там есть «из коробки». Там есть String, который «хранит» строку и есть str - который как раз указывает на часть строки внутри String

str, который УКАЗЫВАЕТ на подстроку в сторке String - указатель. В Си без плюсов есть функция, которая именно что возвращает указатель на нужную подстроку в стоке. То есть, по твоему комментарию, ты описал то, что давным давно есть в Си.

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

StringRef-ы сейчас много где есть. В том числе в QtCore для C++.

Не, Qt вообще был не вариант. Я делал игровой движок на Вулкане и мне хотелось реализовать минимальный Гуй с поддежркой CSS Grid и Flexbox. Никаких тяжёлых библиотек типа Qt использовать не хотел. Но проект заглох и в итоге я пересел на движок Bevy…

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

Утопия.

Но ведь можно писать на плюсах c-style использую минимальный минимум для RAII?

… сказали мужики и отправились валить лес двуручными пилами.

Но ведь можно писать на плюсах c-style использую минимальный минимум для RAII?

Всё равно у C++ будет недостаток по фичам. На любой чих нужна внешняя библиотека. Прочитать json - библиотека. Сокеты - библиотека или иди писать на си (для каждой платформы). Для каких-то вещей библиотеки чисто сишные без биндингов - делай биндинги, либо смешивай си и плюсы в одном коде - это та ещё хрень. Хочется чтобы всё было гармонично и красиво как в Qt, либо просто на си писать - но тут у тебя не будет ни дженериков, ни умных указателей. Нормальными классами можно пренебречь.

Golang не предлагать, это такой выкидыш сатаны, меня от одного вида кода на Golang почему-то тошнит. Почему-то весь код на Go - выглядит как не читаемый говнокод по умолчанию.

Если код с malloc и с кучей выходов - это генератор ошибок по умолчанию.

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

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

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

Так и делают, от Вконтакте до Мета.

Речь не про JIT-компиляцию, а про AOT-компиляцию а-ля (https://bellard.org/quickjs/quickjs.html#qjsc-compiler):

$ echo 'console.log("HELLO");' > foo.js
$ qjsc -o foo foo.js 
$ ./foo
HELLO
$ ldd ./foo
	linux-vdso.so.1 (0x00007f55ea1a3000)
	libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f55e9f6f000)
	libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f55e9c00000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f55ea1a5000)
$

Это бинарник. Он не генерирует код в рантайме (не вызывает mmap с PROT_EXEC). Если укажешь -fno-eval, там вообще интерпретатора не будет.

https://github.com/VKCOM/kphp

https://en.wikipedia.org/wiki/HipHop_for_PHP