Привет! Мы – часть команды разработки «Рамблер/Медиа» (портал «Рамблер»). На протяжении трех лет мы поддерживаем и развиваем несколько больших python-приложений. Чуть больше года назад перед нами встала задача написать еще одно большое приложение – API к основному хранилищу новостей, и мы сделали это на Rust.

В статье мы расскажем о том, что заставило нас отойти от привычного стека технологий, и покажем, какие плюсы по сравнению с Python есть у Rust.

Мы не ответим на вопрос, почему выбор пал именно на Rust, а не Go, например, или на какой-либо другой язык. Также мы не будем сравнивать производительность Python- и Rust-приложений – эти темы достойны отдельного обсуждения.

Этот материал написали cbmw и AndreyErmilov

Содержание:

1. Первая часть (типы, пользовательские типы и полиморфизм, перечисления, Option и Result, паттерн-матчинг, трейты и протоколы, обобщенное программирование)
2. Вторая часть (многопоточность, асинхронность, функциональная парадигма и заключение – «Зачем же питонисту Rust») – готовится к публикации и выйдет чуть позже

Если не хочется читать эту статью или невтерпеж ждать второй части материала, можно посмотреть видео нашего выступления.

Типы

Первое различие, с которым сталкиваются разработчики, Rust – язык со статической типизацией.

Можно по-разному смотреть на динамическую и статическую типизацию, но, на наш взгляд, основное отличие демонстрирует изображение ниже:

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

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

Тут на сцену выходит mypy, как самое зрелое решение в этой области. Сам создатель языка Python активно принимает участие в разработке mypy. И это замечательный инструмент, позволяющий проанализировать код и найти те самые проблемы с типизацией. Давайте рассмотрим его детально.

Начнем с крайне простого примера:

from typing import List

def last(items: List[int]) -> int:
    return items.pop()

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

С точки зрения mypy и нотации типов этот код является вполне корректным:

? mypy --strict types-01.py
Success: no issues found in 1 source file

А теперь давайте рассмотрим аналогичный код в Rust:

fn last(mut items: Vec<i32>) -> i32 {
    items.pop()
}

И посмотрим, к чему приведет попытка его скомпилировать:

?  types git:(master) ? cargo run
error[E0308]: mismatched types
  |
