Записки программиста

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

Начну с мыслей.

Любой евангелист Erlang’а скажет вам, что Cloud Haskell — говно, потому что в нем нет (1) remsh, (2) горячего обновления кода, (3) релизов, и вообще, (4) Haskell очень сложный язык, а Erlang учится за две недели. Ну, с релизами все понятно, их на самом деле даже эрлангисты бояться и не понимают. На счет (1), (2) и (4) все менее однозначно. Можно написать очень много буков по этой теме, но в двух словах я считаю следующее.

Возможно, вы потратите пару лишних недель на изучение Haskell, но зато с ним вы будете спокойнее спать по выходным и меньше времени тратить на выяснение, почему все тормозит, хотя, казалось бы, мы просто данные туда-сюда гоняем. Значение горячего обновления кода и remsh часто сильно преувеличиваются. В некоторых ситуациях они действительно довольно удобны, но это не те вещи, без которых вы не сможете жить. Есть общепринятые практики, например, альфа- и бета-тестирование, релизы раз в неделю, выкатка кода на процент серверов, включение фичи на процент пользователей, ничего не катить за две недели до нового года, разбиение системы на мелкие компоненты, code review, откат к предыдущей версии приложения при возникновении проблем, запись метрик в Graphite, и так далее, которые позволяют без всего этого обходиться. Пишут же распределенные системы, скажем, на Java. Если же вам прям ну очень хочется remsh, мы уже выясняли, что сделать его в Haskell несложно, особенно если воспользоваться Template Haskell.

Дополнение: Асло remsh не позволяет вам разобраться в ситуации, когда система адски тормозила час назад, когда вы ехали в метро, но нормально работает сейчас, когда вы наконец добрались до компа. И не предоставляет удобного REST API для службы поддержки, админов и QA, позволяющего хотя бы частично понять проблему без необходимости будить разработчиков посреди ночи. Поэтому даже при программировании на Erlang ничто не освобождает вас от необходимости логировать вообще все, что происходит в системе, писать кучу метрик и программить шаблонный код REST-концов, позволяющих заглянуть внутрь всех ваших стейтов, за исключением разве что тех, которые лежат в PostgreSQL и Memcached.

В данном контексте не могу не поделиться одним наблюдением. Есть подозрение, что многие эрлангисты неправильно понимают идиому «let it crash!». Им кажется, что этот принцип позволяет им не писать валидацию форм, не проверять входные данные функций, писать в логи тонны нечитаемых сообщений, катить в бой всякую фигню, а потом, когда в выходные позвонят клиенты, отлаживать все прямо на живом через remsh и чинить хотфиксом. Мы же пишем на Erlang, let it crash! На самом деле, ничего подобного.

Если вы откроете 13-ю главу второго издания книги «Programming Erlang» Джо Армстронга (кстати, в первом издании идиома вообще не встречается), то обнаружите, что «let it crash!» в первом приближении означает всего лишь следующее. Во-первых, если что-то пошло не так, сразу бросайте исключение. Напишите отдельный обобщенный код, который ловит и обрабатывает эти исключения. Например, ошибка соединения с базой данных может произойти при вызове разных функций, не писать же в каждой из них свой обработчик. Во-вторых, в распределенных системах может падать сеть, сгорать жесткие диски и так далее. Поэтому зачастую ошибку нельзя обработать там, где она на самом деле произошла. Грубо говоря, если вы ходите с ноды А на ноду Б, а нода Б упала, то ошибку нужно обрабатывать на ноде А. Во всем написанном вам помогут линки и мониторы.

Вот и все! Как видите, ничего, кроме здравого смысла. В общем, всем наплевать, на чем вы там пишите. В приложении должна быть нормальная валидация, нормальные сообщения об ошибках, нормальные логи, и так далее. И вообще, есть куда более фундаментальный принцип — «пользователи не должны страдать (во всяком случае, не больше обычного)». Об этом, кстати, там же у Армстронга написано.

Хотелось бы также заметить следующее. Если вы посмотрите в код Cloud Haskell, то обнаружите, что он на удивление прост и понятен. Изучать его намного проще, чем читать код виртуальной машины Erlang’а. На момент написания этого текста реализация всего Cloud Haskell, с учетом дочерних проектов, «платформы», тестов и примеров, занимала менее 22 000 строк кода (не считая комментариев и пустых строк), что по нынешним меркам является не таким уж крупным проектом.

Так что, если вам всегда было интересно, как можно сделать среду с обменом сообщениями, линками и мониторами, это ваш шанс. Также Cloud Haskell (да и вообще, весь Haskell) привлекателен в качестве полигона для экспериментов. Вы можете реализовать свой транспорт, добавить собственный примитив (например, типизированную очередь сообщений ограниченного размера с приоритетами), попытаться написать свой Observer с магией и эльфийками, и так далее.

Ну и последнее. Haskell — самый что ни на есть настоящий ООП язык. По тем же причинам, почему Erlang является настоящим ООП языком.

Ссылки по теме:

• Официальный сайт и список рассылки;
• Репозиторий с примерами использования Cloud Haskell;
• Из документа Cloud Haskell Semantics (PDF) можно почерпнуть знания о всяких тонких моментах, если документация на Hackage молчит;
• На Haskell Wiki есть страница, посвященная Cloud Haskell, с большой подборкой материалов;
• В книге «Parallel and Concurrent Programming in Haskell» работе с Cloud Haskell посвящена целая глава;

Как всегда, буду рад любым дополнениям и вопросам!

Метки: Haskell, Параллелизм и многопоточность, Функциональное программирование.