Traits в Rust и Typeclasses в Haskell: битва абстракций

Введение: зачем сравнивать Rust и Haskell?

Если вы когда-нибудь заглядывали на Stack Overflow в поисках ответа на вопрос "What is the difference between traits in Rust and typeclasses in Haskell?", то знаете: тема горячая. Тысячи просмотров, десятки голосов — сообщество разработчиков действительно хочет понять, чем эти два механизма отличаются.

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

В этой статье мы разберём ключевые отличия на реальных примерах кода на Rust (с вкраплениями Haskell для контраста), а в конце вы получите чёткое понимание: когда использовать traits, а где лучше подумать о typeclass-подобном подходе.

Краткий обзор: что такое traits в Rust?

Traits в Rust — это способ объявить набор методов, которые должны быть реализованы для определённого типа. Это основа обобщённого программирования (generics) и полиморфизма в Rust.

Простой пример: представьте, что мы хотим, чтобы разные типы умели «здороваться».

trait Greeter {
    fn greet(&self) -> String;
}

struct Person {
    name: String,
}

impl Greeter for Person {
    fn greet(&self) -> String {
        format!("Привет, меня зовут {}!", self.name)
    }
}

struct Robot {
    model: String,
}

impl Greeter for Robot {
    fn greet(&self) -> String {
        format!("Бип-буп, модель: {}", self.model)
    }
}

fn say_hello(item: &impl Greeter) {
    println!("{}", item.greet());
}

fn main() {
    let person = Person { name: "Анна".into() };
    let robot = Robot { model: "R2-D2".into() };
    say_hello(&person);
    say_hello(&robot);
}

Здесь Greeter — это trait. Типы Person и Robot реализуют его по-своему. Функция say_hello принимает любой тип, реализующий Greeter. Это и есть полиморфизм через traits.

Краткий обзор: что такое typeclasses в Haskell?

Typeclass в Haskell — это интерфейс, определяющий набор функций, которые могут быть реализованы для разных типов. Звучит знакомо, правда?

Вот как выглядел бы аналогичный пример на Haskell:

class Greeter a where
    greet :: a -> String

data Person = Person { name :: String }
data Robot = Robot { model :: String }

instance Greeter Person where
    greet (Person n) = "Привет, меня зовут " ++ n ++ "!"

instance Greeter Robot where
    greet (Robot m) = "Бип-буп, модель: " ++ m

sayHello :: Greeter a => a -> IO ()
sayHello item = putStrLn (greet item)

main = do
    sayHello (Person "Анна")
    sayHello (Robot "R2-D2")

Синтаксис разный, но логика — та же. И всё же отличия traits в Rust от typeclasses в Haskell начинаются именно здесь.

Ключевое отличие №1: Мономорфизация vs бокс (Box)

Самое фундаментальное различие между traits и typeclasses кроется в том, как компилятор обрабатывает обобщённый код.

Rust: мономорфизация

Когда вы пишете fn say_hello(item: &impl Greeter), компилятор Rust создаёт отдельную копию функции для каждого конкретного типа. Это называется мономорфизация. Результат: нулевая стоимость абстракции (zero-cost abstraction) — вы не платите за то, что не используете. Но размер кода может расти.

Haskell: бокс (по умолчанию)

В Haskell typeclass-ы обычно реализуются через словари методов (vtable). Компилятор передаёт неявный параметр — таблицу с указателями на функции. Это называется боксинг. Вы платите за косвенный вызов, но код не раздувается.

Практический вывод для Rust-разработчика: если вам важна производительность и вы работаете с небольшим количеством типов — используйте impl Trait или <T: Trait> (мономорфизация). Если типов много и размер кода критичен — рассмотрите Box<dyn Trait> (динамическая диспетчеризация).

// Мономорфизация (быстро, но копируется код)
fn process<T: Greeter>(item: &T) { ... }

// Динамическая диспетчеризация (меньше кода, но медленнее)
fn process_dyn(item: &dyn Greeter) { ... }

Ключевое отличие №2: Ассоциированные типы и функциональные зависимости

В typeclasses Haskell есть мощная фича — функциональные зависимости (functional dependencies) и ассоциированные типы (associated types). Rust тоже поддерживает ассоциированные типы, но функциональных зависимостей — нет.

Пример на Haskell:

class Collection c where
    type Element c   -- ассоциированный тип
    add :: c -> Element c -> c
    get :: c -> Int -> Maybe (Element c)

В Rust это выглядит похоже:

trait Collection {
    type Element;
    fn add(&mut self, item: Self::Element);
    fn get(&self, index: usize) -> Option<&Self::Element>;
}

struct MyVec<T> {
    items: Vec<T>,
}

impl<T> Collection for MyVec<T> {
    type Element = T;
    fn add(&mut self, item: T) {
        self.items.push(item);
    }
    fn get(&self, index: usize) -> Option<&T> {
        self.items.get(index)
    }
}

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

Ключевое отличие №3: Правила согласованности (orphan rules)

В Rust действуют orphan rules: вы не можете реализовать чужой trait для чужого типа. Это предотвращает конфликты, но иногда раздражает. В Haskell таких ограничений нет — вы можете объявить instance для любого типа в любом модуле (хотя это может привести к overlapping instances).

Пример нарушения orphan rules в Rust:

// Ошибка! Мы не можем реализовать стандартный trait Display
// для стандартного типа Vec, если мы не объявили Vec в нашем крейте.
// impl std::fmt::Display for Vec<u32> { ... }

Почему это важно? Потому что traits в Rust — это не просто интерфейсы, а инструмент контроля над кодом. Они гарантируют, что вы не «сломаете» чужой код своими реализациями.