Человек устал от anti-Rust дерьма

Что: 85c3023b72091e91676af80ffd110cad74b7020a

Когда: 2021-02-11 01:45:11+03:00

Темы: go hate

Человек устал от anti-Rust дерьма

https://www.boringcactus.com/2021/02/09/anti-rust-horseshit.html
Что общего между "anti-vaxxers, flat earthers, 9/11 truthers" и
anti-Rust-er-ами? Начало радует. Но нет, автор, Rust дерьмо.

Нет, не потому что я "spent 5 minutes installing it, realized that
something was — gasp — different than C", а потому что я потратил неделю
на его сборку (и то не вышло под FreeBSD) на машине с 128GB RAM. Ведь
его авторы чихать хотели на то чтобы его можно было собрать из
исходников? Мол качайте бинарники наши. Это дерьмовый подход. Из серии
"и так сойдёт", "на отвали". Собирал то изначально для bootstrap-а
проект вообще сторонних людей mrustc.

И он дерьмо потому что безумно переусложнённый. Какие проблемы Rust
решает? Ой, да пофиг на вашу memory safety. Главная проблема --
сложность. Почти все проблемы в софте -- из-за сложности понимания,
сопровождения, написания, отладки, и т.д.. Вот Go отличный пример
продуманной простоты. А Rust -- пример как взяли перманентно
усложняющийся C++ и ещё круче навернули поверх него всяких фич. Это
дерьмовый fail. Rust это пример как люди совершенно не учатся на своих
ошибках (C++).

А главное что автор не понимает: Rust это замена C++, но никак не C
(откуда он берёт такую идею?). Собственно, почти со всеми аргументами
Drew DeVault-а я и согласен:
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
Среди всех хакеров кого читаю, среди любителей suckless и вообще Си,
среди людей из TUHS рассылки: никто не смотрит на Rust, как и почти
никто не смотрит на C++. А вот Go у всех в почёте.

Никто не спорит что в идеале бы вообще писать на формализуемых языках
только, формально доказываемые решения. Coq и прочее. Само собой и
memory safety это тоже хорошо. Вот только в мире нужно решать задачи за

оставить комментарий

комментарий 0:

From: Алексей
Date: 2021-02-11 12:53:12Z

Если бы Go не тащил с собою весьма объёмный рантайм, то Rust умер бы не родившись. Но увы - везде, где критичен размер кода (WebAssembly-апплеты, мелкие утилитки, демосцена, микроконтроллеры, драйвера) Go не подходит, потому что бинарники получаются слишком уж крупными. И вот здесь-то у нас есть выбор: либо C/C++, либо Rust.
При этом у сишки есть серьёзная проблема: программисты вдруг с удивлением выяснили, что C/C++ ни фига не кроссплатформенные языки. Да, они ПОЗВОЛЯЮТ писать кроссплатформенный код, но количество усилий, которые нужно для этого приложить, вызывает оторопь. Собственно, впервые с этим по-настоящему столкнулись при переезде с x86 на X_64: вдруг выяснилось, что код отказывается собираться без существенных правок. А когда собрался, то оказалось, что работает нестабильно, и его нужно основательно тестировать, а потом и отлаживать, выясняя, где и почему падает. А всего-то сменилась разрядность!
Сейчас же, когда платформы плодятся со страшной скоростью, всё стало совсем плохо. Именно поэтому ни один вменяемый разработчик не выберет C/C++ для нового проекта, если есть возможность решить ту же задачу на чём-то более кроссплатформенном. И это я ещё молчу про кросс-компиляцию, с которой у C/C++ инструментария даже не плохо, а хуже некуда. Попробуйте из-под Linux скомпилировать ваш OpenCV-проект для винды, и слегка офигеете от титанической сложности этой задачи. Даже с подсказками от SO быстрее чем за две недели вы никак не справитесь.
И сразу становится понятно, почему с машинным зрением и всякими прочими нейросетями предпочитают через Python работать.
Итог: Rust - кроссплатформенная замена C/C++ там, где больше их заменить попросту нечем из-за требований к размеру кода.

комментарий 1:

From: Sergey Matveev
Date: 2021-02-11 13:02:16Z


>Если бы Go не тащил с собою весьма объёмный рантайм, то Rust умер бы не родившись.

У этих двух языков по определению разные ниши и задачи. Runtime не
главное препятствие в Go для некоторых ниш которые вы перечислили.
Garbage collector -- основное. Так то само собой Go не годится для
некоторых задач.

>При этом у сишки есть серьёзная проблема: программисты вдруг с удивлением выяснили, что C/C++ ни фига не кроссплатформенные языки.

А чем принципиально Rust тут отличается в плане кроссплатформенности?
Даже с endianness-ом все вопросы точно так же остаются (на совести
разработчика). Честно говоря, впервые слышу упоминание что Rust более
"портируемый" чем C/C++.

В любом случае, из-за своей сложности (без компенсирующего profit-а),
заменой Си он быть не сможет.

комментарий 2:

From: kmeaw
Date: 2021-02-12 17:51:15Z

> Ведь
> его авторы чихать хотели на то чтобы его можно было собрать из
> исходников? Мол качайте бинарники наши. Это дерьмовый подход.

Но ведь с компиляторами C++ ситуация ровно такая же. Нужно скачать
бинарники, чтобы пересобрать компилятор. Просто обычно у всех уже есть
либо gcc, либо clang, поэтому проблема остаётся незаметной.

> А Rust -- пример как взяли перманентно
> усложняющийся C++ и ещё круче навернули поверх него всяких фич.

Это неправда. Идеи языка очень сильно отличаются от C++. В Rust не
придётся заниматься метапрограммированием на SFINAE, так как есть
нормальные макросы. Многие вещи, которые в C++ приводят к warning, на
Rust просто не компилируются.

> Rust это пример как люди совершенно не учатся на своих
> ошибках (C++).

Я бы сказал, что авторы Rust взяли C, и сделали с ним примерно то же,
что сделал с ним C++, но по-другому, стараясь не совершить те же ошибки.

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

комментарий 3:

From: Sergey Matveev
Date: 2021-02-12 18:29:23Z


>Но ведь с компиляторами C++ ситуация ровно такая же.

C++ собираются C. Ну а C -- да, надо откуда то брать. Но основная
претензия: изначально же Rust на чём-то был написан? Где-то слышал что
вроде как на OCaml. Который, в свою очередь, тоже написан сам на себе,
но есть корни в виде Си версии. Собственно, почему авторы Rust не
утруждаются "прокладыванием" всего пути сборки?

Я могу (не проверял, но сомнений мало) собрать
самый современный LLVM наверняка имея в своих руках только какую-нибудь
систему из конца 80-х годов с древним Си компилятором, которым смогу
собрать GCC разных версий и "дойти" до LLVM. Собственно в Guix для
сборки GCC используют C-компилятор на Scheme, TCC и возрастающие версии
GCC. На куче этих шагов можно использовать другой компилятор. Проблема
bootstrap-а всегда есть, но в случае с Си -- есть множество источников
где взять этот или другой Си.

Сейчас времена другие: вероятность что кто-то будет пытаться встраивать
что-то зловредное (backdoor) в компиляторы 80-х годов -- я бы считал
почти нулевой, тогда как сейчас я не могу доверять этим странным людям
(у которых странная "глава" их фонда) и их подходам и всей
геополитической ситуации, в основном связанной с США, где уже не раз их
спецслужбы были замечены в backdoor-стве.

С Rust же: имеет только один единственный источник его бинарей, в
отличии от десятков Си компиляторов, которым можно собрать любой другой
известный мне язык или другой компилятор, от другой команд. Современный
Go собирается Go 1.4, который уже собирается Си (благо его сборка
занимает минуты).

