LINUX.ORG.RU

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

 , ,


0

6

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

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

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

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

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

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

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

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

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

(c) Tom Swan

foxtrot
()

И отзыв от геймдева: https://habr.com/ru/articles/811163/

Ржавый нужен только если тебе кровь из носу надо написать что-то что не падает и не переполняется ни при каких условиях.

И вообще, выбирай язык под задачу, а не учи наобум.

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

Долгожданная статья ученика Столярова о том, что rust-говно.

Самой статьи нет.

Долгожданная статья ученика Столярова о том, что rust-говно.

Ты бы написал, что это один и тот же вброс. И не пришлось проводить расследований.

Ygor ★★★★★
()

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

А я Свифтом, но ничего не читаю, кроме документации. Так интереснее. :)

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

Ржавый нужен только если тебе кровь из носу надо написать что-то что не падает и не переполняется ни при каких условиях.

И как? Получается?

У меня с ржавым в системе только Firefox и он почти уже не падает!

hateyoufeel ★★★★★
()

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

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

peregrine ★★★★★
()
  1. Любая более высокоуровневая абстракция увеличивает накладные расходы и кривую обучения. И это нормально. Вопрос правильно должен звучать как: «А что дают макросы, чтобы платить эту цену?». Если у Вас конкретно нет ответа - они вам пока не нужны. А может и никогда не понадобятся.

  2. Так понижается порог обучения. Какая бы ни была хорошая система автоматического вывода типов - лучше указывать вручную. Всегда. Так компилятор и Вы будете уверены, что поняли друг друга правильно. Ближайший пример такого - Typescript, где таки типы лучше всегда указывать вручную.

  3. Во-первых, такой компилятор написать проще. Во-вторых, так возникает меньше ошибок при компиляции. В-третьих, это не такая проблема, как говорит автор.

  4. Автор не разобрался с концепцией владения данными.

  5. Что понимать под сборщиком мусора? В том или ином виде да, есть. Любую автоматическую очистку памяти можно назвать сборщиком мусора.

  6. Не забываем, что есть окружение запуска программы. У любого языка сегодня оно есть. Количество строк в этм случае не проблема. Вопрос в организации окружения и итоговой оптимизации. Но да, на чистом ассемблере программа будет иметь меньше лишнего. А так же работать чуть быстрее. Вопрос цены разработки такой программы.

  7. Вопрос не корректно задан. Он звучит как:«А зачем мне еще один компилируемый язык программирования?» Ответ очевиден, как ни смешно. У него есть современная экосистема. И если она будет работать стабильно и избавит вас от рутины - стоит. Если же вы в целом не пишите на компилируемых языках (а это на самом деле очень узкий круг задач - современные мощности вполне покрываются даже CPython для большего количества задач), то и не нужно.

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

entropy-ronin
()
Ответ на: комментарий от MoldAndLimeHoney

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

peregrine ★★★★★
()

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

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

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

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

fn main() {
    let value = String::from("Hello, Rust!");
    print_value(&value);
    println!("{}", value);
}

fn print_value(val: &String) {
    println!("{}", val);
}
Clockwork ★★★★★
()

Про сборщик мусора – он всё-таки есть

Про Rc не совсем понятно. Это ж про другое, нет? 🤔 Rc реализует ручной подсчет ссылок, а не автоматическое управление памятью, как в яп со сборщиком мусора. Т.е. что объекты освобождаются сразу, как только счетчик ссылок достигает нуля.

В каких нибудь Java и C# освобождение происходит в произвольный момент времени.

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

Без cargo rust всё-таки довольно хорош. Порой напрягает чрезмерное количество проверок,например в 99% случаях проверка на overflow с паникой это огромная лишняя трата времени, как и bounds. Они конечно повышают безопасность, но практически никогда не могут быть выкинуты оптимизацией для внешних данных, а случаев когда внешние данные реально внешние семантически - не так уж много
Ну а с cargo он не сильно лучше js+npm или pip, ведь программист уже не отвечает за то, что попадает в итоговый бинарь

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

например в 99% случаях проверка на overflow с паникой это огромная лишняя трата времени

Вроде бы говорили, что Rust так делает только в Debug-е, а в Release проверок на overflow уже нет. Что-то поменялось?

eao197 ★★★★★
()

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

MOPKOBKA ★★★★
()

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

С буквами и нотами тоже всё понятно. А вот общего мнения какая книга/музыка лучше всё нет и нет.

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

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

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

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

Сишники — больные ублюдки. Чэйндж май майнд.

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

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

Аналогия в точку, как котёнок с дверцей.

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

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

А зачем использовать оптимизатор для обхода проверок? Код хоть и будет работать технически правильно, но результат не соответствует ожиданиям из-за переполнения.

Clockwork ★★★★★
()

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

Как говорил Страуструп: «Существует два вида языков программирования: те, на которые постоянно ругаются и те, которыми никто не пользуется.»

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

Очень красиво получилось на Rust Playground :)

ЗЫ. А такой стектрейс в Rust-приложениях – это прям из коробки или нужно код в каком-то специальном режиме компилировать/собирать?

eao197 ★★★★★
()

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

в лучшем случае, если людям не надоест весь этот borrow checker, будет сделан более приличный новояз, с нормальными классами, более похожий на с++ лайт, чем на рукожопый руст.

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

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

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

alysnix ★★★
()