Стоит ли учить rust

Обновлено: 07.07.2024

Стоит ли изучать новый язык Rust? Возможно бы этот вопрос не встал бы раком, если бы сам Rust не оказался в зоне видимости моих окуляров, и на дороге тоже. Rust для меня стал как в спине хруст - хочешь не хочешь, а "изучать теперь надо". Как вкурить эту ржавчину если знаешь C++ в лучшем случае не выше 14 года, JavaScript не выше идеи 2016 года, а WebAssembly вообще проехал мимо знакомой остановки, да и программируешь лишь на IDE вроде Visual Studio. Дальше оси Windows вступать приходилось разве что "скомпилировал и запустил". И еще, жалко в Rust нету пока CUDA и SYCL.

capitalknew
> Стоит ли изучать новый язык Rust?
Для чего?
> да и программируешь лишь на IDE вроде Visual Studio
В VS Code хорошая поддержка Rust, хоть и не идеальная.
> Дальше оси Windows вступать приходилось разве что "скомпилировал и запустил".
У Rust проблем с этим нет. Поддержка винды очень хорошая.

desss
> Для чего?
В хРуст есть gfx-rs, который имеет и directx 12, и vulkan, и metal, и меньше замусорен.

capitalknew
> не встал бы раком
capitalknew
> хочешь не хочешь, а "изучать теперь надо"

со всеми добрыми лучшими пожеланиями.

Есть в инете статья, как чувак делал игру про змейку на rust и gl, погугли.

лучше один раз увидеть в деле чем семь раз обсудить на форуме

capitalknew
Если ты метишь в джуны, то окей. Если в синьеры и прочие гуглы, то нафиг. Задрочи свой основной core лучше.

Язык замечательный.
Изучать стоит.

capitalknew
"Когда я был молод. " Вопрос изучать что-либо или нет для меня не стоял, я учил все, что попадало в поле зрения и было интересно. И меня нисколько не волновало пригодится оно мне или нет. Ведь было интересно!
Потом я стал постарше, навалился быт и заботы и в общем-то приходилось изучать не то, что интересно, а то, что надо.
Теперь - я динозавр - стал толст и ленив - и, встречая очередную технологию, ловлю себя на мысли: "надо подождать лет пять-десять - а там либо оно сдохнет, либо я помру".
Я бы не назвал Rust хорошим, но он местами интересный.
Определитесь со своим возрастом и устремлениями, и поступайте соответственно.

lookid
> Задрочи свой основной core лучше
Диверсифицировать свои скиллы всегда полезно. Мало ли, завтра твой core станет никому не нужным.

Ну выглядит он, вроде, нормально

