LINUX.ORG.RU
ФорумTalks

Rust vs С++

 


1

7

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

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

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

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

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

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

snake266 ★★
()

В 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

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

fsb4000 ★★★★★
()

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

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

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

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

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

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

seiken ★★★★★
()
Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от fsb4000

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

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

snake266 ★★
()

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

peregrine ★★★★★
()

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от fsb4000

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

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

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

red75prim ★★★
()
Ответ на: комментарий от red75prim

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

Int64 ★★★
()
Ответ на: комментарий от Int64

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

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

red75prim ★★★
()
Последнее исправление: red75prim (всего исправлений: 1)
Ответ на: комментарий от Int64

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от snake266

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

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

provaton ★★★★★
()
Ответ на: комментарий от peregrine

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

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

provaton ★★★★★
()
Ответ на: комментарий от snake266

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

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

provaton ★★★★★
()
Ответ на: комментарий от provaton

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

peregrine ★★★★★
()
Ответ на: комментарий от kirk_johnson

Толсто.

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

theNamelessOne ★★★★★
()
Ответ на: комментарий от provaton

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

snake266 ★★
()
Ответ на: комментарий от snake266

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

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

atrus ★★★★★
()
Ответ на: комментарий от snake266

грубо говоря после 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);
   }
}
provaton ★★★★★
()
Последнее исправление: provaton (всего исправлений: 2)
Ответ на: комментарий от provaton

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

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

goodwin ★★
()
Ответ на: комментарий от provaton

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

#! /usr/bin/env python3
# -*- coding: utf-8 -*-
a = []
while True:
    a.append('0')
так что это не к языку вопрос, более того, я такое видел...

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от Einstok_Fair

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

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

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

goodwin ★★
()
Ответ на: комментарий от goodwin

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

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

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

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

goodwin ★★
()
Ответ на: комментарий от goodwin

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

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

red75prim ★★★
()
Последнее исправление: red75prim (всего исправлений: 1)
Ответ на: комментарий от goodwin

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

peregrine ★★★★★
()
Ответ на: комментарий от red75prim

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

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

goodwin ★★
()
Ответ на: комментарий от provaton

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

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

SR_team ★★★★★
()
Ответ на: комментарий от goodwin

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

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

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

red75prim ★★★
()
Ответ на: комментарий от peregrine

Вот именно!

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

goodwin ★★
()
Ответ на: комментарий от peregrine

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

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

provaton ★★★★★
()
Ответ на: комментарий от red75prim

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

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

goodwin ★★
()

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

goodwin ★★
()
Ответ на: комментарий от goodwin

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

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

provaton ★★★★★
()
Ответ на: комментарий от goodwin

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

red75prim ★★★
()
Ответ на: комментарий от CryNet

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от goodwin

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

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

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

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

provaton ★★★★★
()
Ответ на: комментарий от provaton

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

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

red75prim ★★★
()
Ответ на: комментарий от goodwin

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

peregrine ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

Int64 ★★★
()

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

grim ★★☆☆
()
Последнее исправление: grim (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.