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

Темы седьмого выпуска: Erlang R17, GHC 7.8.1, MongoDB 2.6, все о модели акторов, транзакционной памяти и девушках в белорусском геймдеве, зачем Валера заставил себя пощупать Scala с Rx и почему он осуждает Akka, как учить Java в третьем тысячелетии, битва не на жизнь, а на смерть между Akka и Erlang, и не только. Предыдущие выпуски: шестой, пятый, четвертый, третий.

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/7/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/7/file/podfm_eaxcast__eaxcast_107.mp3

Шоу нотес:

• Поддержите нашу кампанию по сбору средств на запись второго сезона;
• Срелизился Erlang R17, в LYSE появилась глава о maps;
• Наконец-то вышел GHC 7.8.1, хороший обзор новшеств — на LOR;
• Также недавно вышла MongoDB 2.6;
• Страничка Reactive Extensions на GitHub;
• Упомянутая Светой TypeSafe Console, для разработчиков бесплатна;
• По теме Акки Света рекомендует блог letitcrash.com, а также эту серию постов о паттернах обработки сообщений;
• 41-ый выпуск подкаста «Разбор Полетов», также с участием Светы;

Голоса выпуска: Светлана @sbozhko Божко, Валерий @sum3rman Мелешкин, Александр @afiskon Алексеев

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

 

Валерий: Всем привет, с вами EaxCast, это последний выпуск в этом сезоне, поговорим об этом чуть подробнее в конце выпуска. Сегодня здесь со мной Саша afiskon Алексеев.

Александр: Всем привет.

В: И Света Божко.

Светлана: Привет.

В: Сразу всех хочу поздравить с выпусками свежих релизов Erlang и GHC. В Erlang наконец появились maps. Ну и собственно теперь к теме выпуска. Слово тебе, Саша.

А: Я только хочу отметить, что к моменту, когда мы все выложим, это будет уже давно не новость. Просто мы записываемся 9-го числа в 10 вечера и для нас только-только сегодня, почти одновременно вышли GHC и Erlang R17, поэтому здесь все очень рады, у нас просто какой-то праздник. Еще вот Света нам перед началом выпуска подсказала, что там недавно вроде MongoDB релизилась?

С: Да, 8-го числа зарелизилась Монга. Там довольно-таки много изменений. Я думаю, в show-notes добавим ссылку на release notes, там будет все подробно описано.

А: А еще в книжке «Learn you some Erlang» прям моментально появилась глава про maps. Я думаю, она была заранее написана, но все ж приятно.

А темы выпуска у нас очень простые. У нас в гостях Света и мы с ней пообщаемся на всякие прикольные темы, касающиеся мира Java, касающиеся Akka, ну и там дальше по ходу — как пойдет.

Свет, расскажи немного о себе, чем занимаешься, где работаешь, где училась, так, в двух словах.

С: В двух словах? На данный момент я студентка 5-го курса Белорусского Государственного Университета Информатики и Радиоэлектроники. Сейчас пишу свой дипломный проект, и одновременно работаю Java-программистом в довольно-таки небольшой компании, и работаю над игровым проектом.

А: Я даже не знаю с чего начать. Начни с темы дипломного проекта, если не секрет, конечно.

С: Нет, конечно, не секрет. Тема моего дипломного проекта, целиком и польностью повторяет то, над чем я работаю в проекте своем рабочем — это «Высоконагруженный игровой сервер».

А: То есть ты пишешь… Ты в game-dev, у тебя server-side на Джаве, правильно?

С: Ну, да. Это по сути чистый server-side. Game-dev — это ну, как бы сказать, не game-dev. Это больше отношением имеет, скажем, к визуальным частям. У меня вот исключительно server-side, некоторая часть игровой логики. Все, что касается графики — это не мое.

А: Скажи, а как… Что привело тебя в программирование. Это как-то случайно сложилось, или ты всегда целеустремленно шла к этой области. Как так?

С: Все было достаточно давно и мне всегда нравилась математика, мне всегда было здорово с ней. Вот. А в один прекрасный момент мой старший брат поступил учиться и периодически ко мне приезжал домой и рассказывал, что он там делает.

На тот момент в школе у меня программирование не преподавалось из-за прекрасной белорусской системы образования, тогда у нас была 12-ти летняя система обучения и у нас полностью убрали весь курс по программированию, он тогда раньше был на паскале. Наверняка вы знаете, и слышали. У меня был курс совершенно небольшой — это был урезанный на примере ИнтАла, интерпретатора алгоритмов. Там был такой робот-чертежник, может помните или знаете, а может пробовали. Мне там все нравилось, у меня здорово все получалось.

