Привет! Мы – часть команды разработки «Рамблер/Медиа» (портал «Рамблер»). На протяжении трех лет мы поддерживаем и развиваем несколько больших python-приложений. Чуть больше года назад перед нами встала задача написать еще одно большое приложение – API к основному хранилищу новостей, и мы сделали это на Rust.
В статье мы расскажем о том, что заставило нас отойти от привычного стека технологий, и покажем, какие плюсы по сравнению с Python есть у Rust.
Мы не ответим на вопрос, почему выбор пал именно на Rust, а не Go, например, или на какой-либо другой язык. Также мы не будем сравнивать производительность Python- и Rust-приложений – эти темы достойны отдельного обсуждения.
Этот материал написали cbmw и AndreyErmilov
Содержание:
- Первая часть (типы, пользовательские типы и полиморфизм, перечисления, Option и Result, паттерн-матчинг, трейты и протоколы, обобщенное программирование)
- Вторая часть (многопоточность, асинхронность, функциональная парадигма и заключение – «Зачем же питонисту 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 fileMypy не видит в коде с ошибкой никакой проблемы, потому что мы по-прежнему возвращаем одно из корректных значений, описанных в 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 же позволяет сделать это.
