У меня есть несколько мыслей об изучении языков программирования.

Во-первых, мы подходим к этому неправильно. Я уверен, что вы испытывали такие же ощущения. Вы пытаетесь изучить новый язык и не совсем понимаете, как в нём всё устроено. Почему в одном месте используется один синтаксис, а в другом другой? Все эти странности раздражают, и в итоге мы возвращаемся к привычному языку.

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

Это очень похоже на обсуждение автомобилей. Слышали о новом Ford Bratwurst? Насколько он быстр? Смогу ли я проехать на нём через озеро?

Когда мы похожим образом говорим о языках, то подразумеваем, что они взаимозаменяемы. Как машины. Если я знаю, как управлять Toyota Hamhock, значит смогу вести и Ford Bratwurst без каких-либо проблем. Разница только в скорости и приборной панели, не так ли?

Но представьте, как будет выглядеть PHP-автомобиль. А теперь вообразите, насколько будет отличаться автомобиль Lisp. Пересесть с одного на другой потребует гораздо большего, чем усвоить, какая кнопка управляет отоплением.

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

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

Таким образом, моя следующая идея такова: лучше изучать язык через его ключевые особенности. Если мы поймём, почему в языке были приняты те или иные решения, будет проще понять, как именно он работает.

 Давайте посмотрим на ключевые ценности Rust: Давайте отложим параллелизм на время и сфокусируемся на двух остальных целях Rust: скорости и безопасности работы с памятью.

Стоит уточнить: в Rust под "безопасностью работы с памятью" подразумевается, что он не допустит ошибку сегментации (segmentation fault), которая знакома вам не понаслышке, если вы работали с С или С++. Если же вы (как и я) избегали этих языков, тогда это может быть непривычным. Представьте себе следующие ситуации: В Ruby вы можете получить исключение, но в таких языках, как C, случится нечто похуже. Возможно, ваша программа аварийно завершится. А может быть, она выполнит какой-то произвольный код, и ваша небольшая программа на С приведёт к гигантской уязвимости. Упс.

Под "безопасностью работы с памятью" в Rust подразумевается то, что такой проблемы не возникнет.
Примечание переводчика: Rust разрешает утечки памяти в безопасном коде и не может гарантировать их отсутствие в общем случае. Поскольку гарантировать отсутствие циклических ссылок для Rc/Arc (указателя со счётчиком ссылок) невозможно, функция forget не является "небезопасной" (unsafe). Логика понятна, хотя мне крайне не нравится — предпочёл бы чтобы эта функция всё-таки была unsafe, чтобы подчеркнуть, что с ней надо обращаться осторожно.

Ruby тоже защищает вас от ошибок сегментации, однако использует для этого сборщик мусора. Это здорово, но оказывает негативное влияние на производительность.

Но ведь Rust придаёт скорости большое значение! Следуя этой цели, Rust отказывается от сборщика мусора. Управление памятью — задача программиста. Подождите, а как же все эти ужасающие баги, которые я упоминал?! Так как Rust ценит скорость, он заставляет меня управлять памятью. Вот только если второй ключевой ценностью этого языка является безопасность работы с памятью, то почему он заставляет меня работать с ней вручную?!

Между этими двумя целями наблюдается явное противоречие. Помня об этом, давайте попробуем разобраться в Rust! 

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

Стремясь гарантировать безопасность работы с памятью, как вариант, вы можете запретить изменения данных.

Таким образом, в Rust всё по умолчанию неизменно (immutable). 

Конечно же, создатели Rust хотят, чтобы люди пользовались их языком. Так что мы можем объявить переменные изменяемыми, если это реально необходимо. 

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

Вот только не создаст ли проблемы возможность изменять данные? Одна из целей языка — это безопасность работы с памятью. Изменяемость данных и безопасность работы с памятью кажутся взаимоисключающими. 

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

Давайте посмотрим, как это работает: 

Многословный синтаксис String::from создаёт строку, которой мы действительно владеем. Затем мы передаём владение, и в этот момент original_owner владеет… ничем. У нашей строки может быть только один владелец.

Через систему владения Rust обеспечивает безопасность работы с памятью. Если у данных может быть только один владелец, то возможность изменить их разными потоками управления одновременно исключается. По тем же причинам невозможно обратиться к данным, которые были уничтожены.

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

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

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

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

Для начала о функциях. Мы объявляем их точно так же, как нашу функцию main: 

Наша функция same_length должна принимать два параметра: исходную строку и строку для сравнения. 

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

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

И снова о явности. Функции должны декларировать не только то, что они принимают, но и тип возвращаемого значения. Мы возвращаем bool: 

Круто. Это компилируется. Давайте попробуем реализовать сравнение. У строк есть функция len, которая возвращает их длину: 

Здорово. Теперь произведём два сравнения! 

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

Это выглядит как серьёзное ограничение. Хорошо, что Rust ценит безопасность работы с памятью так высоко, но стоит ли оно того?

Rust игнорирует наше недовольство и придерживается своих ценностей, вводя понятие заимствования (borrowing). Значение может иметь только одного владельца, но любое количество заимствующих. Заимствование в Rust обозначается символом &. 

Ранее мы пытались реализовать это через передачу владения и потерпели неудачу, но с одалживанием всё получилось. Попробуем использовать такой же подход в нашей функции: 

Мы явно одолжили наши данные функции, которая явно говорит, что только одалживает их, а не забирает владение. Когда same_length завершается, то заканчивается и одалживание, но данные не уничтожаются.

Погодите, разве это не нарушает безопасность памяти, о которой мы столько говорили? Не приведёт ли это к катастрофе? 

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

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

Если мои теории, упомянутые в начале статьи, верны, это введение в одалживание не получилось таким уж сложным. Надеюсь, это понятнее, чем если бы я сказал: "Rust позволяет одалживать данные, просто не забывайте использовать &, и всё будет хорошо". Надеюсь.

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