Когда брат показал — вот, смотри, Света, как можно все это круто делать и по другому! Он мне показал, мне стало интересно. Он оставил мне свои лабораторные работы, уехал обратно учиться. А я начала это все разгребать, разбираться, потом скачала несколько книжек. На текущий момент я понимаю, что книжки, наверное, были ужасные, по Турбо Паскалю, и вот с этого всего и началось. Потом в 11-м выпускном классе, другой преподаватель информатики пришел, рассказали нам про С++, немного показали, как это там что-то делается, и я потихоньку начала во все это сама въезжать, разбираться. В последствии поступила в БГУИР и поняла, что это мое, мне нравится и вот так. С конца 3-го курса начала работать, и по текущей теме работаю программистом.

До этого у меня был проект другой, я работала в другой компании, это была банковская сфера. Я там проработала год и больше туда не хочу.

А: Кровавый энтерпрайз?

С: Да. Это было просто такое посвящение, я видела как не надо делать, и я ни за что больше не пойду в это все кровавое месиво, энтерпрайз. Нет.

А: Но это все равно был ценный опыт, согласись.

С: Это хороший опыт, это полезно, но больше года там оставаться вообще не вариант.

А: Вот я считаю, что любому программисту нужно хотя бы год прожить в кровавом энтерпрайзе, чтобы понять, как не нужно делать.

С: Ну, чтобы было с чем сравнивать, сразу видно на таком контрастном примере, что значит хорошо, а что значит плохо.

А: А вот скажи, пожалуйста, вот такую вещь. Я человек немного далекий от Java, но меня всегда тянет, не то чтоб прямо тянет именно к Java, мне интересна JVM как платформа, потому что под нее создаются различные языки, там библиотек много и говорят, что большинство из них не такие уж и плохие. Вот, допустим, я хочу научиться Java, что бы ты посоветовала, какие книжки почитать, курсы послушать, какую IDE лучше взять и тд?

С: Ну скажем, с чего я начинала свое обучение в Java — это была самостоятельно изученная книжка Брюса Эккеля Философия Java.

А: Четвертое издание на русском? Или какое?

С: На английском. Русский перевод ужасен, лучше его не читать. Вообще книжки по программированию лучше не читать на русском языке, пусть она будет на английском в оригинале. Это мое мнение и я рекомендую его всем — сразу привыкать к оригинальным изданиям, не ждать переводов, не пытаться понять, что же хотел сказать переводчик. Лучше оригинал.

А: Если не ошибаюсь, они в русском переводе последнем… она в переводе в два раза тоньше, чем оригинал.

С: Да там просто пару глав, по-моему, выкинули, поэтому так получилось. Как правило, русскоязычные издания они будут потолще, чем английские, здесь банально выкинули несколько глав.

А: Хорошо, а помимо Эккеля?

С: Помимо Эккеля — статьи, спека, наверное так. Ну можно пойти на какие-нибудь курсы, в какой-нибудь компании. У нас в Минске, в принципе, такие вещи устраиваются и можно пойти на бесплатные курсы, пройти тренинг. Там в усиленном режиме можно многому чему научиться с быстрым feedback-ом. Это очень полезно, потому что самостоятельное обучение — это, конечно, здорово, но намного лучше когда есть какой-то учитель, педагог, который тебе скажет: «Вот тут-то ты не прав!» Желательно, чтобы этот педагог был программистом, а не просто педагогом, который что-нибудь прочитал, выучил, и чтобы сразу били по рукам и говорили: «Вот так вот делать нельзя! Это — хорошо, а это — плохо!»

А: А пишешь ты в IDEA, в Eclipse, в NetBeans?

С: Начинала я писать в Eclipse, потом, год когда была в банковском проекте, работала в IBM-овской штуке Rational Application Developer. Это надстройка, это Eclipse с кучей плагинов платных, при этом там стоит каких-то бешеных денег этот IDE, хотя по сути тут платится только за плагины. И сейчас я пересела на IntelliJ IDEA, где-то год назад, и теперь я не хочу никуда слезать, мне очень нравится эта IDE, приятно с ней работать и не хочется никуда больше. Хотя в принципе я пробовала и NetBeans, пробовала и такую штуку JDeveloper, там еще разные пробовала, чтобы иметь преставление о разных IDE, но IDEA пока лучше всех.

А: Валер, наверняка у тебя есть вопросы?

В: Ну у меня скорее вопросы… Вот по тому что сейчас обсуждалось вопросов нет, потому что я писал немного на Scala для курсов Coursera-ских. Поэтому я тоже попробовал всякого разного, тоже IDE-шек копнул. В общем, остановился остановился на IntelliJ, более того для IntelliJ есть довольно занятный плагин для Эрланга, который постепенно приходит в состояние, когда им можно пользоваться. Поэтому продолжить эту тему какими нибудь вопросами я не могу, скажем так.

