LINUX.ORG.RU

А действительно ли Rust так... плох?

 , ,


0

6

Друзья, есть такой вопрос.

Я тут выбираю какой новый ЯП выучить. Заинтересовался Rust-ом. Сейчас о нём много говорят и даже сам Линус (да святится имя его) осторожно допускает, что он может заменить С++. Много пишут о его преимуществах, о новой системе сборки мусора, о скорости работы и красиво организованной низкоуровневости. Читая это, я загорелся идеей его выучить. И всё бы хорошо, но вот наткнулся на эту статью некоего Алексея Вересова. В ней автор разносит Раст в пух и прах… И вера моя пошатнулась (или как там это говорится).

Да, я понимаю, естественно, что есть сторонники и ненавистники у всего нового, и у Раста в частности. И это правильно и нормально и так устроен мир и всё такое. Но! Информатика – это ведь не философия. Это наука вполне конкретная. Если есть сигнал, значит это единичка, и никак не нолик. И двух мнений тут быть не может. Это я к чему – к тому, что факты, которые товарищ Вересов упоминает в своём опусе – это именно что вполне конкретные факты, с которыми надо что-то делать. Последователям Раст надо как-то на них ответить. Например, если скомпилированный код получается слишком большой, то это либо факт, либо вымысел, двух мнений не может быть.

Конечно, возможно, автор чего-то не понимает, или вообще врёт. Он опасно молод (в 22 году окончил МГУ), так что кто его знает. По сему, хотел бы разобраться с теми отдельными негативными моментами, которые он высказывает в сторону Раста. А именно:

1. Макросы усложнили жизнь и принесли избыточность?
2. Типы указываются автоматически, но явное указание допустимо в тех случаях, когда автоопределение не срабатывает. Т. е. оно может не сработать? Но при этом по умолчанию тип не надо указывать… Если автоматика не идеальна, зачем делать её умолчальной?
3. Зачем сделана многопроходная компиляция, просто в угоду возможности объявить функцию после её вызова? И ради этого увеличивать время компиляции до нескольких часов? Не проще ли пролистать код в начало и вписать объявление туда?
4. Мы передаём в функцию значение, а потом не можем использовать его в основной программе? Серьёзно что ли? Ну это очень веская должна была быть причина, чтобы так сделать. Так это правда?
5. Про сборщик мусора – он всё-таки есть, и даже не один?
6. Раст – это параллелизм, прежде всего?
7. Получаемый после компиляции машинный код действительно больше, чем аналоггичный на плюсах? Ну т. е. это всегда так, или он просто пример такой подобрал? На 3 строки Раста 2779 строк Ассемблера! Если так, почему тогда Раст считается очень быстрым, что аж это его фишка?
8. Ну, про то, что сторонники Раста самые счастливые люди он ничего не объяснил. Каждый кулик своё болото хвалит. А вот как куликов сравнить объективно по уровню счастья – это уже сложнее.

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

P.S. Полезный, кстати, сайтик для себя открыл: Стрела Бога. Позволяет смотреть ассемблерное представление кода.

