Линус Торвальдс запланировал внедрение Rust в Linux 6.1

Отлично.

не про стиль а область применения

В этом смысле Раст тоже не преемник, т.к. он никогда не станет «народным» языком, каким стал Си. Но в каких-то областях действительно может заменить Си. В т.ч. в ядре.

И кто тогда у Rust этот бакенд ?

LLVM.

LLVM много у кого бекенд: у D, C, C++, Swift, Rust, C#(один из возможных бекендов), Haskell, Zig и т.д.

правда ли, что Рабинович выиграл миллион в лотерею? - правда. только не Рабинович, а Иванов, не миллион, а сто рублей, не в лотерею, а в карты. и не выиграл, а проиграл! (с)

А в чем реальный профит на пальцах? Что значит «бОльшая безопасность памяти»? Нельзя просто соорудить пару надстроек над С чтоб к массиву прибивался его размер (и указатель не мог выйти за его пределы) и указатель «выгрузить» чтоб компилятор проверял переменную на наличие освобождения динамической памяти в коде?

В Си тоже есть unsafe. Это дело программера юзать ЭТО или нет.

А вот интересно, сколько человек, из отметившихся здесь, что-то на Расте компилировали? Пять-шесть?

Вот сейчас собрал свеженький gitui. Да, хорошая утилита, удобная. Но 500K исходников за 5m 06s и 666Mb (смешно получилось)?! И это только в директории исходников.

Зато безопасно, да.

Два стакана смузи всем разработчикам.
Почитать, что ли, доков по расту...

в чем реальный профит на пальцах

Профит в том, что всё это чекается во время компиляции, а не динамически.

Такими темпами можно сказать, что у C++ бэкенд тоже на C написан. И что?

Профит в том, что всё это чекается во время компиляции, а не динамически.

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

Собсно по аналогии с гет/сет бинов - задекларировал массив myArray, если так-же задекларирована переменная с заведомо определенным форматом имени, например myArrayCheckSize=10 то компилятору нет проблемы убедится что все указатели будут внутри массива.
Не хотца типовых имён? Ввести указатель на функциональные переменные - например @myArraySize=10 - тогда вообще ноль проблем со старыми прожектами и ляпота в новых

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

что такое в твоём понимании «самостоятельный язык» и как «ллвм и прочих» этому противоречат?

в моем понимании самостоятельность языка определяется наличием своего компилятора-линковщика. я неверно определил этот термин для себя?

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

Кто-нибудь может объяснить, в чём проблема Раста, что для модулей на нём нужна специальная поддержка? Они компилируются не в машинный код? Они тянут большой рантайм? Они требуют особых аппаратных привилегий?

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

Такими темпами можно сказать, что у C++ бэкенд тоже на C написан. И что?

Какой-то может быть и написан.

Ничего, я просто хотел уточнить структуру компиляторов.

ergo

Сейчас примерно такое понимание как я написал, вот ещё коммент про разделение на фронтенд/бекенд: https://www.reddit.com/r/cpp/comments/hjn4uv/comment/fwsi2xh/?utm_source=share&utm_medium=web2x&context=0

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

Вот сейчас собрал свеженький gitui

Три месяца назад поставил наиновейший Debian Linux 11.

Результат компиляции:

error: failed to parse manifest at `/home/xi/work/develop/rust/gitui/Cargo.toml`

Caused by:
  failed to parse the `edition` key

Caused by:
  this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions.

Дебиан как обычно

Максимально зажатый и зарегулированный язык, он противоестественен духу свободного программного обеспечения и философии Linux. Если он и привлечёт в ядро «новые лица», то совсем с другим мировоззрением. Боюсь, что это будет большая ошибка Линуса…

Сейчас примерно такое понимание как я написал

«Сейчас»?

Открываю «Построение компиляторов» Вирта, 1985, и вижу там эти понятия. Они уж сто лет не менялись.