С: А подожди, ты же в курсах предполагалось, что будут пользоваться Eclipse-ом с плагином для Scala. Чем тебе не понравился?

В: Смотри, там было два курса, один по Scala, точнее по Functional programming Scala. Я его проходил, потому что мне было просто интересно пощупать Scala, а так я себя не мог запинать. Вот его я проходил на Eclipse. Курс по реактивщине я проходил уже на IntelliJ IDEA, потому что она приятнее в использовании и она тупо быстрее работает. Меньше тормозит, потому что Eclipse умудрялся тормозить даже на моем 8-ми ядерном ноутбуке. Как он это делает!? Я не знаю.

А: Я, кстати, тоже пробовал IDEA втихаря, для Erlang-а правда. Она мне понравилась тем, что она шустренькая, она немного не кошерно выглядит в Линуксе под моим оконным менеджером, под i3. но в целом такое приятное впечатление произвела. Но правда для Erlang она мне не очень понравилась. Я попользовался, посмотрел, не проникся и вернулся обратно на Vim. Но вообще она такая приятная штука. Вообще все Java-разработчики, которых я знаю, в большинстве своем рекомендуют IDEA.

В: Ну, собственною если мы заговорили про реактив курс на Coursera, кто-нибудь здесь кроме меня его еще проходил?

C: Нет.

А: Нет.

В: Ну, в общем, я могу поделиться впечатлениями, мне очень понравился Rx, довольно, во-первых, красиво, во-вторых, удобно.

А: Что такое Rx, я извиняюсь?

В: Rx — это «Reactive Extensions», это такая штука, которую Эрик Мэир в начале сделал для C#. В курсе был использован порт Rx на Scala, ее сделали, если я правильно помню, ребята из Netflix. Хотя я могу ошибаться. Это учитывая, что язык довольно удобен для расширения, я имею в виду Scala, учитывая, что в языке есть for comprehensions и подобные вещи, вот на этих reactive extensions писать довольно удобно. И собственно хочу осудить Akka, потому что очень странно брать язык со статической типизацией, то есть Scala, и потом пытаться на этом языке со статической типизацией лепить динамически типизированные акторы. Зачем? Зачем вообще брать тогда язык со статической типизацией. И я вот знаю, что Света немного с Akka работала, я хотел спросить ее мнение по этому поводу. Ну, не только по поводу типизации, а вообще, как тебе Akka?

С: Год назад я столкнулась с Akka. Я почитала спеку, а почитала несколько книг по Akka и для меня это стало открытием. Потому что это модель акторов, я впервые с этим столкнулась, я разобралась, что это такое, и мне безумно понравилась эта идея. Очень богатая идея, как это реализовано. И в принципе, это все было здорово, это здорово звучало на бумаге. Когда сталкивались с этим в жизни, то возникали некоторые проблемы.

Первая проблема, с которой я столкнулась, вот ты говоришь, действительно типизация. В Scala это в принципе, можно делать, есть такая вещь как case классы и это все выглядит более-менее адекватно. А в Java же приходилось всегда делать проверку на instance of. Это совершенно не хорошо, это плохо, но с этим приходилось как-то жить. И что касалось типизации, то это наверное один из таких вот проблемных вещей. Но, в принципе, я не скажу что прям так уж плохо.

Наибольшая проблема у акторов, что нельзя делать в акторах такие вещи, что у тебя было что-то синхронно, либо блокирующим в акторе. А так или иначе, когда ты работаешь с базой данных у тебя в любом случае есть какие-то блокирующие операции. Я не говорю что там есть асинхронные драйвера к базам данных, но приходится, когда ты пишешь асинхронную обертку над какой-то своей бизнес логикой, это получается не всегда хорошо. Вот и в этом есть некоторые проблемы. Но в принципе, что касается моделей акторов и то, что они выстраиваются в иерархию, и у каждого актора есть свой supervisor, что он упадет и его можно поднять. Эта идея очень богатая и это очень хорошо работает. Более того, они обмениваются сообщениями, ты не привязан ни к какому, скажем, конкретному узлу. Твои акторы могут работать на разных нодах, эти ноды могут быть физически распределены, и это здорово работает, мне нравится эта концепция.

