Rust vs С++

Сейчас начнётся срач и можно уже заранее кастовать модеров?

Суть раста в том, что разработчики хотели получить язык, который бы мог использоваться в той же нише что и C++ или C(я так если честно и не понял, сначала сравнивали с Си, потом с плюсами), но при этом давал бы гарантии, того что в коде нет UB.

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

В Rust много крутых штук.

В частности

cargo doc --open

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

Ещё есть удобный rustup где можно держать несколько версий компилятора. Например, какую-то конкретную, которая есть в каком-нибудь старом Debian, stable и nightly.

Про отсутствие UB и прочую безопасность не верь. Потенциально также всё опасно, поэтому в Rust есть свои линтеры(aka clang-tidy): https://github.com/rust-lang/rust-clippy

и sanitizers: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/sanitizer.html

и прочие https://github.com/rust-lang/miri

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

Замечательный комментарий, спасибо.

Если я правильно понял

Вся крутизна синтаксиса rust в том, что mut на две буквы короче чем const.

Даже я, который ни бум-бум в Rust, понял, что это не так. Читай доки дальше. Вообще, какие доки о Rust ты прочитал, прежде чем строчить постик на ЛОР?

Edit: только сейчас заметил, что речь о «крутизне синтаксиса». Ну что же, судить о ЯП по синтаксису - это уровень рассуждений «видел в музее картинку, прошел мимо».

разработчики rust не реализовали многие другие механизмы C++

Какие? Пруф или не было.

Про отсутствие UB и прочую безопасность не верь.

Тем не менее, от очень многих ошибок, связанных с памятью раст помогает: double-free, use-after-free и прочее - хотя, ЕМНИП, в раст утечка не считается ошибкой.

C++ это про ООП, Rust это про императивное и функциональное программирование. Так что Rust надо с сишкой сравнивать.

Расскажите, пожалуйста, про Rust.

Современный низкоуровневый язык программирования.

Если я правильно понял, то разработчики взяли C++ насмотревшись на его слово const, и всё сделали наоборот. Т.е. const теперь по-умолчанию, а то что раньше было без ключевого слова, теперь стало mut.

Ты неправильно понял.

Про отсутствие UB и прочую безопасность не верь. Потенциально также всё опасно

Потенциально вообще всё опасно. На сервер с ядром seL4 может кирпич упасть, но это не значит, что с ядром проблемы.

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

От логических багов никакой раст не спасет, только фигачить на каконмить coq либо idris с доказательством корректности логики.

Говорили про «UB и прочую безопасность», а не про доказанное соответствие алгоритма спецификации.

А из того, что «всё опасно» не следует, что ничто не может быть менее опасным.

неправильно

От логических багов никакой раст не спасет, только фигачить на каконмить coq либо idris с доказательством корректности логики.

Так ведь и это не спасёт, если у тебя в логике ошибка.

ЕМНИП, в раст утечка не считается ошибкой.

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

Rust это про императивное и функциональное программирование.

В расте есть трейты, которые позволяют использовать некоторые концепции из ООП. Нету наследования, но разрабы считают, что наследование зло и ненужно.

Толсто.

https://en.wikipedia.org/wiki/Memory_leak ?

Шо, опять!?

In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations[1] in such a way that memory which is no longer needed is not released.

memory which is no longer needed

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

А ООП не бывает без трёх вещей: наследование, полиморфизм и инкапсуляция. Сам написал чего в расте нет.

Толсто.

Это скорее троллинг тупостью, посмотри, кто ОП.

Спасибо за разъяснение. Я думал что течет та память, которая не очищается, грубо говоря после malloc не написали free, но я понял, что все несколько сложнее

в раст утечка не считается ошибкой.

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

грубо говоря после malloc не написали free

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

fn foo() {
   loop {
      let a = vec![1,2,3];
      println!("a is {:?}", a);
      // a освобождается здесь
   }
}

Но вот такой уже потечет даже без ворнинга от компилятора:

fn foo() {
   let vector_of_vectors = Vec::new();
   loop {
      vector_of_vectors.push(vec![1,2,3]);
      println!("vector of vectors is {:?}", vector_of_vectors);
   }
}

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

Не в твой огород камень, а так, рассуждения на тему.

Если у памяти есть возможность утекать, она утечёт.

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

#! /usr/bin/env python3
# -*- coding: utf-8 -*-
a = []
while True:
    a.append('0')

Не надо пихать указатели. Достаточно пихать что угодно в бесконечном цикле.

Если у памяти есть возможность утекать, она утечёт.

Если у программиста есть возможность не написать free()/delete, то он это сделает.

