LINUX.ORG.RU

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

 , ,


0

6

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

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

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

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

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

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

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

Ответ на: комментарий от Manhunt

Perl в планах, но не знаю, когда до него дойду, потому что у меня после bash идёт либо Python, либо Tcl, либо что-то ещё - хочу что-то универсальное, кроссплатформенное, чтобы не только на линуксе работало.

Главное вовремя остановится на какой-то степени красноглазия. Мне кажется, любой уважающий себя линуксоид должен знать шелл хотя бы в средней или ниже среднего степени красноглазия. Да и потом, Bash реально крут, если закрыть глаза на некоторые нелогичные и неочевидные вещи. Приноровиться можно.

Насчёт разбазаривания времени ты точно подметил. Отнимает это всё кучу времени - причём непропорционально. Один день можешь сидеть корпеть над какой-то простой задачей и изучить мало нового. А другой день - узнаёшь много нового, продуктивно получается. И всё это неравномерно распределеяется, нет линейного прогресса … то быстро доходит, то медленно, то вообще останавливаешься и не знаешь, что делать.

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

Да, про Lua что-то забыл. Синтаксис у Lua просто песня … но я мельком только глянул и конфиг для devilspie2 тут приходилось немного редактить - выглядит так просто, прямолинейно, и, я так понял, он очень быстрый - по крайней мере, у меня сложилось такое впечатление. В devilspie2 удивляет, как он быстро отрабатывает код, быстро выставляет окна, где нужно. Я думал, будет какой-то небольшой лаг перед отработкой кода, но нет, всё происходит тут же, мгновенно, как будто окна так всегда и появлялись.

Desmond_Hume ★★★★★
()

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

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

либо Tcl

хочу что-то универсальное, кроссплатформенное

Что-то более универсального и кроссплатформенного найти сложно, запускается и работает даже на xp и древних линуксах.

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

Мысль интересная, дельная. Все мы отчасти животные… Я лично пушистая няшка (ну т. е. пушистый нях). ^_^ Тоже учу Бэш. Хорошая вещь, блин! Так приятно его учить, такой кайф получаю! Насколько же он хорош и продуман! Да и Линь в целом. А вот Раст учить не так кайфово будет, чувствую (если соберусь). Придётся многое переосмыслить. Удачи с Бэшем!

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

Ну в чём-то усложнили, в чём-то упростили. По-мне в расте нормальные макросы, уж явно лучше, чем C/C++.

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

В общем нормальные в расте макросы, не кипишуй.

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

Идиотский тезис. Если компилятор не может скомпилировать какой-то код идеально, зачем вообще писать не на ассемблере - так что-ли? Глупость же. Если вывод типов работает в 90% случаев, ну и славно. А он работает.

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

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

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

Впрочем в любом случае медленная компиляция сегодня это норма. Любой продвиинутый ЯП компилируется долго. Rust, Swift, TypeScript, C++. Rust тут никак особо не выделяется. Да, могли бы сделать упор на скорость компиляции, как это сделали в Go, но это был бы совсем другой язык.

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

Чего?

  1. Про сборщик мусора – он всё-таки есть, и даже не один?

Нет.

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

Нет.

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

Нет.

  1. Ну, про то, что сторонники Раста самые счастливые люди он ничего не объяснил. Каждый кулик своё болото хвалит. А вот как куликов сравнить объективно по уровню счастья – это уже сложнее.

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

И какого ты ответа ждёшь? Ну пусть будет единичка.

Резюмируя. По-мне Rust самый интересный ЯП за последние лет 30.

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

https://veresov.pro/rustmustdie/

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

Например.

Он всё время обращается к начинающему программисту, к месту и не очень. Начинающему вообще по барабану, является ли «println!» функцией или макросом, как и то, реализовано ли оно в стандартной библиотеке или в компиляторе или в комбинациях того, другого и чего-то третьего. Туда же идёт скорость компиляции, ведь хелловорлды всё равно не компилируются часами.

Никто из них не понимает, как работает этот язык, да это и невозможно понять.

Так уж «никто»? И по сравнению с чем? Точно не с C++, eсли вспомнить всякие UB, реализацию stdlib и прочие кишки gcc.

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

Но там причина ясна - мейнтейнеры местами дурачки и не знают как собирать софт на растишке

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

rupert ★★★★★
()