Судя по статье, некий Алексей Вересов - бездарный идиот. Изучи себе сначала C и C++, а потом Rust. Тогда возможно станет ясно, для чего нужен Rust и какие застарелые проблемы копролита из 70-х он решает.

  1. Декларативные макросы мощнее и безопаснее, чем примитивные сишные дефайны с убогим текстовым копипастом. В частности, они решают проблемы вроде необходимости обмазывания скобками имен параметров или скрытия имен переменных. Почитай, что такое гигиенические макросы. Приводить в качестве недостатка раста хелловорлд с println! это вообще смешно. Сложность базового хелловорлда имеет значение разве что при первоначальном обучении программированию. И здесь ни Rust, ни C, ни C++ не пригодны в качестве самого первого языка при обучении. Дырявый сишный printf вообще априори небезопасен и никак не проверяет соответствие форматной строки и параметров. Ну да, println! в расте реализуется через встроенные средства компилятора, но и в сишке проверки параметров printf намертво зашиваются в компилятор. Например через уродский костыль __attribute__ ((format (printf, 2, 3))) в GCC.

  2. В подавляющем большинстве случаев автовыведение типов работает корректно, потому оно и сделано умолчальным. Если скажем, автовыведение срабатывает в 95% случаев, нахрена его отключать ради 5% неоднозначностей? Чтобы что? В большинстве современных языков есть автовыведение типов, как минимум для локальных переменных. Это тупо удобно. Даже в C23 и то завезли новый старый auto.

  3. Писать функции в любом порядке проще и удобнее. Например сначала функция main, затем вспомогательные функции, вызываемые из main, затем вспомогательные функции, вызываемые из предыдущих и т.д. Зачем писать горы бессмысленного мусора с предварительными объявлениями функций? Где пруфы, что именно возможность писать функции в любом порядке замедляет компиляцию раста? Компиляторы C/C++ тоже получились тормозные и многопроходные, но при этом все равно требуют писать forward декларации. И чо, стоила ли игра свеч в итоге?

  4. Что тебя удивляет в семантике перемещения? Крестовики тоже обмазываются всякими std::unique_ptr для достижения подобного эффекта. Только в расте этот синтаксический мусор не нужен и компилятор отслеживает use-after-move/free, а в крестах даже полоумные указатели ничего не гарантируют и оставляют широкие возможности для простреливания ног.

  5. Про сборщик мусора там очевидное вранье и манипуляция. В Rust нет недерминированного сборщика мусора типа Java, C# и прочих языков с GC. Речь идет только о детерминированном RAII и подсчете ссылок. С тем же успехом можно заявить, что C++ - это тоже язык со сборщиком мусора, ведь там есть std::shared_ptr.

  6. Раст - он так же про параллелизм, как и C/C+.

  7. В старом треде писали, что автор ниасилил включить оптимизацию растокода, вот и получился громоздкий ассемблерный код. Касаемо скорости - где пруфы, что оптимизированный растокод медленнее оптимизированного сишного? Где бенчмарки и вообще хоть какие-нибудь цифры? Размер ассемблерного выхлопа никак не связан с производительностью полученного кода. Более того, бывает так, что более громоздкий код работает быстрее. Например при инлайнинге.

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

archie
()
Последнее исправление: archie (всего исправлений: 2)
Ответ на: комментарий от alysnix

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

Изначально всего лишь собирались переписать движок мозилы на собственный безопасный и более простой (чем C++) язык. Затея конечно дурацкая, но в принципе реалистичная. Откуда взялись наполеоновские замашки у фанатов (как и сами фанаты) совершенно непонятно. Хотя бы серво доделали уже перед захватом мира.

bread
()

Я тут выбираю какой новый ЯП выучить. Заинтересовался Rust-ом.

Не читай всякий шлак.

Возьми и изучи. Сам поймёшь что к чему.

  1. Макросы усложнили жизнь и принесли избыточность?

Кому? Большая часть кода пишется через derive и это удобно.

  1. Типы указываются автоматически, но явное указание допустимо в тех случаях, когда автоопределение не срабатывает. Т. е. оно может не сработать? Но при этом по умолчанию тип не надо указывать… Если автоматика не идеальна, зачем делать её умолчальной?
let s = "123";
let x: u8 = s.parse().unwrap();
let y: u32 = s.parse().unwrap();

Как тут определить каким должен был быть x или y?

  1. Зачем сделана многопроходная компиляция, просто в угоду возможности объявить функцию после её вызова? И ради этого увеличивать время компиляции до нескольких часов? Не проще ли пролистать код в начало и вписать объявление туда?

А сколько раз проходит Си через #include, #if и прочие?

И нафиг нужны объявления + реализации.

https://blog.rust-lang.org/2016/09/08/incremental.html

  1. Мы передаём в функцию значение, а потом не можем использовать его в основной программе? Серьёзно что ли? Ну это очень веская должна была быть причина, чтобы так сделать. Так это правда?

Причина есть: время жизни значения. foo(val), bar(&val), baz(&mut val)

Ну и правильней было бы:

fn sumtop(v: &[i32]) -> i32 {
  1. Про сборщик мусора – он всё-таки есть, и даже не один?

Нет. Или умные указатели С++ тоже сборщик мусора?

  1. Раст – это параллелизм, прежде всего?

Нет. Но помогает решить определённую часть проблем.

  1. Получаемый после компиляции машинный код действительно больше, чем аналоггичный на плюсах? Ну т. е. это всегда так, или он просто пример такой подобрал? На 3 строки Раста 2779 строк Ассемблера! Если так, почему тогда Раст считается очень быстрым, что аж это его фишка?

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

pub fn magic(values :&mut [i32]) {
    for x in values.iter_mut() {
        *x += 1;
    }
}

Для opt-level=z

example::magic::he8ec2dd9e19ea10d:
        shl     rsi, 2
        xor     eax, eax
.LBB0_1:
        cmp     rsi, rax
        je      .LBB0_2
        inc     dword ptr [rdi + rax]
        add     rax, 4
        jmp     .LBB0_1
.LBB0_2:
        ret

Для opt-level=3 будет 36 строк, но с xmm*

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

Не брошен, а переписан 1 к 1 какой-то из опенсорсных сишных. Не сегфолтится - как и было заявлено. Об этом и говорилось, с чего ты решил что я функционал его нахваливал?

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

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

rk-d
()
Ответ на: комментарий от fluorite

Оказывается, краш компилятора - это фича.

Нет, конечно, но компилятор, тем не менее, не пропустил некорректный код. Он мог это сделать красивее, но тяжело отрицать, что он его не пропустил.

rk-d
()
Последнее исправление: rk-d (всего исправлений: 1)
Ответ на: комментарий от fluorite

У T вроде как должен быть ’статик, но я не уверен. Но это и не совсем важно - может вы всё таки приведете пример действительно некорректной компиляции, а не (возможно) ложного срабатывания?

rk-d
()

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

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

Что касается критики раста, то её в сети огромное количество, особенно русскоязычной. В основном со стороны программистов на C++ (эти понятно, боятся и защищают свои рабочие места) и своеобразных луддитов, которым любой прогресс как серпом по яйцам. Но из всех этих мегатонн текста я ничего никогда ещё полезного не находил, рекомендую читать англоязычные источники (не написанные русскими!), там куда меньше эмоций и чепухи.

neumond
()

Много пишут о его преимуществах, о новой системе сборки мусора, о скорости работы и красиво организованной низкоуровневости.

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

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

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

компилятора

Которого из трёх?

dataman ★★★★★
()

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

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

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

А зачем кому-то нужно в таблицу из 255 ячеек пихать 10 возведённую в 3 = 10^3 = 1000 и ожидать, что ответ будет 232, вместо того что написано?

Clockwork ★★★★★
()
Последнее исправление: Clockwork (всего исправлений: 1)

даже сам Линус (да святится имя его) осторожно допускает, что он может заменить С++

В его речах с ругательствами в адрес C++ и тех, кто на нём пишет?

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

Что касается критики раста, то её в сети огромное количество, особенно русскоязычной. В основном со стороны программистов на C++ (эти понятно, боятся и защищают свои рабочие места)

Вот кстати да. Подозреваю, что большинство истерик и воплей исходят от сишников/крестовиков, которые боятся, что раст сделает их ненужными. Раньше тоже появлялись всякие «убийцы С++» вроде джавы и D. Но все попытки с треском проваливались из-за проблем с производительностью и обязательного GC. А Rust имеет неплохие шансы подвинуть C/C++ прямо в его насиженной нише.

archie
()
Ответ на: комментарий от Clockwork

вместо того что написано?

Чего написано-то? И что делать, если степень не 3, а допустим 130? u8 - это арифметика по модулю 256. Если это не устраивает, то нужно или другие типы использовать, или другие функции, которые дают выбор. Например, для базовых операций типа сложения существуют варианты с проверкой переполнения или насыщением.

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

И даже не думайте доказывать фанам FORTH, что это - совершенно непонятный язык и не приспособлен для какой- либо серьёзной работы: в лучшем случае вас просто прогонят.

И будут правы. Потому что непонятность - в головах.

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

А Том Свон точно программист? Потому что если продолжить его аналогию, то от «языка на котором записан рецепт суфле» зависят его стоимость, время приготовления, и длительность поноса и/или несварения у его употребивших.

Gentooshnik ★★★★★
()

Плох вовсе не раст, отвратительны растаманы, те кто за ним стоит и их поведение тождественное ЛГБТ и прочим SJW. Натуральная блевотина программизма. Ещё хуже жабомакак.

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

D. Но все попытки с треском проваливались из-за проблем с производительностью и обязательного GC.

Много лет пишу на D - с каждым годом он всё лучше и быстрее. А GC это благо, даже Дишный

Вообще, выбирающим между C++ и Rust горячо рекомендую попробовать D

ahdenchik
()
Ответ на: комментарий от unC0Rr

Чего написано-то?

То что написано в коде: u8 в данном случае, значит оно кому-то для чего-то нужно. Имею в виду вместо 1000

И что делать, если степень не 3, а допустим 130?

Менять написанный код, чтобы получить ожидаемый результат от желаемого кода, а не наоборот. Но ты это не у меня спрашивай, потому что не я 10 возвёл в 3 и получил 232.

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

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

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

mydibyje ★★★★
()

Я тут выбираю какой новый ЯП выучить. Заинтересовался Rust-ом.

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

zent
()
Ответ на: комментарий от Shushundr

У каждого топ-издательства (Packt, Apress, Nostarch, Manning, CRC, BPB, Oreilly, Wiley, …) есть книжка про раст, чаще не одна, так что статистически они не могу быть плохими все, тема обсосана вдоль и поперек, учись-нехочу.

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

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

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

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

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

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

Написано понятнее некуда

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

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

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

Интересно. Всегда думал, что в раст заходить легко только после уже имеющегося опыта в C/C++. У меня знакомый питонист книжку так и не осилил - оказалось слишком сложно и низкоуровнево.

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

от сишников/крестовиков, которые боятся, что раст сделает их ненужными

В смысле ненужными? Если С++ отомрет, то буду писать на Rust,D или что к тому времени станет новым языком на замену. Язык программирования - это инструмент, а не религия.

pathfinder ★★★★
()

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

Простой пример. Я сейчас начал изучать Bash. Нахожусь в самом начале пути, но в комментариях к моим темам — тьма разбирающихся в Bash’e, постоянно третируют меня, хейтят и делают, со своей стороны, всё, чтобы я не изучал Bash. Это называется «охраной территории» у животных. Да, я вторгся в их «территорию». Новый потенциальный конкурент. А теперь представьте, как их заставить учить Rust, в котором они, как я, будут плавать на дне? Это не их территория. Они и свою-то территорию окучили еле-еле, а тут ещё предлагают новое поле возделывать. Нет уж!! Учите сами! Вот такая будет реакция. Зато на своём поле они над вами поглумятся - будьте уверены.

Вот так это работает. Если сильно обобщённо.

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

0. intercall и прочий малбордж да тот же bf - хорошие(уж точно не плохие)

1. трудность не в «переучивании» а в фундаментальном отличии сложности самой задачи и превнесённой сложности текущих методов решения в том числе и задачи с её иманентной сложностью

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

https://www.computerwoche.de/article/2720775/the-a-z-of-programming-languages...

дело в адектватнности инструментов задачам и технологиями преодоления мисматча

qulinxao3 ★☆
()

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

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

Ну а хейтер пишет во многом чушь. Сдобрив её правдой, чтоб легче было проглотить эти притягивания.

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

А если ты аналогичные памфлеты на все остальные ЯП почитаешь, то сомнения относительно того, программировать ли вообще, появяится. А если ещё почитать критику архитектуры компьютеров нынешних… В общем, можно сразу в монастырь.

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

делают, со своей стороны, всё, чтобы я не изучал Bash

Правильно делают. Шелл фантастически убог, не разбазаривай на него своё время. Уж лучше всратый perl, чем шелл.

PS Не прими только это за призыв учить перл, пожалуйста :D

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)