Последний гроб в шляпку гвоздя C++

Не, у меня rustup и nightly, поэтому неудивительно.

За «духом СПО» нужно идти в HURD (правда, он почему-то до сих пор не работает, но это просто случайность, главное что его хакеры пишут!), а философия Linux это чисто инженерный подход.

«чисто инженерный подход» - это UNIX. А Linux - это в первую очередь свобода и открытость.

Ты это Торвальдсу расскажи, а то он не в курсе.

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

Тебе кто-то запрещает писать на Rust-е то что ты хочешь?

Главное достоинство Rust-а в том, что он не даст тебе возможности сделать ошибку при доступе к памяти переменной, потому что концепция владения вшита в сам язык. Но даже это не гарантирует отсутствие утечек памяти. Rust гарантирует что ты работаешь с реально существующим объектом, но не гарантирует, что пока ты добрался до данного объекта, память не засралась не удаленными артефактами работы программы. Какая тут нафиг зарегулированность.

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

Но даже это не гарантирует отсутствие утечек памяти

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

Чтобы не было ошибок доступа к памяти может нужно просто писать код внимательнее

А чтобы не было войн, надо просто не конфликтовать 🤗

Чтобы не было ошибок доступа к памяти может нужно просто писать код внимательнее

Вот так программирование и превращается в упражнение на внимательность.

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

Если без маркетинга (зачастую вредного) про безопасность, то поинт очень простой: контроль над алиасингом.

Вот пост Линуса про алиасинг: https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing/

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

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

Господа, я сплю? Ущипните меня.

Добро пожаловать в реальность

коменнтарий про «всю суть линукса» уже был?

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

Байндинги чего к чему? Раста к API ядра? Или Си к чему-то на Расте? Если первое, почему этим занимаются в LKML а не на сайте Раста?

ведро стало настолько большим что в него со свистом помещается Rust :-)

общая проблема не в «большей безопасности алисов над ссылками», а в том что ядро стало слишком велико и сложно управляемо. Ждём Minix-X :-) Или что-нить подобное

Отлично. Стоим на пороге нового шага к развитию Linux.

Согласен. Так-то Linux стоит на краю пропасти, а теперь сделает огромный шаг вперед.

Сам язык же при этом не меняется

Без специальной поддержки со стороны языка придётся городить статический анализатор. Такие инструменты есть, но они не дают 100% гарантии.

Это только фронтенд.

Вот внедрим в LLVM код на расте, будешь знать!

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

Внимательность тут ни при чём. Часто проблемы бывают неочевидные.

Такими темпами можно сказать, что у C++ бэкенд тоже на C написан. И что?

Для gcc вернее сказать наоборот: C написан на C++.

или rustc_codegen_gcc

Такими темпами можно сказать, что у C++ бэкенд тоже на C написан. И что?

Так наоборот же. Это у C сегодня все актуальные компиляторы написаны на C++. Что GCC, что Clang/LLVM, что MSVC.

В данном случае актуальнее чтобы существовало больше одной реализации языка.

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

Эти планы точно там же, где планы по доведению vim/emacs/vscode до самостоятельных IDE без всяких language server’ов, плагинов и прочих

Кстати, напомните, ядро наконец-то начало собираться Clang’ом нормально по дефолту?

Или луддиты всё так же теребонькают несовместимые со стандартом GCC Extensions?

Часто проблемы бывают неочевидные

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

Я прост не догоняю как один компилируемый язык может генерить код «безопаснее» чем другой

Прочитайте TAPL и перестаньте задавать глупые вопросы. Различные системы типов способны давать гарантии совершенно различного уровня.

В этом смысле Раст тоже не преемник, т.к. он никогда не станет «народным» языком, каким стал Си.

А что такое «народный язык»?

Наверно, никакой, если придумать что в целом делать с interoperability. Кроме ввода/вывода, нужно ещё много всякого другого api ядра использовать.