1 | fn last(mut items: Vec<i32>) -> i32 { 
  |     items.pop()
  |     ^^^^^^^^^^^ expected `i32`, 
  |                 found enum `std::option::Option`
  |
  = note: expected type `i32`
             found enum `std::option::Option<i32>`

Ошибка компиляции явно говорит о том, что метод .pop() в каких-то случаях может вернуть None. И действительно, если мы в качестве аргумента передадим пустой вектор, так и произойдет.

Но почему mypy не предупредил нас о потенциальной ошибке? Дело в том, что в Python при пустом списке произойдёт Exception, который никак не учитывается и не отражается в нотации типов. Это кажется достаточно большой проблемой, которая не позволяет использовать возможности статической типизации в полной мере. В целом существование исключений и их игнорирование в системе нотации типов перекладывает ответственность за корректность кода на разработчика.

Отлично, давайте перепишем Python-код по аналогии с Rust, не вызывая исключения:

from typing import List, Optional

def last(array: List[int]) -> Optional[int]:
    if len(array) == 0:
        return None
    return array.pop()

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

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

Пользовательские типы и полиморфизм

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

Рассмотрим задачу. У нас есть разные сущности – расстояние, которое измеряется в километрах и метрах, и время, которое измеряется в часах и секундах. Мы хотим уметь получать скорость. Опишем структуры:

/// Distance, km
struct Kilometer(f64);

/// Distance, m
struct Meter(f64);

/// Time, h
struct Hour(f64);

/// Time, s
struct Second(f64);

/// Speed, km/h
struct KmPerHour(f64);

/// Speed, km/s
struct KmPerSecond(f64);

/// Speed, m/h
struct MeterPerHour(f64);

/// Speed, m/s
struct MeterPerSecond(f64);

Реализуем операцию деления для километров и метров и в каждом случае будем получать свой тип:

/// Speed, km/h
impl Div<Hour> for Kilometer {
    type Output = KmPerHour;
    fn div(self, rhs: Hour) -> Self::Output {
        KmPerHour(self.0 / rhs.0)
    }
}
/// Speed, km/s
impl Div<Second> for Kilometer {
    type Output = KmPerSecond;
    fn div(self, rhs: Second) -> Self::Output {
        KmPerSecond(self.0 / rhs.0)
    }
}
/// Speed, m/h
impl Div<Hour> for Meter {
    type Output = MeterPerHour;
    fn div(self, rhs: Hour) -> Self::Output {
        MeterPerHour(self.0 / rhs.0)
    }
}
/// Speed, m/s
impl Div<Second> for Meter {
    type Output = MeterPerSecond;
    fn div(self, rhs: Second) -> Self::Output {
        MeterPerSecond(self.0 / rhs.0)
    }
}

Проверим, что наш код работает. Rust в зависимости от типов, которые мы делим и на которые мы делим, определит, какого типа будет скорость.

fn main() {
    let distance = Meter(100.);
    let duration = Second(50.);
    let speed = distance / duration;  // MeterPerSecond
    assert_eq!(speed.0, 2.);

    let distance = Kilometer(180.);
    let duration = Hour(3.);
    let speed = distance / duration;  // KmPerHour
    assert_eq!(speed.0, 60.);
}

Реализуем тоже самое на Python.

Опишем структуры:

@dataclass
class Hour:
    """Time, h."""
    value: float

@dataclass
class Second:
    """Second, s."""
    value: float

@dataclass
class KmPerHour:
    """Speed, km/h."""
    value: float

@dataclass
class KmPerSecond:
    """Speed, km/s."""
    value: float

@dataclass
class MeterPerHour:
    """Speed, m/h."""
    value: float

@dataclass
class MeterPerSecond:
    """Speed, m/s."""
    value: float

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

from typing import overload

@dataclass
class Kilometer:
    value: float

    @overload
    def __truediv__(self, other: Hour) -> KmPerHour: ...

    @overload
    def __truediv__(self, other: Second) -> KmPerSecond: ...

    def __truediv__(self, 
                    other: Union[Hour, Second]
                   ) -> Union[KmPerHour, KmPerSecond]:
        if isinstance(other, Hour):
            return KmPerHour(self.value / other.value)
        elif isinstance(other, Second):
            return KmPerSecond(self.value / other.value)

...

Проверим код, используя mypy:

?  01-types poetry run mypy --strict typing-02-2.py
Success: no issues found in 1 source file

А теперь случайно ошибемся в возвращаемом типе: при делении на секунды будем возвращать километры в час:

if isinstance(other, Hour):
    return KmPerHour(self.value / other.value)
elif isinstance(other, Second):
    return KmPerHour(self.value / other.value)

Запустим mypy:

?  01-types poetry run mypy --strict typing-02-2.py
Success: no issues found in 1 source file

Mypy не видит в коде с ошибкой никакой проблемы, потому что мы по-прежнему возвращаем одно из корректных значений, описанных в Union[KmPerHour, KmPerSecond].

Явно укажем, что ожидаем получить при делении на секунды именно км/с, и снова запустим mypy.

speed: KmPerSecond = Kilometer(1.0) / Second(1.0)
assert isinstance(speed, KmPerHour)

?  01-types poetry run mypy --strict typing-02-2.py
Success: no issues found in 1 source file

Понятно, почему это происходит, но не понятно, как избежать подобных ошибок с mypy.

Перечисления

Перечисления существуют во многих языках. Посмотрим, как в Python и Rust происходит работа с ними.

Создадим перечисление, описывающее возможные состояния пользователя:

from enum import Enum, auto

class UserStatus(Enum):
    PENDING = auto()
    ACTIVE = auto()
    INACTIVE = auto()
    DELETED = auto()

Сделаем тоже самое в Rust:

enum UserStatus {
    Pending,
    Active,
    Inactive,
    Deleted,
}

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

enum UserStatus {
    Pending(DateTime<Utc>),
    Active(i32),
    Inactive(i32),
    Deleted,
}

В примере для статуса Pending мы храним информацию о том, как долго мы ожидаем подтверждения от пользователя; для активного и неактивного пользователей храним их идентификаторы.

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

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

Option и Result

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

pub enum Option<T> {
    None,
    Some(T),
}

pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

Давайте на примере разберем, как использование Option влияет на корректность работы приложения.

let mut vec = vec![1, 2, 3];

let last_element = vec.pop();
assert_eq!(last_element, Some(3));

Когда мы достали из вектора правый элемент, то получили не число, а значение типа Option, содержащее в варианте Some нужное число. Мы не сможем его сложить с другим числом, т.к. в этом случае мы потерям информацию о возможном варианте None.

let mut vec = vec![1, 2, 3];

let last_element = vec.pop();
assert_eq!(last_element, Some(3));

let four = last_element + 1; 
// Cannot add `std::option::Option<{integer}>` to `{integer}`

Чтобы использовать полученное из вектора число мы можем прибегнуть к паттерн-матчингу, который мы рассмотрим еще ниже. А сейчас проверим, как аналогичный код работает в Python. Мы используем написанную нами функцию last(), чтобы возвращаемый тип был Optional.

from typing import List, Optional

def last(array: List[int]) -> Optional[int]:
    if len(array) == 0:
        return None
    return array.pop()

numbers = [1, 2, 3]
last_element = last(numbers)
four = last_element + 1

?  01-types poetry run mypy --strict typing-04-1.py
typing-04-1.py:12: error: Unsupported operand types for + ("None" and "int")
typing-04-1.py:12: note: Left operand is of type "Optional[int]"

Mypy, как и комплиятор Rust, не позволит нам сложить опциональное значение с числом. Но для этого программисту нужно будет самостоятельно указать, что возвращаемое значение Optional.

Паттерн-матчинг

Раз уж мы упомянули pattern-matching, давайте, наконец, раскроем эту концепцию чуть подробнее.

Для начала рассмотрим следующий Python-код:

class UserStatus(Enum):
    PENDING = auto() 
    ACTIVE = auto()
    INACTIVE = auto()
    DELETED = auto()

def serialize(user_status: UserStatus) -> str:
    if user_status == UserStatus.PENDING:
        return 'Pending'
    elif user_status == UserStatus.ACTIVE:
        return 'Active'
    elif user_status == UserStatus.INACTIVE:
        return 'Inactive'
    elif user_status == UserStatus.DELETED:
        return 'Deleted'

Все, что этот код делает, – преобразует элементы перечисления UserStatus в строковое представление. Выглядит это достаточно просто.

А теперь рассмотрим аналогичный вариант на Rust:

enum UserStatus {
    Pending,
    Active,
    Inactive,
    Deleted,
}

fn serialize(user_status: UserStatus) -> &'static str {
    match user_status {
        UserStatus::Pending => "Pending",
        UserStatus::Active => "Active",
        UserStatus::Inactive => "Inactive",
        UserStatus::Deleted => "Deleted",
    }
}