Dimich
> чувак делал игру про змейку на rust и gl, погугли.
ни гуглится(

desss
> Для чего?
В хРуст есть gfx-rs, который имеет и directx 12, и vulkan, и metal, и меньше замусорен.

capitalknew
> не встал бы раком
capitalknew
> хочешь не хочешь, а "изучать теперь надо"

со всеми добрыми лучшими пожеланиями.

Есть в инете статья, как чувак делал игру про змейку на rust и gl, погугли.

лучше один раз увидеть в деле чем семь раз обсудить на форуме

capitalknew
Если ты метишь в джуны, то окей. Если в синьеры и прочие гуглы, то нафиг. Задрочи свой основной core лучше.

Язык замечательный.
Изучать стоит.

Ну выглядит он, вроде, нормально

Dimich
> чувак делал игру про змейку на rust и gl, погугли.
ни гуглится(

desss
> Для чего?
В хРуст есть gfx-rs, который имеет и directx 12, и vulkan, и metal, и меньше замусорен.

capitalknew
> не встал бы раком
capitalknew
> хочешь не хочешь, а "изучать теперь надо"

со всеми добрыми лучшими пожеланиями.

Есть в инете статья, как чувак делал игру про змейку на rust и gl, погугли.

лучше один раз увидеть в деле чем семь раз обсудить на форуме

capitalknew
Если ты метишь в джуны, то окей. Если в синьеры и прочие гуглы, то нафиг. Задрочи свой основной core лучше.

Язык замечательный.
Изучать стоит.

Ну выглядит он, вроде, нормально

Dimich
> чувак делал игру про змейку на rust и gl, погугли.
ни гуглится(

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

Введение

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

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

Чем сложнее язык, тем богаче фразы, составленные с его помощью, и тем лучше он может выразить требуемую предметную область. Т.к. концепции обычно изучаются единожды, а применяются многократно, намного выгоднее с точки зрения вложения собственного времени изучить всякие страшные слова вроде "монадические трансформеры" (а еще, желательно, их смысл), чтобы потом экономить свои ментальные силы и тратить их на что-то более приятное. И поэтому весьма грустно видеть тренд некоторых компаний делать специально "упрощенные" языки. В итоге словарь этих языков намного меньше, и выучить его не составляет особого труда, но читать потом программы "моя твоя покупать лук" весьма тяжело, не говоря про возможные неоднозначные трактовки.

Основы

А что у нас в расте?

Утроенное количество кода, все эти реверансы с созданием переменной перед использованием (привет Паскаль!), вызовом кучи вспомогательного кода, и т.п. "Что за ужас" подумает среднестатистический разработчик и в очередной раз убедится в "системности" языка.

А ведь на самом деле это можно написать существенно проще:

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

Лайфтаймы и борроучекер

Ох уж эти страшные звери. Люди бросаются непонятными заклинаниями навроде

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

На деле же при написании прикладной программы вам скорее всего не понадобится указывать ни одного лайфтайма вообще. Причина этого в том, что в расте есть правила вывода лайфтаймов, которые почти всегда компилятор может выставить сам. Вот они:

Each elided lifetime in input position becomes a distinct lifetime parameter.
If there is exactly one input lifetime position (elided or not), that lifetime is assigned to all elided output lifetimes.
If there are multiple input lifetime positions, but one of them is &self or &mut self, the lifetime of self is assigned to all elided output lifetimes.
Otherwise, it is an error to elide an output lifetime.

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

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

Лично я вижу прелесть концепции в автоматическом управлении в нескольких аспектах

В итоге, код получается чистый (как в языке с GC), но в то же время все ресурсы освобождаются максимально быстро (как в языке с ручным управлением). А лайфтайм: декларативное описание ожидаемого времени жизни объекта. А декларативное описание всегда лучше, чем императивное "освободи объект здесь".

Жестокий компилятор

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

На самом деле компилятор действительно довольно придирчивый. Особенно это было верно до появления Rust 2018, когда компилятор в некоторых случаях не пропускал совершенно очевидно правильный код. Но и сейчас возникают проблемы, особенно от непонимания концепции владения. Например, когда человек пытается реализовать двусвязный список. При наивной реализации он сначала попробует сделать

Компилятор скомпилирует объявление этой структуры, но воспользоваться ей не получится, т.к. Box<Node> является владеющей ссылкой, или unique_ptr в терминах C++. А уникальная ссылка, конечно же, может быть только одна

Следующая попытка человека может выглядеть так:

Теперь у нас есть невладеющие ссылки (они же shared_ptr ), и их может быть сколько угодно на один объект. Но тут возникает две проблемы: во-первых владелец должен где-то быть. А значит мы скорее всего получим кучу ошибок компиляции "владелец умер, когда кто-то ссылался на его данные", потому как dangling pointers раст не допускает. А во-вторых, что важнее, мы не сможем изменять эти значения, из-за правил раста "либо одна мутабельная ссылка, либо произвольное количество иммутабельных, и никак иначе".

После этого человек обычно начинает биться о клавиатуру, и писать статьи что "в расте даже связный список реализовать нормально не получится". Реализовать же его, конечно, можно, но немного сложнее чем в других языках, придется руками добавить подсчёт ссылок (примитивы Rc / Arc / Cell / RefCell ), чтобы рантайме подсчитывать количество этих самых ссылок, потому что компилятор в данной ситуации бессилен.

Причины этого: эта структура данных плохо ложится на концепцию владения раста, вокруг построен весь язык и экосистема в целом. Любые структуры данных, где необходимо наличие нескольких владельцев потребуют некоторых приседаний, например реализация всевозможных лесов/деревьев/графов или тех же связных списков. Но это верно для всех языков программирования: попытки реализовать своё управление памятью в языках с GC приводит к страшным монстрам, работающих через WeakReferences с гигантскими byte[] массивам, воскрешающие объекты в деструкторах, чтобы вернуть их в пул, и прочей страшной некромантией. Попытки уйти от динамической природы JS, чтобы написать производительный код, приводит к еще более странным вещам.

Таким образом, в любом языке программирования есть своя "болевая точка", и в случае раста, это структуры данных с многими владельцами. Но, если мы смотрим с прикладной точки зрения высокоуровневых программистов, наши программы устроенны как раз таким образом. Например, в моем окружении типовое приложение выглядит как некоторый слой контроллеров, которые шарят между собой сервисы. Каждый сервис имеет ссылку на какие-то репозитории, которые возвращают какие-то объекты. Всё это отлично укладывается в концепцию ownership'а. И если учесть, что на практике основными структурами данных являются списки, массивы и хэшмапы, то оказывается, что всё не так уж и плохо.

Что же делать с этим зверем

Он говорит как раз о том, что мы передали владение ссылкой одному элементу, и уже не можем его использовать повторно. Также он нам рассказывает, что есть некий Copy трейт, который позволяет вместо перемещения объекта производить его копирование, из-за чего его использовать после "перемещения", потому что переместили мы копию. Если вы не знали про его существование, то ошибка компиляции снабдит вас информацией для размышления "А может стоит добавить реализацию этого трейта?".

Вообще, раст для меня первый язык, в котором есть compiler-driven development. Вы просто запускаете компиляцию, если что-то не работает, язык просто скажет вам "хмм, что-то не сходится. Я думаю, проблема в Х. Попробуй добавить вот этот код, и всё заработает". Типовой пример, допустим мы написали две функции, и забыли добавить ограничение на генерик:

Компилируем, получаем ошибку:

Да, IDE всех современных языков умеют это делать через всякие сниппеты, но во-первых тут польза в том, что вы видите, из какого крейта/неймспейса прилетело ограничение, а во-вторых это поддержка всё же со стороны компилятора, а не IDE. Это очень помогает при кросс-платформенной разработке, когда у вас локально всё собирается, а на некоторой матрице на CI сервере где-то что-то падает из-за условной компиляции. На билд-сервере IDE нет, а так лог глянул, подставил, и всё собралось. Удобно.

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

Уверенность в том, что собралось == работает действительно имеет место. Это не значит, что в коде нет багов, это значит, что все баги связаны с логикой приложения. У вас нет неожиданных нуллов, несихнронизированного доступа, buffer overflow и так далее. А их намного легче отловить, а иногда можно вынести на уровень типов (хорошая статья на тему).

Итого

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

Читайте также: