В любом серьезном приложении должно быть логирование, и по возможности логов должно писаться как можно больше. Тут даже обсуждать нечего. Наиболее каноничным средством для решения этой задачи в мире Haskell является гибкий и богатый возможностями пакет hslogger. Сегодня мы научимся работать с ним.

На этой неделе мы проделали большую работу. Если вы честно прочитали весь цикл постов о Cloud Haskell, во всем разобрались и прорешали домашку, то можете с чистой совестью пойти в ближайший магазин и купить себе какую-нибудь вкусняшку. Если ничего не поняли, не расстраивайтесь. Спокойно разберитесь в непонятных вопросах и вернитесь к Cloud Haskell через пару-тройку недель. Не пытайтесь разобраться во всем наскоком, в мире Haskell это не работает! В заключение мне хотелось бы поделиться кое-какими своими мыслями, а также привести ссылки на дополнительные материалы по теме.

На данный момент мы уже посмотрели на Cloud Haskell в действии и выяснили, в чем заключаются отличия Cloud Haskell от Erlang. Сегодня же мы посмотрим на основные функции, предоставляемые Cloud Haskell. В том числе, на функции для работы с типизированными каналами, а также функции receiveTimeout, register, whereis, getProcessInfo, и другие. Про распределенщину пока не будет, потому что этот вопрос я и сам еще не до конца осилил :)

Итак, у вас было целых два дня на то, чтобы подготовиться к подаче материала про Cloud Haskell, а также составить общее впечатление об отличиях Cloud Haskell от Erlang. Сегодня же мы наконец-то увидим пусть и простую, но саму что ни на есть настоящую программу, использующую сабж. Возможно, кто-то из читателей предпочел бы сначала ознакомиться с детальным описанием API, но я лично всегда больше любил учиться на примерах, так что API отложим до завтра.

Cloud Haskell — это фреймворк / DSL для разработки конкарент распределенных отказоустойчивых приложений без разделяемого состояния. Типа Erlang, только лучше. Как минимум, за счет строгой статической типизации, компиляции в нативный код и более приятного синтаксиса. Кроме того, как будет показано ниже, Cloud Haskell лишен некоторых родовых травм Erlang’а и в некоторых аспектах более гибок.

Как я уже когда-то писал, потоки в Haskell сделаны как можно более легковесными для минимизации накладных расходов и чтобы поверх них можно было сотворить все что угодно. Прекрасным примером всего что угодно является Cloud Haskell. Это попытка принести в мир Haskell модель акторов а-ля Erlang. И, как оказалось, попытка эта на редкость удачная. Не как Akka.

Что-то в последнее время мне подозрительно часто стали задавать этот вопрос. Как по мне, тут все предельно просто, и на пост тема едва ли тянет. Но раз люди интересуются, видимо, у них возникают какие-то сложности с самостоятельным поиском ответа, так что, наверное, кому-нибудь этот пост пригодится.

Один из наиболее запутанных вопросов при изучении Haskell — это обработка исключений. Многие учебники, в том числе LYH, повествуют об исключениях, описанных в стандарте Haskell 98, создавая тем самым ошибочное впечатление, что в Haskell нельзя объявлять собственные исключения. А в RWH, например, в качестве «современных» функций для работы с исключениями называются throwDyn, catchDyn и прочие. В результате многие хаскелисты не понимают и боятся исключений, а асинхронные исключения так и вовсе считают какой-то черной магией. Благодаря этой небольшой заметке вы узнаете, как же на самом деле в Haskell обрабатываются исключения.

MessagePack — это формат, напоминающий JSON, только более быстрый и более компактный. Например, {"a":1,"b":2} занимает 13 байт в JSON, 19 байт в BSON и всего лишь 7 байт в MessagePack. MessagePack RPC представляет собой протокол удаленного вызова процедур, основанный на MessagePack. Полная реализация MessagePack RPC предоставляет синхронный и асинхронный обмен сообщениями по TCP, UDP или через Unix-сокеты. Давайте выясним, как работать со всем этим хозяйством в Haskell.

Недавно мне пришло письмо от одного из посетителей с просьбой помочь решить небольшую проблему с OCaml‘ом. И как-то между делом он поинтересовался, почему я отказался от OCaml в пользу Haskell. После небольшого раздумья я ответил, что это сложный вопрос и что я не готов вот так сразу на него ответить, а также пообещал когда-нибудь написать пост на эту тему. И вот, я наконец-то собрал свои мысли в кучку.