А: Я от себя добавлю пять копеек. Это действительно забавно выглядит, когда ты читаешь книжку по Scala, например Одерски, и там через каждую страницу повторяется идея, что строгая статическая типизация — это очень хорошо, она нас спасет, смотрите, у нас строгая статическая типизация, поэтому у нас в коде нет ошибок. Потом ты открываешь другую книжку, Akka Concurrency, и там с точностью до наоборот — смотрите, как здорово, у нас есть акторы, и у нас поэтому динамическая типизация и мы можем любому актору послать любое сообщение. Это так же классно, как если вы пишете на Ruby. Давайте только мы все покроем тестами. И вообще писать по TDD — напишем тесты, а потом напишем код. И вот эта двоякость мышления — это довольно забавно, особенно с точки зрения стороннего наблюдателя.

И у меня вопрос сразу. Ты, Свет, упомянула проблему написания асинхронной обертки над синхронным кодом. Я правильно говорю?

С: Асинхронной обертки над синхронным кодом, да.

А: А как это в Akka правильно делается? Я, честно говоря, пытался добиться ответа от коллег, которые пишут на Scala у нас, но либо я не понял, либо…

В: Они тоже осуждают Акку.

А: Да, но тем не менее, как это делается? Ты вешаешь актор на какую-то нитку операционной системы или как?

С: Смотри. У нас есть разделяемый ресурс, допустим, ну это как всегда, база данных. К базе данных у нас есть какой-то слой DAO. У вас там наверняка в Erlang он так же называется data access object, data access layer как-то? Вы понимаете, что это такое в любом случае. И дальше, поскольку это разделяемый ресурс, он должен быть потокобезопасным. Если у него нет никакого состояния в данный момент, то все ОК, можно его разделять. Проблема наступает, когда нам нужно какие-нибудь параллельные транзакции выполнять несколькими акторами. И каким образом это происходит — тебе по сути приходится писать какие-то lock-и на какие-то конкретные объекты базы данных, чтобы у нас не получилось списание, скажем, денег с одного счета дважды. Как это легко разрулить? Первый момент это lock-и, но это не есть хорошо. Второй момент, в принципе, легко можно разрулить на уровне роутеров. У Akka есть такое понятие, как роутер и есть понятие как диспетчер. Вы с Akka работали, вы понимаете, что это такое или мне стоит объяснить?

А: Я понимаю о чем ты говоришь, но я думаю, что будет здорово, если ты это объяснишь нашим слушателям, потому что это действительно хорошая вещь. Которой в Erlang, кстати, иногда не хватает.

В: В Erlang это можно самому сделать.

А: Можно, но, Свет, расскажи нам.

С: Хорошо, начнем. Что такое диспетчер? Диспетчер, это такая сущность, которая отвечает за то, каким образом наши акторы будут map-иться на системные потоки. На деспетчере можно повесить, сколько потоков может выполняться, сколько потоков мы выдаем данному актору, сколько времени он будет выполняться, сколько максимум потоков может быть, сколько минимум потоков и, в принципе, под капотом у себя скрывает либо fork join pool — это один деспетчер, либо thread pool executor. Это одна штука и есть и вторая штука.

Вторая сущность это роутер. Роутер — это такая вещь, которая описывает, каким образом будут наши сообщения обрабатываться акторами. Есть несколько типов встроенных уже и написанных роутеров, допустим обычный round robin роутер, который по кругу всем акторам раскидывает сообщения. Есть broadcast роутер, который всем одновременно раскидывает сообщения. Есть прикольная штука, называется consistent hashing router, вообще здоровская вещь. Оно раскидывает сообщения в соответствии с какой-то хэш функцией. Мы эту хэш функцию у себя определяем и у нас сообщения, которые попадают под эту хэш функцию, если единица выходит, то на один и актор, двойка — на другой, и так далее. И таким образом мы можем без lock-ов разделить транзакции. То есть мы через этот роутер разделим таким образом, что все транзакции, которые идут к одной записи в базе данных, скажем, к одному кошельку, они будут попадать в одну и ту же очередь, одного и того же актора. У актора очередь называется mailbox-ом в Akka. Эти mailbox-ы тоже могут быть разными, и они могут быть с ограниченным значением писем в mailbox, могут быть с неограниченным, всякие разные способы есть.

А: А ты не пробовала транзакционную память в своей работе использовать?

С: Пробовала. В Акке есть такая вещь, как STM, software transactional memory, это для тех вещей, когда нам приходится разделять между акторами какое-то изменяющееся состояние.

А: Извини, что я перебиваю. Это прям в Akka есть?

С: Это есть в Акке, да.

А: А давно оно там есть?

С: Достаточно давно. Я не скажу с какого конкретно релиза, надо посмотреть в доках, но по-моему со второй версии есть.

А: Здорово. Ну хорошо, извини, что я перебил, продолжай, пожалуйста.