Для Rust единственное отдалённое спасение это mrustc проект. Которым я
всё же смог под Devuan собрать современный Rust. mrustc, ну а дальше
куча минорных версий Rust. И на каждом, каждом, каждом шаге постоянные и
регулярные проблемы и подвохи. Некоторые решения я подсмотрел в GNU Guix
пакетах. Но, почему этим должен заниматься конечный разработчик или
maintainer? Я убеждён что это ответственность автора языка. Это здорово
что кто-то взялся делать mrustc, но на FreeBSD у меня так и не вышло его
(или Rust им собрать) собрать. Плюс оно требует 16+GB RAM, которых у
меня нет ни в одной системе, но это уже второй вопрос. Прежде я
сталкивался только с PyPy, который на 4GB RAM не собирается.

Так что нет -- с Си ситуация очень и очень отличающаяся, как минимум
тьмой источников этих самых компиляторов. Но да, изначально где-то да
придётся взять бинарник, которым уже можно собрать Scheme, TCC, GCC,
LLVM, whatever, Go 1.4, Go 2.x, и т.д.. Главная претензия: сами авторы
не видел чтобы что либо делали по этому поводу, их не парит. А сейчас
времена с доверием к бинарям и backdoor-ами совсем другие, чем были в 80-е.

Я думаю что mrustc улучшит поддержку (хотя может и сейчас там стало
получше -- не слежу же) FreeBSD и других платформ и проблема возможно
уйдёт. Но это в любом случае не говорит хорошо об авторах самого Rust,
с моей точки зрения. Это как писать нетривиальную программу без
документации (без которой многий софт бы был буквально бесполезен, где
ценность книг может быть колоссальна).

>Это неправда. Идеи языка очень сильно отличаются от C++.

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

>Я бы сказал, что авторы Rust взяли C, и сделали с ним примерно то же,
>что сделал с ним C++, но по-другому, стараясь не совершить те же ошибки.

Ну можно и так сказать, тоже вариант :-)

>Да, язык получился сложным, потому что решает сложную задачу - пытается
>дать memory safety гарантии на этапе компиляции с помощью богатой
>системы типов.

Пару месяцев я на нём пытался программировать, честно (после того, как
его по факту всё же можно хотя бы для одной системы собрать). Ну,
изучал, что-то делая криптографическое на нём. Вещи связанные с memory
safety я не отношу к сложности. Ну в смысле с ними сложно, но потому что
сама задача сложна. Возможно я не прав и не допонял до конца, но 90%
всего что я видел кроме memory safety штук мне показалось исключительно
только сплошным сахаром и возможностями выражения одного и того же тьмой
способов. Конкретные примеры не назову, ибо уже не помню. 90% у меня
уходило не на "борьбу" с memory safety (точнее её удовлетворение), а на
просто написание и использование библиотек. Но я в принципе не особо то
дружу со всей этой темой связанной с типизацией и возможно всё что мне
казалось бесполезным сахаром и самовыражением -- было на самом деле ради
типизации и безопасности. Не исключаю. Но по сути максимум что я на нём
осилил, это AES шифрование в каком-то режиме. После, я пошёл уже к боссу
со словами что больше не могу, совершенно не идёт, совершенно не
нравится (да и не удобно, ведь Rust то у меня собраный был только под
Devuan и я через прослойку эмуляции Linux-а из FreeBSD запускал
компилятор), а месяцы прошли без полезного выхлопа. Даже Erlang,
функциональный язык, мне проще давался и что-то в нём даже понравилось.

Я понимаю что тот факт что *я* его не осилил -- не говорит плохо о
языке. Это говорит что у меня мозгов мало. Не спорю. Только проблемы с
его сборкой объективны (но на GNU/Linux были решаемы -- подтверждаю). Но
я думаю не много кто будет спорить с тем, что не много программистов
программистов сможет писать формально верифицируемые программы (с Coq-ом
каким-нибудь). Для этого нужно *очень* много мозгов. Хотя в идеале бы
всё делать формально верифицируемым, ни никто не берётся это делать.
Rust для меня примерно из этой же серии -- не для мозгов большинства, к
коему я отношусь. Это значит что нам лучше вообще не браться за
программирование? С точки зрения Кнута и прочих светил computer science
-- да. Но даже наши умения, даже на Си, is good enough для многих задач.
Для меня это тема "лучшего vs хорошего", is good enough, перфекционизма
(неоправданно дорого).

Сгенерирован: SGBlog 0.34.0