В любом серьезном приложении должно быть логирование, и по возможности логов должно писаться как можно больше. Тут даже обсуждать нечего. Наиболее каноничным средством для решения этой задачи в мире 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.
Недавно коллега рассказал мне об одном интересном паттерне в Erlang’е. На самом деле, то, о чем он рассказал, это настолько полезная и очевидная фигня, что я не понимаю, как мне до сих пор нигде не попадалось упоминание сего приема (возможно, все-таки попадалось, но я не предал этому особого значения) и как можно было не додуматься до такого самостоятельно.
Мое первое знакомство с Erlang состоялось в июле 2012-го, но зарабатывать программированием на этом языке я начал только год назад, 19 ноября 2012. В сей заметке я хотел бы поделиться своими впечатлениями от практического использования Erlang на протяжении всего этого времени.
Что-то в последнее время мне подозрительно часто стали задавать этот вопрос. Как по мне, тут все предельно просто, и на пост тема едва ли тянет. Но раз люди интересуются, видимо, у них возникают какие-то сложности с самостоятельным поиском ответа, так что, наверное, кому-нибудь этот пост пригодится.
Один из наиболее запутанных вопросов при изучении Haskell — это обработка исключений. Многие учебники, в том числе LYH, повествуют об исключениях, описанных в стандарте Haskell 98, создавая тем самым ошибочное впечатление, что в Haskell нельзя объявлять собственные исключения. А в RWH, например, в качестве «современных» функций для работы с исключениями называются throwDyn, catchDyn и прочие. В результате многие хаскелисты не понимают и боятся исключений, а асинхронные исключения так и вовсе считают какой-то черной магией. Благодаря этой небольшой заметке вы узнаете, как же на самом деле в Haskell обрабатываются исключения.