С: Этим вполне можно пользоваться, и это вполне себе ОК работает. Хотя, когда мы писали тест, у нас была такая штука, писали тест со Scala STM, и написали такую же штуку на Java коллекциях, но с lock-ами. И в принципе получилось тоже самое по производительности. Но сама идея STM, когда разрабатывали Скалу, она была взята из Clojure, если я не ошибаюсь…

A: Clojure появилась позже, на сколько я знаю.

B: Ты уверен, что Clojure появилась позже чем Akka?

А: Нет, не уверен, поэтому я сказал «я так думаю». Скорее всего, эта идея в первую очередь слизана с Хаскеля. Это мне так кажется, но я могу ошибаться на этот счет. Потому что в Хаскеле это, насколько я знаю, одна из первых реализаций, такая более-менее, которая получила распространение. В Хаскеле считается, что все надо делать через STM, и если ты делаешь на mutex-ах, то либо у тебя очень высокая нагрузка и тебе нужно использовать поэтому mutex-ы, либо ты еще не знаешь про STM.

С: А в Erlang есть STM?

А: Есть, но она называется Mnesia :)

С: Ну а поподробнее?

В: Ну там есть встроенная база данных, в которой есть нормальные транзакции. В Erlang чаще всего можно без STM жить.

С: Ну хорошо. А как изменяемые состояния будете хранить?

В: Если очень нужно, то есть Mnesia, но как правило, просто заводят актора, который это состояние менеджит.

С: А если тебе одного актора мало?

В: Несколько акторов и consistent hashing или пул.

А: Смотри, в случае с Mnesia это просто встраиваемая база данных реляционная с транзакциями, которая может быть и in-memory и/или на диске, и она очень навороченная. Там есть репликация, там можно расшардить данные, но это довольно сложно готовить и реально в мире человек 10, которые умеют это правильно готовить.

С: Как я понимаю, это реляционная обычная база данных, да?

В: Она не очень обычная, не очень реляционная, и она не работает как отдельный процесс, она работает прям внутри твоей виртуальной машины.

А: Она скорее как молодая NoSQL.

С: На Erlang тоже написанная наверняка?

А: Наполовину на Erlang, наполовину на Cи.

С: О! Задам тоже вам вопрос. А как у вас такая штука происходит. Допустим, у вас есть актор, и в этом актор есть какое-то состояние. Этот актор падает, а потом вам нужно восстановить это состояние. Как вы это будете делать в Erlang?

В: Варианты, варианты, варианты, в зависимости от конкретной задачи. В Erlang кроме Mnesia есть более легковесная штука, называется ETS, они тоже могут разделяться на несколько процессов, это такая табличка. Это не STM в том смысле, что нельзя сказать, что хочу две ячейки одновременно поменять атомарно, но зато можно… операция по каждому отдельному ключу она атомарная. Эти ETS при падении процесса могут наследоваться другим процессом.

А: Грубо говоря, это хэш-таблица, которую ты можешь отдать другому процессу когда ты умер.

С: Я к тому, что у нас недавно был релиз Akka новый и там появилась такая фича как persistent actor, и там такую штуку сделали. Когда у нас актор падает с неким состоянием, мы можем восстановить это состояние. Почитала каким образом это реализовано. По сути, у актора есть внутреннее хранилище, и в это внутренне хранилище попадают инкрементально какие-то изменения, которые приходят нашему актору. И потом когда супервайзер восстанавливает наш актор, то эти инкрементальные изменения будут накатываться на актор и мы получим наше состояние, которое было до падения. Вот такая штука. Я еще, правда, не трогала, только почитала в новом релизе, но очень хочется попробовать. Интересная штука.

В: Я сходу вижу подводные грабли у такого подхода, потому что этот крэш во многом про то, чтобы сбросить состояние, потому что если мы покрэшились, значит вероятно, что в нашем состоянии что-то было не так. Если мы берем это состояние и просто поднимаем потом обратно…

С: Нет, смотри, там же какая штука. У тебя есть какое-то состояние, получаешь сообщение, и на этом сообщении ты падаешь. Таким образом ты можешь восстановит состояние, которое было до получения твоего сообщения.

В: Это если ты подаешь от сообщения, а не от того, что у тебя предыдущее сообщение привело к состоянию неконсистентному.

А: Ты, Валер, забываешь, что там строгая статическая типизация и чтобы получить неконсистентное состояние, надо очень постораться.

С: Смотри, у тебя же в любом случае есть супервайзер, и ты супервайзеру определяешь функцию, что делать при возникновении той или иной ошибки и в зависимости от типа ошибки ты можешь упасть, можешь перезагрузиться, ты можешь сказать «все ок, работаем дальше», либо сказать «все упало, все плохо, идем на следующий уровень супервайзера».

