Haskell
- Парадигма: чисто функциональный, ленивый, декларативный, сильный акцент на неизменности и чистых функциях.
- Модель памяти: управляемая средой выполнения (RTS) с сборщиком мусора; данные неизменяемы по умолчанию, активно используются persistent-структуры.
- Управление ресурсами: GC + идиомы вроде `bracket`/ResourceT; появляются линейные типы, но детерминистская финализация не универсальна.
- Система типов: статическая, сильная, HM‑вывод, тайпклассы, GADTs, расширения для типовой абстракции.
- Экосистема: Hackage/Cabal/Stack — богата для функциональных задач (STM, Conduit, Pipes), но меньше по количеству пакетов, чем у больших экосистем.
Rust
- Парадигма: мульти‑парадигменный (системный, императивный + функциональные элементы), ориентирован на безопасность памяти.
- Модель памяти: без GC; владение/заимствование + lifetime-анализ на этапе компиляции; стек + куча, нулевой оверхед абстракций.
- Управление ресурсами: RAII (Drop), детерминистские деструкторы.
- Система типов: статическая, сильная, обобщения + трейт‑система, явные lifetime’ы, строгая проверка на этапе компиляции.
- Экосистема: Cargo/crates.io — быстрорастущая, сильна в системном/сете/асинхронном коде (tokio, async‑ecosystem), хороша для FFI и WebAssembly.
Python
- Парадигма: мульти‑парадигменный (императивный, ООП, элементы функционального стиля).
- Модель памяти: интерпретаторное выполнение (в CPython — подсчёт ссылок + циклический GC); объекты изменяемы по умолчанию.
- Управление ресурсами: GC + контекстные менеджеры (`with`); детерминистичность освобождения зависит от реализации (CPython — refcount обеспечивает предсказуемость).
- Система типов: динамическая, duck typing; опционные аннотации для статического анализа (mypy).
- Экосистема: самая большая — обилие библиотек для web (Django, Flask, FastAPI), data science, scripting и т. п.
Рекомендации по задачам
- Задача $1$: параллельная обработка потоков данных — предпочтительнее Rust.
Обоснование: нулевая стоимость абстракций, владение/заимствование даёт предсказуемое управление памятью и отсутствие стоп‑пауз GC, зрелые async/параллельные фреймворки (tokio, rayon), низкая латентность и высокая пропускная способность. Haskell хорош для декларативных стримов (conduit/pipes, STM) но GC и ленность могут усложнить поведение при высоких нагрузках; Python ограничен GIL для CPU‑параллелизма и подходит лишь для IO‑bound снаружи.
- Задача $2$: разработка безопасной низкоуровневой библиотеки — предпочтительнее Rust.
Обоснование: Rust даёт безопасность памяти на этапе компиляции без GC, контроль над размещением в памяти, безопасный FFI и детерминистское освобождение ресурсов (Drop). Haskell не предназначен для системного кода без значительных накладных и RTS; C/С++ опасны из‑за UB. Rust обеспечивает баланс производительности и безопасности.
- Задача $3$: быстрая прототипная разработка веб‑сервиса — предпочтительнее Python.
Обоснование: максимальная скорость разработки, богатые фреймворки (Django, Flask, FastAPI), простая интеграция с БД/аутентификацией/шаблонами и огромная экосистема. Производительность можно компенсировать горизонтальным масштабированием или вынести узкие места в Rust/C. Haskell может дать безопасный, типобезопасный сервис, но более крутая кривая обучения и меньше готовых шаблонов; Rust требует больше времени на реализацию и типичные boilerplate для прототипа.