Cloud Haskell — это фреймворк / DSL для разработки конкарент распределенных отказоустойчивых приложений без разделяемого состояния. Типа Erlang, только лучше. Как минимум, за счет строгой статической типизации , компиляции в нативный код и более приятного синтаксиса. Кроме того, как будет показано ниже, Cloud Haskell лишен некоторых родовых травм Erlang’а и в некоторых аспектах более гибок.
Если сравнивать Cloud Haskell с Erlang , то можно отметить следующее:
- Помимо динамически типизированных сообщений, как в Erlang, Cloud Haskell также предлагает статически типизированные каналы. Эти каналы дают не только статическую проверку типов передаваемых сообщений. Например, один процесс может иметь много каналов;
- Кроме очередей сообщений и каналов в Cloud Haskell также есть функционал (типобезопасный, понятное дело), похожий на тот, что предоставляет пакет async Саймона Марлоу или футуры в Scala ;
- Есть аналог Open Telecom Platform, только здесь он называется The Cloud Haskell Platform. Есть supervisor (так и называется — Supervisor), что-то вроде типобезопасного gen_server (называется ManagedProcess), а также всякие удобняшки типа функции sendAfter и многое другое;
- Есть линки и мониторы (let it crash!), но без такого бардака, как в Erlang. Во-первых, линки здесь однонаправленные и, если только не пытаться вручную поймать соответствующие асинхронные исключения , всегда прибивают процесс, установивший линк. То есть, никакого trap_exit. Во-вторых, если попытаться создать линк или монитор на умерший процесс, происходит в точности то, что ожидается . Поэтому в Cloud Haskell функция spawnLink просто делает spawn, а затем link, безо всякой атомарности. В-третьих, как линки, так и мониторы, работают с процессами, нодами и портами (теми, через которые происходит запись в каналы). В Erlang, например, линковаться к нодам нельзя;
- Как и в Erlang, обмен сообщениями, каналы, линки и мониторы можно использовать для процессов, работающих на разных нодах, в том числе, находящихся на разных физических машинах. Строгая статическая типизация при этом, разумеется, никуда не девается. Впрочем, как мы уже выясняли, использовать распределенный Erlang и аналоги нужно с умом;
- Процессы могут использовать обычные примитивы, такие, как MVar или STM , благодаря чему мы не очень-то нуждаемся в ETS или Mnesia и можем с легкостью написать нормальный LRU кэш , что не так-то просто в Erlang ;
- Вообще, нам доступно все то, что обычно доступно в Haskell — нормальные строки, нормальное метапрограммирование , словари, множества, очереди с приоритетами, а также другие контейнеры, ленивые вычисления , и так далее;
- При желании мы можем придумать собственный способ сериализации сообщений, вручную написав для них экземпляр класса типов Binary. Например, можно прикрутить какое-нибудь приведение строк к нижнему регистру, сжатие данных или и то, и другое;
- Отметим, что Cloud Haskell — это совершенно обычная библиотека, никак не завязанная на возможности системы времени исполнения. В частности, это означает, что при желании мы можем написать собственный транспорт для передачи сообщений и прочее в таком духе. Согласно, например, этой презентации , это может быть очень важно для HPC кластеров. И вообще, если подумать, это же целый новый мир. Можно, например, попробовать предусмотреть какую-то совместимость с Erlang или Akka . Можно обмениваться сообщениями через RabbitMQ. Можно воспользоваться готовым транспортом для сообщений в проекте, никак не связанном с Cloud Haskell. Можно тупо добавить какой-нибудь удобный функционал. Например, одном из бэкендов для Cloud Haskell, distributed-process-simplelocalnet , есть механизм автоматического обнаружения и соединения новых нод;
Понятно, что ознакомиться со всем этим хозяйством в рамках одной-двух заметок не предоставляется возможным, поэтому мы посмотрим только на простейший пример и основные функции, пока что без обмена данными между нодами на разных машинах, местного OTP и других интересных вещей.
Дополнение: Простейший пример использования Cloud Haskell