Разница в том, что в случае, когда разработчик по какой-то причине (например, если добавляется новый статус пользователя при рефакторинге) не опишет один из исходных вариантов перечисления в функции serialize, Rust ему об этом скажет:

fn serialize(user_status: UserStatus) -> &'static str {
    match user_status {
        UserStatus::Pending => "Pending",
        UserStatus::Active => "Active",
    }
}

// Error: non-exhaustive patterns: `Inactive` and `Deleted` not covered

Это и есть одно из отличительных свойств pattern-matching в Rust. При его использовании в коде компилятор заставляет рассмотреть все варианты.
И возвращаясь к функции last, которую мы приводили в начале: при обработке Option, являющегося результатом вызова функции, компилятор не даст забыть обработать ситуацию, при которой результатом выполнения станет None.

Соответственно, аналогичное правило касается и типа Result:

let number = "5";
let parsed: Result<i32, ParseIntError> = number.parse();

let message = match parsed {
    Ok(value) => format!("Number parsed successfully: {}", value),
    Err(error) => format!("Can't parse a number. Error: {}", error),
};
assert_eq!(message, "Number parsed successfully: 5");

В случае если нам нужно определить некоторое дефолтное поведение, Rust предоставляет следующую конструкцию:

fn fibonacci(n: u32) -> u32 {
    match n {
        0 => 1,
        1 => 1,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

В этом примере мы видим, что описаны только два конкретных значения, а для всех остальных рекурсивно вызывается функция fibbonacci.

Трейты и протоколы

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

Представим, что нам нужно написать функцию-валидатор, которая принимает список экземпляров класса Image и возвращает список из булевых значений. True будет обозначать, что изображение валидное и весит не больше, чем MAX_SIZE, False – невалидное. Напишем код:

from typing import List

MAX_SIZE = 512_000

class Image:
    def __init__(self, image: bytes) -> None:
        self.image = image

def validate(images: List[Image]) -> List[bool]:
    return [len(image) <= MAX_SIZE for image in images]

Если мы запустим mypy, то увидим следующую ошибку:

?  01-types poetry run mypy --strict p-01-2.py
p-01-2.py:8: error: Argument 1 to "len" has incompatible type "Image"; expected "Sized"
Found 1 error in 1 file (checked 1 source file)

Mypy сообщает, что ожидается класс типа Sized, а мы вместо этого передали Image. Из документации становится понятно: все, что реализует магический метод __len__, является Sized.

В Python мы давно привыкли к утиной типизации, и требование реализовать метод __len__ кажется вполне понятным. Сделаем это.

from typing import List

MAX_SIZE = 512_000

class Image:
    def __init__(self, image: bytes) -> None:
        self.image = image

    def __len__(self) -> int:
        return len(self.image)

def validate(images: List[Image]) -> List[bool]:
    return [len(image) <= MAX_SIZE for image in images]

После добавления __len__ mypy определит код как корректный.

Итого – Sized это и есть протокол, а про наш класс Image можно сказать, что он реализует протокол Sized.

Но давайте рассмотрим тему протоколов немного подробнее и усложним задачу – будем валидировать различные документы по их статусу – были ли они проверены и можно ли их публиковать. Функция validate будет возвращать только те документы, которые прошли проверку.

from abc import abstractmethod
from typing import List, Protocol

class SupportsReview(Protocol):
    @abstractmethod
    def approved(self) -> bool: ...

class Article(SupportsReview):
    def approved(self) -> bool:
        return True

class PhotoGallery(SupportsReview):
    def approved(self) -> bool:
        return True

class Test(SupportsReview):
    def approved(self) -> bool:
        return True

def validate(documents: List[SupportsReview]) -> List[SupportsReview]:
    return [
        document for document in documents
        if document.approved()
    ]

documents = [Article(), PhotoGallery(), Test()]
approved_documents = validate(documents)
assert len(approved_documents) == 3

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

Сравнивая протоколы в Python с трейтами в Rust, мы увидим, что они очень похожи. Давайте напишем тоже самое на Rust.

Начнем с создания трейта Review:

trait Review {
    fn approved(&self) -> bool;
}

Создадим структуры и реализуем для них трейт Review:

struct Article;

impl Review for Article {
    fn approved(&self) -> bool {
        true
    }
}

struct PhotoGallery;

impl Review for PhotoGallery {
    fn approved(&self) -> bool {
        true
    }
}

struct Test;

impl Review for Test {
    fn approved(&self) -> bool {
        true
    }
}

Опишем функцию validate и запустим код:

fn validate(documents: Vec<Box<dyn Review>>) -> Vec<Box<dyn Review>> {
    documents
        .into_iter()
        .filter(|document| document.approved())
        .collect::<Vec<_>>()
}

fn main() {
    let documents: Vec<Box<dyn Review>> = vec![
        Box::new(Article),
        Box::new(PhotoGallery),
        Box::new(Test),
    ];
    let approved = validate(documents);
    assert_eq!(approved.len(), 3);
}

Код на Rust выглядит менее понятно, чем код на Python за счет появления типов Box и описания поддержки трейта Review, как dyn Review. Это важный момент – за все приходится платить, и это плата за статическую типизацию.

Обобщенное программирование

Мы обсудили протоколы и выяснили, что с их помощью мы можем накладывать ограничения на типы, с которым работаем. Но что делать, если нам нужно описать для типа более одного ограничения и указать, что при этом везде должен быть один и тот же тип? На помощь нам приходят дженерики. Рассмотрим, как строится работа с ними в Python и сравним с Rust.

Реализуем узел бинарного дерева поиска:

from typing import Generic, TypeVar, Optional

T = TypeVar('T')

class Node(Generic[T]):
    def __init__(self, value: T,
                 left: Optional['Node'[T]] = None,
                 right: Optional['Node'[T]] = None,
                 ) -> None:
        self.value = value
        self.left = left
        self.right = right

if __name__ == '__main__':
    root = Node(2)
    root.left = Node(1)
    root.right = Node(3)

Мы описали обобщенный тип T, который может храниться внутри узла. Запустим mypy и убедимся, что все корректно описано.

?  01-types poetry run mypy --strict generics-01-1.py
Success: no issues found in 1 source file

Ошибемся в одном значении внутри узла и посмотрим, как mypy отловит эту ошибку:

root = Node(2)
root.left = Node(1)
root.right = Node('Hello!')  # Тут ошибка

При создании корня дерева mypy определил тип T как int и не должен позволить нам создать другой узел с типом str.

generics-01-1.py:18: error: Argument 1 to "Node" has incompatible type "str"; expected "int"
Found 1 error in 1 file (checked 1 source file)

Mypy верно поймал ошибку.

Но достаточно ли нам для описания узла дерева текущего определения? На данный момент мы наложили только одно ограничение – все типы внутри дерева должны быть одинаковыми. Но чтобы реализовать бинарное дерево поиска, необходимо уметь сравнивать значения внутри. Например, сейчас мы можем в узлы положить None и при этом код будет определяться, как корректный.

Давайте наложим на тип T дополнительное ограничение – T должен реализовывать протокол сравнения. Поищем протокол Comparable.

К сожалению, разговоры про этот протокол шли еще в 2015 году, но он так и не появился. Реализуем его самостоятельно:

C = TypeVar('C')

class Comparable(Protocol):
    def __lt__(self: C, other: C) -> bool: ...

    def __gt__(self: C, other: C) -> bool: ...

    def __le__(self: C, other: C) -> bool: ...

    def __ge__(self: C, other: C) -> bool: ...

И добавим в бинарное дерево поиска:

...
T = TypeVar('T', bound=Comparable)

class Node(Generic[T]):
    def __init__(self, value: T,
                 left: Optional['Node'[T]] = None,
                 right: Optional['Node'[T]] = None,
                 ) -> None:
        self.value = value
        self.left = left
        self.right = right

    def add(self, node: 'Node'[T]) -> None:
        if node.value <= self.value:
            self.left = node
        else:
            self.right = node

if __name__ == '__main__':
    root = Node(2)
    root.add(Node(1))
    root.add(Node(3))

Mypy проверяет код и подтверждает, что все корретно. Попробуем ошибиться и проверим, как mypy отловит ошибку:

root = Node(None)
root.add(Node(None))
root.add(Node(None))

?  01-types poetry run mypy --strict generics-01-4.py
generics-01-4.py:35: error: Value of type variable "T" of "Node" cannot be "None"
generics-01-4.py:36: error: Value of type variable "T" of "Node" cannot be "None"
generics-01-4.py:37: error: Value of type variable "T" of "Node" cannot be "None"
Found 3 errors in 1 file (checked 1 source file)

Ошибка поймана, все работает.

Теперь реализуем тоже самое на Rust.

struct Node<T> 
    where T: Ord
{
    pub value: T,
    pub left: Option<Box<Node<T>>>,
    pub right: Option<Box<Node<T>>>,
}

impl<T> Node<T> 
    where T: Ord 
{
    pub fn add(&mut self, node: Node<T>) {
        if node.value <= self.value {
            self.left = Some(Box::new(node))
        } else {
            self.right = Some(Box::new(node))
        }
    }
}

fn main() {
    let mut root = Node { value: 2, left: None, right: None };
    let node_1 = Node { value: 1, left: None, right: None };
    let node_3 = Node { value: 3, left: None, right: None };
    root.add(node_1);
    root.add(node_3);
}

Код похож на тот, который мы делали в Python, но трейт сравнения нам не нужно писать самостоятельно. Он уже есть, и мы просто описываем его where T: Ord.

Это отличие не кажется принципиальным, и можно сделать вывод, что протоколы и дженерики в Python не уступают Rust.

К сожалению, это не так.

from typing import TypeVar, Generic, Sized, Hashable

T = TypeVar('T', Hashable, Sized)

class Base(Generic[T]):
    def __init__(self, bar: T):
        self.bar: T = bar

class Child(Base[T]):
    def __init__(self, bar: T):
        super().__init__(bar)

На этот код mypy выведет:

?  01-types poetry run mypy --strict generics-01-6.py
generics-01-6.py:13: error: Argument 1 to "__init__" 
    of "Base" has incompatible type "Hashable"; expected "T"
generics-01-6.py:13: error: Argument 1 to "__init__" 
    of "Base" has incompatible type "Sized"; expected "T"
Found 2 errors in 1 file (checked 1 source file)

Этот пример скопирован из issue mypy на гитхабе и висит там уже достаточно давно.

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

Продолжение следует ?