А: Я должен прервать вашу дискуссию, потому что в воздухе повеяло холиваром. Если хотите, вы можете после выпуска на эту тему пообщаться. А я хочу у Светы другое спросить. Дело в том, что в Erlang мы постоянно используем синхронное хождение из акторов в акторы, gen_server:call. Мне интерсно, а в Akka это как-то решается или всегда нужно делать асинхронную посылку, потом ждать получение ответа асинхронного и тд.

С: Я поняла вопрос, сейчас расскажу. В Акке есть несколько паттернов передачи сообщений, послать сообщение в стиле fire and forget, послал и забыл. Это вот обычная асинхронная отправка. И второй тип, это послать сообщение и ждать респонса. Можно так и так, но в принципе, во всех книжках во всех мануалах рекомендуют использовать в стиле fire and forget. А в другом случае, когда ты хочешь получить ответное сообщение, тебе нужно это делать через future, это по сути уже синхронная обработка данных. Ты должен указать, какое количество времени ты должен ждать ответа и это уже есть синхронная обработка, что ни есть здорово. А Akka заточена на то, чтобы было асинхронно и за счет этого мы выигрываем при подходе с акторами. По сути большую часть времени твое предложение чего-то ждет от пользователей, либо еще какого-то действия. Вместо того, чтобы ждать, можно отдать это процессорное время другим акторам, которые будут в это время что-то обрабатывать. За счет этого мы получаем довольно производительную систему. А когда мы будем в наших акторах писать, что «подожди три секунды ответ от какого-то внешнего сервиса» то всю концепцию мы таким образом крэшим. Я не права?

А: Дело в том, что в Erlang, у тебя…

С: Там каким-то другим образом работают синхронные вызовы?

А: Во-первых, там весь ввод-вывод асинхронный. Во-вторых, у тебя время между акторами распределяется не таким образом, что типа ты вышел из метода, потом вошел в метод другого актора. А у тебя считаются редукции, количество команд виртуальной машины, которые выполнено, и можно посередине твоей функции, метода, грубо говоря, выйти и войти в другой актор. Поэтому у тебя нет такой проблемы, что ты кого-то заблокировал, или типа того. То есть, если тебе нужно поддерживать 10 тысяч пользователей онлайн одновременно, то ты создаешь 10 тысяч акторов и каждый работает со своим пользователем.

В: И каждый может вдоволь блокироваться и он на самом деле ничего не заблокирует. Ты можешь в акторе пойти матрички перемножать. Если он будет слишком долго это делать, его просто прервут, дадут время другому актору, и потом вернет время предыдущему актору. Причем все это проходит внутри одного процесса ОС.

С: Я поняла, просто у нас такая штука есть, я говорила, что есть деспетчер, и всем акторам, которые работают с блокирующими ресурсами, с базы данных, мы должны выделять свой деспетчер, либо свой набор деспетчеров. И в том случае, когда у нас база данных слегла, либо какой-нибудь длинный запрос, как ты говоришь — матрицы пошли перемножаться в базе данных, либо что-то еще подобное. И в таком случае, там деспетчер забрал некоторое число потоков, ну и черт с ними, пускай он забрал. Чтобы другие акторы работали с другими деспетчерами, другими потоками, вот у нас таким образом это решается.

В: В чем проблема с имплементацией акторов в Akka, собственно, почему я обсуждаю Akka, кроме собственно статической и динамической типизации. В Erlang, и кстати говоря в Go и других языках, можно писать код линейно, и поэтому нет необходимости превращать простой линейный алгоритм в какую-то стейт машину сложную. Если мы реализуем какой-нибудь, прости Боже, Paxos, если нам по алгоритму следует подождать ответов от acceptor-ов, притом дождаться кворума, мы можем так и написать: «вот сейчас мы стали колом и ждем кворума». Причем, реально система колом не встанет. И в Go, и в Erlang, и в Scala, используя недавно написанные поверх макросов await async, это можно сделать довольно приятно и это будет выглядеть линейно, почти как код из пейпера по соответствующему алгоритму. В случае с Akka, нужно писать кучу кода вокруг этого, чтобы хотя бы можно было понять. Вот это, на мой взгляд, проблема большая.

С: Смотри, каким образом это будет сделано…

А: Ребят, ребят, я извиняюсь, но мы просто не можем делать двухчасовой выпуск. А Валеру опять понесло в холиварную тему, типа Erlang против Akka.

С: Просто это тоже легко можно реализовать, это не проблема.

В: Я это реализовывал, я понимаю, как это реализовывается, и мы не будем про это холиворить. Я просто к тому, что это требует большего количества кода и мозговых усилий.

