Rust — это сложно, или несчастье массового программирования Перевод

Yori Yori 4 Июня 2022

Когда вы используете Rust, иногда просто нелепо, сколько знаний языка, а также изобретательности и любознательности в программировании вам нужно, чтобы выполнить самые тривиальные вещи. Когда вы чувствуете себя особенно отчаянно, вы идете на rust/issues и ищете решение своей проблемы. Внезапно вы обнаружите проблему с объяснением того, что теоретически невозможно спроектировать ваш API таким образом из-за какой-то тонкой языковой ошибки.

Проблема с Rust

«Бесстрашный параллелизм» — формально правильное, но тем не менее вводящее в заблуждение утверждение. Да, у вас больше нет страха перед гонками данных, но у вас есть БОЛЬ, много боли.

Почему Rust такой сложный?

Иногда полезно понять, почему происходит дерьмо. «Потому что X — это плохо» — это не ответ; «Потому что люди, которые сделали X, плохие» — это тоже не объяснение.

Rust стремится сделать все эти вещи интуитивно понятными и безопасными для памяти. Эта офигенная комбинация подчеркивает человеческие ограничения дизайна компьютерного языка. Теперь должно быть совершенно понятно, почему Rust время от времени кажется дырявым; на самом деле, это почти чудо, что он вообще функционирует.

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

Как все может быть иначе?

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

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

В ожидании лучшего будущего

Так что, если я «во всем этом разобрался», почему бы мне не разработать более совершенную версию Rust? Я не хочу тратить следующие двадцать лет на попытки сделать это, учитывая, что шанс того, что мой язык выделится, бесконечно мал. Я думаю, что текущий набор наиболее используемых рабочих языков в какой-то степени довольно случайный — мы всегда можем сказать, почему конкретный язык стал популярным, но в целом мы не можем объяснить, почему лучшие альтернативы канули в лету.

Поддержка крупной корпорации? Случайно нацелились на ИТ-тенденцию будущего? Опять же, причины скорее социальные. Суровая реальность: в жизни иногда надежда играет гораздо более важную роль, чем все ваши умения и самоотверженность.

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

Rust — это сложно

https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-of-mainstream-programming.html

3 Ответа

  1. answer answer 4 Июня 2022 (ред.)

    Rust был задуман как системный язык, и не каждая проблема требует этого. Держите Rust сосредоточенным на том, что он делает, на системном программном обеспечении.

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

    1. на системном программном обеспечении.

      Тогда почему он называется «общего назначения»?

  1. Evg Evg 4 Июня 2022 (ред.)

    Прочитал полную статью про Rust.

    Вообще, конечно, многое зависит от задач, собственно. А «проблема» инструмента только в одном, мы прилипаем к нему. А они не бывают универсальные. Задач миллионы, а инструмент к которому мы «прилипли» один.

    Пример. Читал путь Tailwind, как автор в течении лет 10 писал css и улучшал подход в написание для своих задач. Он пробует, меняет подходы и получает Tailwind. Который по сути не особо предлагает что-то новое. Так люди писали лет 20 назад, те кто много занимался с фронтом. Но Tailwind сказал (и навязал, вот в этом молодец) некий стандарт. Далее он стал развивать Tailwind, улучшать тот подход к которому пришел.

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

    ИМХО, если задачу ставить во главе угла, то часто подход подходит не или/или, а то и то. Если человек может свободно (а для этого он должен легко), без проблем, разбираться в любой модели. Тогда глядя на некоторые задачи, функциональный подход Tailwind мы можем считать избыточным, например:

    mt5 — в коде, мы можем считать заплаткой (а давайте тут сделаем margin-top: 5**).

    Все меняется. От задач и уровня того кто пишет. Все больше убеждаюсь в этом, и в этом плане, некоторые «стандарты», «лучшие практики», которые выполняются слепо, только потому что они «лучшие», могут увести черт знает куда. Для задачи появляется избыточность.

    Tailwind, кто следует ему, может получить избыточность разных мелких mt5 в кода, Bootstrap, кто следует, появляется некая избыточность в конструкциях и не очень большая гибкость и т.д. Как экономия времени, для того чтобы что-то сделать, для начинающих (спорно) возможно и хорошие инструменты, но для себя, тут вопрос, который собственно упрется во вложения.

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

    Мы привязываемся очень сильно и смотрим на других, ИМХО. В нас есть это:

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

    Мы спорим про инструменты, языки, это вообще не имеет смысла.

    Если мы «танцуем» от задач. :)

    Так и по поводу Rust, мы услышали, что он «крутой» и взяли его. Не так надо, ИМХО, лучше от задачи «прыгать».

    А более конкретно (Rust не должен быть сложным):

    https://itsallaboutthebit.com/async-simple/

    Это один человек написал ответ (на англ. языке) на первую статью.