Не могу с этим согласиться, особенно на фоне бурлящих дискуссий про текущую память и последующий UB.
Пора уже давно начать испытывать благоговейный страх при вызове malloc()/new() и не переставать после этого думать о free()/delete.
А если уж захотелось похулиганить и сотворить нечто вроде «что_то.push(new что-то другое(параметры))» и забыть потом освободить память, то аббревиатурой UB можно назвать только своё поведение, но никак ни кода :)
К слову, если надо реализовать функцию, которая выделяет память и возвращает указатель на неё как результат, то это надо документировать. Дополнительно полезно к такой функции, например create_ololo()/load_ololo(), дописывать нечто вроде free_ololo()/delete_ololo(). Главное чтобы на это всё была документация, а уж её не_чтение это UB тех личностей, которые будут пользовать этот функционал :)

Для этого в ООП придумали деструкторы, но не помогает. Просто когда пишешь new, сразу пиши и delete, а код между ними, если только не сложный менеджмент памяти. Но обычно даже такого не придерживаются и потом просто забывают delete дописать.

Достаточно пихать что угодно в бесконечном цикле.

Но это уже утечка памяти другого рода (как написано в wiki по ссылке выше).
Кстати, я всю жизнь считал утечкой памяти именно ситуацию,
когда программа работает корректно, но с течением времени объём занимаемой ею памяти растёт без причины. (хотя выделение в бесконечном цикле под это тоже подходит..)

а уж её не_чтение это UB тех личностей, которые будут пользовать этот функционал

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

Род утечки не очень помогает, когда приложение падает.

Вот вам болгарка без кожуха. Глаза выбьет - сами виноваты.

Некорректное сравнение.
Вот вам болгарка без кожуха. Без него глаза выбьет, сами виноваты будете (вызвал malloc(), вернул указатель, предупредил что его надо самому освободить).
Взял болгарку, у самого в загашнике полно защитных кожухов, кожухов для штроборезов (free()), но зачем ими пользоваться?
Жаль что с такой логикой, в режиме слабоумия и отваги, мастера режут стены 230-ыми дисками без кожухов и либо погибают, либо слепнут... (но в последнее время уже перестают геройствовать)
А программисту легко, ну упало приложение, ну и ладно, перезапустить можно (хотя не всегда без последствий (самых разных))

Упало приложение на АЭС или в навигации ракеты, ну бахнет не там где надо, подумаешь...

разрабы считают, что наследование зло и ненужно.

Просто не осилили. В D аналогичная батва была, но с множественным наследованием. Тоже говорили, что грешно и не надо так делать, а в итоге костылей накидали

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

Вот это «предупредил» и есть «не держите глаза на линии разлёта осколков».

Защитный кожух - компилятор сам вызывает free по выходу из scope.

Вот именно!

Нужен плакат в советском стиле «Выделил память? Не забудь освободить!», «На каждый *alloc() должен быть свой free()!».
Но пока все ждут язык-мессию...

это от языка не зависит, это к программисту вопрос.

Собственно пример приводился как раз для того, чтоб проиллюстрировать этот тезис)

Защитный кожух - компилятор сам вызывает free по выходу из scope.

Нет, это уже совсем не подходит.
Компилятор сам вызывает free() - во-первых он может вызвать не там где надо (либо отслеживание использования указателя займёт слишком много времени и ресурсов, и будет дешевле самому помнить о необходимости освобождения); во-вторых это «отнёс деталь и тебе её разрезали».

С Rust'ом не знаком, но как я понял, в ногу там стрелять целенаправленно тоже можно, и закапывать С/С++ пока рано.

Компилятор сам вызывает free() - во-первых он может вызвать не там где надо

Ну вот вся семантика rust’а (ownership, lifetimes, raii) построена на том, чтоб free() вызывался там где надо. На лоре недавно тред был с математическим доказательством корректности этих механизмов.

В С++ и Расте с RAII как-то живут. Если нужно что-то подвыподвертнутое, то снимают кожух - берут указатели.

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

в ногу там стрелять целенаправленно тоже можно

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

и закапывать С/С++ пока рано

Их еще очень нескоро закопают по многим причинам, но область применения rust’а растет, к счастью.

Там выстрелить в ногу можно только специально прицелившись

Не то чтобы особо целиться надо было. Но предохранитель с ногострела надо снять (unsafe), и после этого попадаем в ногу с большей вероятностью чем в C - в unsafe коде нужно гарантировать больше условий.

Можно, но сложно. Надо изворачиваться. А в C дробовик уже направлен куда нужно

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

Здесь поробегала ссылка о том что безопасность безопаного Раст была доказана математически.

можно написать формальную спецификацию

а кто проверит формальную спецификацию на наличие ошибок?