А: Раз уж мы заговорили, и начали сравнивать Erlang и Akka, и Java и все такое. Скажи пожалуйста, Свет. Вот в Erlang, то, что мне очень нравится, это два момента. У меня есть работающее приложение, server-side, которое долго живет. И я могу в любой момент к нему подключиться, и посмотреть, что там внутри. Есть интроспекция, я могу понять, чем занимаются процессы, stacktrace-ы их посмотреть. Могу посмотреть, что в очередях сообщений, могу посмотреть, что там в табличках. Это первое, и второе, что в случае крайнего факапа, я, в принципе, могу взять модуль и сделать горячее обновление кода без остановки самого приложения. Есть ли что-то подобное в мире Java в Akka, или как-то по-другому решаются эти проблемы?

С: Ну, хорошо, были проблемы с производительностью, каким образом это вообще все решалось нашим приложением. Для Akka есть хороший тул, называется TypeSafe Console, может быть даже слышали.

Этот тул для разработчиков бесплатный. Когда что-то свое дебажишь, разрабатываешь, все окей, это бесплатно. Если ты хочешь на продакшене это все исследовать, это становится платным. Нужно конкретно ознакомиться с лицензией, я ссылку добавлю в show notes. Эта штука действительно очень здорово работает. Ну, там есть, правда, свои особенности, из-за того, что оно работает только с Protobuf 2.4.1. А у нас было написано приложение на 2.5.0, и вот столкнулись с проблемами. Написала об этом в твиттер, мне разработчики этой TypeSafe Console сказали, вот, мы это все исправим через две недели, ждите. Но прошло уже намного больше, чем две недели.

А: У тебя эта консоль, она взаимодействует с твоим приложением по Protobuf’у?

С: Да, оно взаимодействует с моим приложением, оно как обычное Java приложение запускается java -jar ..., пошел стартовать сервер. И дальше к этому серверу с командной строки мы дописываем свои агенты. И таким образом, у нас Akka консоль стартует вместе с нашим приложением. Плюс там еще дополнительно пара jar-ок стартует для непосредственно самой работы консоли. И все, понеслась, мы можем в виде web-приложения смотреть, сколько к нам в mailbox акторов пришло сообщений, какое максимальное количество сообщений, какая пропускная способность. И всякие метрики, которые очень полезны, и которые помогают понять, в чем же причина, где у нас затык, что у нас тупит. Графики строит, и с этим довольно приятно и удобно работать.

А: А насчет горячего обновления кода?

С: Насчет горячего обновления кода, по-моему, что-то в акторах такое было. Но я не уверена, потому что в Akka есть две установки, Akka как библиотека, и Akka как платформа. В Akka как платформа, ты можешь свои приложения встраивать, и они там будут работать. И насколько я помню, там можно в Акке как платформе такую штуку делать. Я не буду утверждать, что это так и есть, нужно проверить и посмотреть. В любом случае, я руками это своими не пробовала.

В: Ну, кстати, есть еще JRebel.

С: JRebel лучше подходит для разработки. Для тестирования, непосредственно для разработчика, когда ты что-то поменял у себя в коде, и тебе нужно, чтобы оно быстренько перегрузилось на каком-то сервере. Это удобно, когда ты веб разработчик, это отлично работает. Для наших целей это не то, совсем не то. И, в принципе, когда проблемы с сервером, есть такая штука как JMX, и можно подключиться к работающему серверу по JMX-у через VisualVM и посмотреть, что там происходит, какие потоки, что у нас спит, где блочится. И если есть какие-то проблемы с производительностью, можно через VisualVM все расследовать.

A: Ты на работе пишешь на Java, как я понял. А ты интересуешься Scala или Clojure или может быть Kotlin-ом. Что ты думаешь об этих языках?

С: В принципе, смотрю в разные языки, по большей степени я смотрела в Скалу, и какие-то для себя небольшие проектики писала, в основном было для университета что-то. Так, показать, смотрите, эту штуку можно сделать так-то, вот эту штуку можно сделать так-то. Там задача была довольно простая и типичная на MapReduce, посчитать количество слов в абзаце текста, либо в большом тексте. Количество употреблений разных слов. И эту штуку написала на Java, написала это на Scala, написала это на Java с помощью Akka, написала на Scala с помощью Akka. Вот, смотрите, какие разные подходы. И написала это с помощью Hadoop тоже. Вот такие штуки были.

В принципе, очень интересен Erlang, но пока руки не доходят посмотреть это все. Я не исключаю, что как-нибудь возможно в будущем я перейду на Erlang, но пока что не до этого. Но я считаю, что разработчику очень нужно знать и понимать, какие технологии есть, кроме своей актуальной, которые использует разработчик в своей работе. Более того, не только технологии, важно понимать разные подходы и парадигмы программирования. Зная несколько парадигм программирования, это очень хорошо расширяет сознание, и очень полезно для общего кругозора. И свои повседневные задачи можно решать лучше, эффективнее, удобнее. Не замыкаться только на своем, привычном используемом круге технологий.

