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

Проще говоря: нарушение доступа к памяти — это какие-то действия с некорректными данными, а утечка памяти — это отсутствие определённых действий с корректными данными. В табличной форме:

1
2
3

                    Корректные данные     Некорректные данные
Используются        OK                    Ошибка доступа к памяти
Не используются     Утечка памяти         OK

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

Год назад произошёл выпуск первой стабильной версии языка — Rust 1.0. С тех пор язык активно развивался. Ещё вчера про Rust никто не знал, а сегодня Dropbox переписал на нём ядро своей дисковой инфраструктуры.

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

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

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

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

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

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

Когда мы похожим образом говорим о языках, то подразумеваем, что они взаимозаменяемы. Как машины. Если я знаю, как управлять Ладой Саранск, значит смогу вести и УАЗ Рыбак без каких-либо проблем. Разница только в скорости и приборной панели, не так ли?

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

Примечание: Эта статья предполагает, что читатель знаком с Rust FFI (перевод), порядком байтов (endianess) и ioctl.

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

На днях я участвовал в обсуждении на reddit того, насколько трудны на самом деле времена жизни. При работе над clippy мне не приходилось до этого времени иметь с ними дела, потому что всем, чем мы пользовались, владел компилятор, особого мнения на этот счёт у меня не было, и тут The_Doculope заявил:

Есть места, в которых опускание времён жизни может укусить нас за задницу.

(/u/The_Doculope на /r/rust)

Честно говоря, я был шокирован!

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

(я на /r/rust)

Сразу после написания этого, мне попалась строка в исходном коде clippy, которой я был не очень доволен, потому что в ней происходило клонирование строки (с помощью .to_string()! богохульство!) просто для использования её в &format(…). Итак, происходило это в Result<String, …>::unpack_or(…), поэтому сначала я попытался дать обладаемой строке такое же время жизни, как и у полученной, без особого смысла.

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

Я избавлю вас от этих покрытых моей кровью сообщений об ошибках, потому что убеждён — если вы писали код на Rust, вы их знаете наизусть, и, даже наоборот, на самом деле все было не так уж и плохо, потому что, к счастью, я вспомнил такой удобный std::borrow::Cow, а уж переписать сниппет с ним (и std::convert::From) было раз плюнуть. Я даже создал fn для его повторного использования, таким образом, так я официально написал свой первый метод, аннотированный временем жизни. [ДОСТИЖЕНИЕ ОТКРЫТО]