А: Это золотые слова! Это, кстати, одна из основных причин, почему я всем советую упарываться Хаскелем. Вы, может, его в продакшн и не сможете протащить, но те подходы, то, как вы сломаете себе мозг в хорошем смысле, так многократно окупится, независимо от того, на чем вы будете писать. Только ради этого.

С: В принципе, любой функциональный язык, я считаю, сломает мозг на ура.

В: На самом деле, у меня было два слома мозга, и даже три. Первый слом мозга — была функциональщина вся, притом я начинал со Scheme. Второй слом мозга был акторы эрланговские, и третий слом мозга был Prolog, с тем, что результат может быть вычислен не как результат функции. Любой аргумент может быть результатом. Если у нас есть какой-то предикат, и он может работать в обе стороны, он может… что бы такого быстро привести. Если у вас есть, скажем, два множества, и есть их сумма. То он может как их сумму посчитать, так и по сумме множеств и одному из подмножеств вывести второе множество, например. Это очень сильно взрывает мозг, когда первый раз это видишь.

А: У нас выпуск подходит к концу, и мы сделаем небольшое объявление. Точнее, даже я сделаю. Дело в том, наши слушатели, вы знаете, что это последний выпуск в этом сезоне. И следующий сезон мы, если начнем записывать, то не сразу, а где-то после майских праздников. И у нас есть одна маленькая проблема. Дело в том, что одна из важных составляющих нашего подкаста заключается в том, что у нас есть текстовая расшифровка. Я считаю, что это очень важно, потому что если у подкаста нет текстовой расшифровки, то его один раз слушатели послушали, и все, после этого он мертвым грузом лежит. Потому что поисковые системы не могут индексировать mp3 по-нормальному в данный момент, и никто это никогда не найдет. Это во-первых. И во-вторых, кому-то просто больше нравится читать. Я знаю, что некоторые люди просто читают наш подкаст.

Так в чем заключается проблема? Она заключается в том, что подкасты мы начали делать длинными, вот этот должен быть 40-45 минут. Но лапки у меня начинают отваливаться после 20-25 минут набивания. Поэтому последние выпуски, мы их набивание отдали на outsource. И отдали довольно успешно. Я уверен, что вы не заметили особой разницы, я их писал или не я. Но это стоит денег. Стоит довольно немалых денег, если умножать на год подкаста, два раза в месяц в течение года. И оплатить следующий год подкаста меня немножко душит жаба. Поэтому мы к моменту публикации этого выпуска сделаем небольшую… как это, программа на boomstarter? Или проект?

В: Проект.

А: Проект на бумстартере. И надеемся на вашу помощь, что вы нам дадите денег на следующий сезон подкаста, вот как. Денег нам нужно совсем немного. Если в расчете на одного человека, я тут посидел с калькулятором посчитал. Если каждый слушатель подкаста даст 100-150 рублей, нам этого будет за глаза, мы вам целый год будем делать два раза в месяц вот такой подкаст. Мы надеемся, он вам нравится. Ты, Валер, как считаешь, 150 рублей за год подкаста нашего уровня, это много или мало?

В: Это мало, вообще я очень люблю kickstarter-ы, boomstarter-ы и все такое, регулярно даю денег на каких-то кампаниях. Да, кстати, правильное слово я вспомнил, как называется. Называется «кампания». Через букву «а», как военная кампания. И мне кажется, что не такая это проблема собрать. Но я думаю, что мы даже если не соберем, тоже продолжим это делать, просто мы тогда не обещаем длину выпусков.

А: Ну, или сделаем сезон покороче, то есть выпусков поменьше. Мне тоже кажется что 150 рублей, это не так много. Это, грубо говоря, один раз пива попить один вечер. Так что, мы надеемся на вашу помощь, и на то, что вы поддержите подкаст ретвитом и в социальных сетях прочих, отличных от твиттера. Чтобы мы собрали денег успешно и продолжали для вас делать хороший подкаст. У нас пока вроде все, никто ничего добавить не хочет, нет?

Ну, тогда, мы, наверное, завершаемся, спасибо, что слушали нас, и надеемся услышаться в следующем сезоне. Всем пока!

В: Пока!

С: Счастливо!

Дополнение: EaxCast S02E01 — интервью с Александром Юрченко о работе в Яндексе, проекте OpenBSD и машинном обучении

Метки: EaxCast.