Почему Erlang?

    Оригинал статьи: smyck.net/2012/04/22/why-erlang

    Шансы, что вы читаете эту статью на устройстве с многоядерным процесcором, растут каждый день, вот почему все постоянно говорят про параллелизм (concurrency). Параллелизм для наших web приложений и API бэкендов, это когда вывод htop выглядит примерно как на картинке:

    Concurrente htop

    Я недавно был на великолепной Ruby конференции и три или четыре доклада были про параллелизм. Сообщество Ruby достаточно открыто и обсуждалось достаточно много возможностей: использовать потоки, использовать различные среды выполнения Ruby, чтобы обойти GIL, использовать больше процессоров, использовать модель акторов через библиотеки как Celluloid или даже использовать Akka через JRuby.

    В то время как модель акторов, кажется, хорошо подходит для создания сетевых параллельных приложений, которые часто страдает от проблем, если среда выполнения, на которой реализовано приложение не имеет нативной поддержки. Существуют реализации для Ruby, Python и Java, но все они должны подстраиваться, чтобы достичь нормальной работы и не обязательно результат даёт наилучшую производительность. Это одна из многих причин, почему Erlang был бы намного лучшим выбором, но сначала, давайте немного уделим время модели акторов, чтобы понять, почему это так хорошо работает.



    Модель Акторов


    Вот неплохая цитата из wikipedia, для поверхностного понимания:

    «Модель акторов исходит из такой философии, что всё вокруг является акторами. Это похоже на философию объектно-ориентированного программирования, где всё вокруг является некоторыми объектами, но отличается тем, что в объектно-ориентированном программировании программы, как правило, выполняются последовательно, в то время как в модели акторов вычисления по своей сути совпадают по времени.»


    Несмотря на некоторое сходство между актороми и объектами, такими как: модулярность, инкапсуляция и возможность отправки сообщений; акторы имеют уникальную особенность — они могут выполнять свою работу в одно и тоже время.

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

    Другое большое отличие от мира ООП это то, что модель акторов не имеет глобального состояния и по-этому не разделяют общую память между актороми. В языках, таких как: Java, Ruby и Python всегда используется глобальное состояние и нити имеют доступ к общей памяти. Это обстоятельство часто становится проблемой в виде блокировок или гонок состояний и возможно является наибольшим неудобством

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

    Необходимо так же отметить, что модель акторов очень хорошо подходит для функциональных языков программирования с концепцией неизменяемых данных (Immutable Data).

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

    Хорошо, а что насчёт Erlang?


    Сперва я бы хотел сказать, что много лет я был страстным Ruby разработчиком. Мне действительно очень нравится этот язык и его сообщество. Но время от времени я чувствовал, что преодолеваю невидимые стены, когда дело доходит до сетевых приложений, веб приложений, веб серверов, прокси и т. д. То есть все те приложения, которые обрабатывают множественные запросы и/или выполняют не тривиальные задачи.

    Erlang попал в поле моего зрения достаточно давно, но с высоты моей башни из слоновой кости и рубиновой крышой потребовалось много попыток, чтобы понять, что его стоит попробовать. Концептуально это имеет большое значение для меня и я уверен, что большенство людей читавшие про Erlang, согласятся со мной. Должен признаться, что был потрясён синтаксисом языка и это останавливало меня
    от желания попробовать этот язык. Думаю, это было большой ошибкой, которая и мотивировала меня написать эту статью, сказать вам, что вы должны попробовать Erlang как можно быстрее.

    Сначала позвольте дать описание Erlang в одну строку:

    «Erlang — функциональный язык, реализованный на модели акторов для параллельных приложений.»

    Этот язык был разработан компанией Ericsson для своих телекоммуникационных свитчей и целью было создать язык, который позволил бы разрабатывать отказоустойчивые и параллельные системы с высокой доступностью.

    Вы можете почитать обо всём на wikipedia или великолепном сайте: learnyousomeerlang.com — Эти ребята сделали отличную работу описав язык.

    Практический пример использования Erlang в Wooga


    Эта статья своеобразный толчок, я хочу побудить вас попробовать Erlang и буду стараться делать это рассказывая историю применения Erlang в Wooga.

    Wooga делает социальные игры с миллионами активных игроков в день. Игры постоянно сообщают серверам изменить и удерживать состояние участников игры. Некоторые из наших игр были разработаны на Ruby и они работают неплохо. Ruby, как я уже говорил, действительно хороший язык и хотя не самый быстрый, но он может быть достаточно производительным, если вы знаете что делаете.

    Наша самая большая игра, по числу пользователей, со сложной внутренней логикой, работает на серверах количеством от 80 и до 200. Они обрабатывают около 5000-7000 запросов каждую секунду и почти все запросы изменяют состояние игрока в самой игре. Должен отметить, хотя количество серверов и сохраняется в разумных пределах в момент пиковых нагрузок, но цифра, конечно же, не самая впечатляющая.

    Когда пришло время создать новую игру со схожей логикой и сложностью, на этот раз мой коллега Paolo решил выбрать Erlang, он думал это будет правильным выбором. Мы наняли опытного разработчика на Erlang (Knut) и они вместе реализовали логику. Сейчас эта игра имеет около 50% игроков от остальных игр и количество серверов, необходимых обслуживать её, равно 1!..

    Игра обслуживается двумя или тремя серверами для некоторой избыточности, но она может вполне идеально работать и на одном. Даже если игре действительно потребуется четыре сервера, всё равно это будет намного эффективнее и производительней, чем другие игры.

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

    Говоря другим языком, они создали веб сервер для хранения состояния игроков, это значит, что каждый игрок, который ирает в данный момент, обслуживается отдельным актором внутри Erlang VM. Игрок, начиная игру, порождает актор с его состоянием. Последующие запросы, пока он играет, идут напрямую к актору, с которым он связан. Соответственно, пока состояние игры хранится в памяти, при этом исключаются любые обращения к базе, запросы обрабатываются и отвечают очень быстро.

    Если актор падает, остальные акторы остаются «живыми» так как нет общего / глобального состояния. Когда игрок прекращает игру, актор сохраняет состояние игрока в постоянном хранилище и сборщик мусора (GC) удалит его из памяти. В тоже время, как мы помним, данные в Erlang не изменяются, что позволяет вернуть состояние игрока пока не произошли изменения и не пошло что либо не так.

    Это действительно восхитительно и я могу рассказать намного больше. К счастью, Knut и Paolo рассказывали на нескольких конференциях про наш опыт и выложили свои слайды в открытый доступ. Вы можете просмотреть их по ссылкам:

    * www.slideshare.net/wooga/erlang-factory-sanfran
    * www.slideshare.net/hungryblank/getting-real-with-erlang

    Больше Erlang в Wooga


    После того, как Paolo и Knut заразили вирусом Erlang всю компанию, мы сделали новую игру на Erlang и несколько дополнительных сервисов. Могу подтвердить, что чем больше ты изучаешь Erlang, тем больше понимаешь как делать правильно. Это заставляет меня немного сожалеть о тех, кто на конференциях Ruby боролись с различными библиотеками, чтобы можно было легко разрабатывать параллельные приложения, что обеспечивает Erlang в одном пакете. Пакет, который используется уже более 20 лет.

    Трудная часть в изучении нового языка, это найти небольшой проект и принять в нём участие. Изучать, просто читая книги, всегда медленно и когда приступаешь к написанию кода, большая часть прочитанного забывается. Так же, странный синтаксис (сейчас я не считаю его странным), был для меня непреодолимой преградой, чтобы начать использовать Erlang в реальном проекте. По этому рекомендую выбрать небольшой проект и «поиграться» с Erlang. Думаю вы не пожалеете.

    Надеюсь в скором будущем написать статью как я изучал Erlang и выложить её. Тем временем вы сами можете начать изучение, посетив ресурс learnyousomeerlang.com. Доверьтесь мне — это лучший выбор, чем любые книги по Erlang доступные на данный момент.

    PS: Спасибо Elise Huard за корректуру! Если у вас есть замечания, изображения башен из слоновой кости с рубиновой крышей, чтобы сделать статью более красочной или какие либо пожелания, шлите мне их немедленно!
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 62
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Не спрашивайте — пишите)
      • 0
        Т.е. код на erlang`е в 80-200 раз производительней чем в ruby? Интересно сколько ядер у них на серверах.
        • +2
          И да, и нет — в зависимости от того, что понимать под производительностью. Если количество серверов — да, Erlang более оптимально использует ресурсы сервера как раз для такиз задач. Если просто скорость исполнения линейного кода — совсем нет, в Erlang ужасная производительность операций со строками и математики (особенно с плавающей точкой), а ведь именно последнюю обычно проверяют во всяких бенчмарках,
          • +3
            Если строки хранить в бинарях, а не списках, то скорость вполне на уровне.
            • 0
              Возможно я и не прав, но разработчики поминали некоего парня, который занят (или был занят) оптимизацией математики с точкой в Erlang. И вроде бы как успехи вполне себе приличные.
          • –3
            «Пишлите, Шура! пишлите...» © :)
            • +1
              Ну в целом, учитывая что они фермы клепают, эрланг неплохой выбор.
              А вот как быть с играми, в которых состояние это не банальный набор грядок, а где есть активные действия между игроками в реальном времени, котоые к тому же завязаны на довольно тяжелые расчеты коллизий и прочих вещей?
              Всякие стрелялки и т.д. типа танковонлайн…
              Сдается мне, что эрланг не потянет такое…
              • +4
                Любые сложные расчёты лучше вынести куда либа, например NIF, OCaml, Clojure или что больше нравится. Ничего плохого в этом нет, такова общепринятая практика.
                • 0
                  Вынести то можно… только что тогда останется? просто обработка входящего пакета и отправка его в нормальный сервер, который уже все сделает?
                  Тогда выигрыш будет ничтожным… если вообще будет.
                  • 0
                    Будет-будет. Вы просто не представляете, как удобно обрабатывать подключения пользователей в э-ге. =)
                    • 0
                      Да при чем тут удобство то?
                      Мне в скале тоже просто отлично все обрабатывается)
                      Я про то, что все равно будет 80-200 серверов на чем тяжелом для всех расчетов и 1 (ну или парочка) серверов на эрланге для обработки подключений… и это не ничем не отличается от просто 80-200 серверов орбабатывающих все.
                      Я не вижу тут профита. Разве чтоб можно было шильдик повесить «дезигн бай эрланг».
                      • 0
                        Не, если у вас скала с акторами — почему бы и нет, ваш выбор. Там почти тот же эрланг, плюс-минус.
                        Профит в разделении логики поддержки соединения и бизнес-логики. Наличие фронтенда-роутера, позволяющего держать подвешенными тысячи подключений дает крутые возможности по балансировке нагрузки бэкэндов. Или, например, миграции бэкэндов между машинами «на лету» — повесить клиентов в режим ожидания, снять снапшот бэкэнда, перезапустить его на отдельной машине с повышенными квотами, сообщить клиентам «продолжаем».
                        • 0
                          Не правильно. Можно так же паралельно через акторы обчисливать сложные рассчеты. Актеры — это не столько сетевая технология, как технология распаралеливания. Scala же и ее akka полный аналог актеров Erlang.
                          • 0
                            Что неправильно-то? Речь не про акторы в целом, у себя в скале, я на них отлично все что надо считаю, а про конкретно скорость расчетов на эрланге… все что читал про него, говорит что с математикой там все плохо в плане производительности.
                            • 0
                              Так подключаешь Сишную либу для узкого места, паралелится все так же через актеры, считается быстрее, зачем 80-100 серверов?

                      • +1
                        Емнип, ребята из Echo (JS-Kit) примерно так и делают — сервер на Erlang, бизнес-логика на Haskel (или на Scala, точно не помню, но на чем-то расово-функциональном), фронтэнд на JS.
                        • +1
                          OCaml у них в качестве бэкэнда. Но, вообще, целый зоопарк. И чуть-чуть C, и Clojure.
                          • 0
                            OCaml кстати очень хорош, скомпиленный по скорости так и языкам более низкого уровня не особо уступает. Жаль, что он не особо популярен.
                    • 0
                      Вот презентация про MMOG — www.erlang-factory.com/upload/presentations/297/PikkoServerErlangconference.pdf. Там есть неосвещенные моменты, но идея интересная.
                      Алсо, танки и прочее, назовем это instance-based, пишется по-другому. Если хочется эрланг — на нем пишется фронтенд, обрабатывающий пользовательские подключения и лобби, и управление бэкэндами, отдельные игры обсчитываются бэкэндами на других языках.
                      • 0
                        Ха, прикольно. У дураков мысли сходятся))
                        Один в один мой сервак на Scala+Akka… прямо дежавю при чтении.
                        • 0
                          О, а как вы решали вопрос взаимодействия игроков на разных Mast, выражаясь терминологией этой презентации?
                          Упрощенный пример: игрок с одного mast стреляет в игрока с соседнего mast, который в рейнжде оружия первого.
                          • 0
                            Этот вопрос решен так, что сервер пока делается для конкретной игры, она сессионная.))
                            Т.е. запускается карта, на ней воюют игроки. Игрок понятия не имеет на каком он сервере.
                            При старте боя, игроки объединяются на одном сервере, чтобы все задержки свести к минимуму.
                            Это процесс настраиваемый и происходит динамически.
                            При этом механизмы миграции игроков и серверов, очень похожи на описываемые в презентации.
                            Но заданный вами вопрос интересен и он будет прорабатываться…
                            Если это интересно, можно будет статейку написать по результатам. Чего удалось добиться и как это все работает.
                    • 0
                      Сравнение с Akka непонятно. Говорится о интеграции, но при этом ничего не говорится о интеграции с Erlang.
                      Мне нравится Erlang, но какое-то одностороннее сравнение получилось.
                      • +6
                        В результате беглого знакомства с Erlang был больше всего впечатлён узкой специализацией его Garbage Collector и связанными с этим трюками, благодаря которой зачастую реально выполнить с ним soft real-time требования. Но с уменьшением количества ядер эффективность Erlang падает заметно, типичный пример очень хорошего инструмента для очень узкого класса задач.
                        • 0
                          Так никто и не позиционирует его, как серебрянную пулю.
                          • +3
                            Как это никто? Вся статья о том, как люди выбрали эрланг, выкинули нафиг 200 серверов и оставили 2.
                            Сплошные положительные эмоции, ни слова о недостатках…
                            • 0
                              Один сервер, 3 резервных. Одноядерных серверов сейчас уже и не найти. Многопоточность на лицо, по-моему.
                              • 0
                                По личным ощущениям Erlang начинает проявлять себя во всей красе начиная ядер с 8.
                              • 0
                                У них задача как раз для erlang-а, потому такой эффект. Про серебряную пулю ни слова.
                              • +1
                                В любом посте про бекенды на не ерланге, появляется ерлангер и пишет, что автор ничего не умеет, надо было на э-г. Потом появляюсь я и говорю, что «В любом посте про бекенды на не ерланге, появляется ерлангер и пишет, что автор ничего не умеет, надо было на э-г. Потом появляюсь я и говорю, что...»
                              • 0
                                Даже на однопоточной VM прекрасно живут десятки и сотни тысяч процессов. С эффективностью все ок.
                                • 0
                                  «всё ок» в том смысле, что она не падает до уровня интерпретируемых языков? О да. Но и только. Не так давно тестировал Erlang/Cowboy в рамках экспериментов с веб серверами — на 8 ядрах было топовым решением с однозначно лучшим latency. На 2х в серединке и вся стабильность latency сошла на нет. То есть уже ничем не лучше любого другого умеренно адекватного решения.
                                  • +1
                                    Есть еще скорость разработки, простота поддержки, и тп. Если 2х ядер не хватает выгребать тестовый поток, то чуда, конечно, не случится.
                                    • 0
                                      А в этих областях Erlang ничем не примечателен.
                                      2х ядер хватало для нативно компилируемых языков, речь идёт именно о том, что management overhead окружения заметно сказывается в таких условиях, пока вся сила системы многозадачности ещё не проявляется.
                                      • 0
                                        Не удивительно. Любой опытный эрлангист может долго перечислять области и ситуации в которых Erlang ничем не примечателен, и ещё дольше те, где он вообще аутсайдер :)

                                        Это, правда, совсем не мешает им ругаться и крутить пальцем у виска, когда кто-то не использует erlang (или модель акторов вообще) там, где он примечателен или станет примечателен в будущем при горизонтальном масштабировании.
                                        • 0
                                          Не очень большой оверхед, если честно. Если брать те же веб-сервера, на Erlang'е можно выкатить цельное решение, которое будет себя вести вполне прилично даже при скромном ресурсопотреблении. Оно быстро напишется, его будет удобно деплоить, обслуживать и развивать, ИМХО, годная овчинка, полезная в реальной жизни.
                                          • 0
                                            По личным впечатлениям — быстрее питона. Но в питоне, в то же время, больше библиотек, написанных на C.
                                  • +2
                                    Ерланг хорош исключительно для сетевых приложений, все что работает с сетью пишется на ерланге за милую душу. Работа с пакетами вообще выше всяких похвал.
                                    Проблема в том что в остальном он не так хорош. Он не такой быстрый и проводить в нем тяжелые мат. расчеты это откровенная лажа. Он очень плохо работает с текстом, особенно с кодировками. В какойто новой версии это вроде бы обещали исправить(больше к сожалению об этом не слишал). На нем не очень удобно писать логику, так как ее приходится ломать под функциональный язык, на котором человек не думает.
                                    Так же я общался с некоторыми дедами ерланга которые расказывали что в больших проектах не все так гладко как хотелось.

                                    Так что увы Ерланг тоже не серебрянная пуля, хотя и заслуживает того что бы его знать и использовать под нишевые задачи.
                                    • 0
                                      А вот координировать тяжелые вычисления — в самый раз.
                                      • +2
                                        Пришел и написал, все то, что уже написали выше, смысл таких комментов?

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

                                        Логику на нем нормально писать, не надо себя проецировать на всех людей, человек прекрасно думает в терминах функционального языка, даже лучше императивного. Более того, так как язык полностью immutable о коде можно вести разумные рассуждения, потому что он предсказуем.
                                        • 0
                                          Логику нормально писать на любом production-языке. Проблема в том, что разные языки предоставляют разной степени выразительности различные парадигмы для выражения и структуризации бизнес-логики, и _каждая_ парадигма сильно ограничивает возможности. За это любят пайтон и руби — они весьма выразительны и мультипарадигменны, что позволяет лаконично делать то, что удобнее программисту, а не компилятору/интерпретару языка программирования.

                                          В этом смысле эрланг очень сильно ограничивает возможности и заставляет усложнять логику, просто из-за ограниченности парадигмы чистого функционального программирования.
                                          • +1
                                            из-за ограниченности парадигмы чистого функционального программирования

                                            Erlang — не чисто функциональный язык, в отличие, например, от Haskell. Да и функциональная парадигма, при небольшой привычке, часто порождает более естественную, ясную и тестируемую логику.
                                            • 0
                                              Скажу в терминах математики. Допустим логика человека это А, лоигака программы это Б, Ф это отображение А в Б.
                                              Функциональный язык имеет довольно сложную фукцию Ф, в то время как императивне имеют более простую. Именно по этой причине сложно писать логику. Второй момент который видимо забывают это то что логику в играх пишут не девы а геймдевы. А они от языков крайни далеки, а особенно от функциональных.
                                              К примеру World Of Tanks крутиться на Сишном двигле, но игровая логика написана на пайтоне, что бы упростить жизнь геймдевам.

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

                                              Простота тестируемости о которой выговорит вообще не связана с простотой логики… просто в функ. языках отловить ошибку крайне просто ввиду мат описуемости языка. В ерланге к примеру есть тулза которая строит график логики приложения. В императивных языках такое можно получить только через страшные костыли.
                                              • +1
                                                Ну видно, что ты не в теме, но зачем глупости такие писать?
                                              • 0
                                                С чего это Erlang не чистый функциональный язык? :). В нем даже переменных нету в отличие от того же Haskell, нету ООП и процедурщины. Вполне себе чистый функциональный язык.

                                                По поводу выразительности, берем Elixir и получаем язык похожий на Ruby. Да и очень спорно, что Erlang не выразительный, как и любой функциональный язык — он вполне себе выразительный.
                                                • 0
                                                  Вообще говоря у акторов может быть shared state, что сразу делает язык не «чисто функциональным».

                                                  Относительно Elixir'а вы несколько загнули — это скорее загибающаяся на сегодняшний день штука для тех, кому трудно освоить синтаксис эрланга.
                                                  • 0
                                                    Мы про язык говорим, а вы о технологии. Точно так же многие делают ошибку, утверждая, что Haskell поддерживает монады, а язык Х нет, так как это всего лишь концепция, которую просто сделали частью языка.
                                                  • 0
                                                    С чего это Erlang не чистый функциональный язык?
                                                    В нем даже переменных нету

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

                                                    Сравните с Haskell, где работа, к примеру, с файлом невозможна из функции, не имеющей IO монады в сигнатуре (есть, конечно, unsafePerformIO, но он нужен лишь в крайних ситуациях, в основном для вызова чистых по сути функций через FFI).

                                                    По поводу выразительности… Мне Erlang не кажется сильно выразительным языком. Часть «выразительности» ему придаётся стандартной стратегией обработки ошибок: падаем и откатываемся на предыдущее состояние (или эскалируем падение). Это отбрасывает довольно много проверочного кода, необходимого в других языках. Ну и сопоставление с образцом весьма облегчает жизнь.

                                                    Мне лично по выразительности больше нравится Scala. К сожалению, она гораздо сложнее Erlang и перегружена семантикой.
                                                    • 0
                                                      Насчет Scala согласен. Сейчас макросы добавили, так там вообще черт ногу сломит. :)
                                                      • 0
                                                        Как же хочется с вами двумя поспорить.

                                                        И в плане перегруженности (сравнивая с котлином, C# и Java).

                                                        И про сложность макросов. Если немного разобраться они крайне просты в использовании ибо метапрограммирование средствами самого языка. Они уж точно проще того, что было раньше (вроде shapeless).
                                          • 0
                                            Его можно использовать на одном сервере в паре с другим языком? Например прослойка на Erlang которая для вычисления передает все в какую то часть написанную, скажем, на Python/Ruby/PHP?
                                          • +4
                                            Go точно так же подходит под аргументы статьи — язык изначально заточен под удобную параллелизацию, и есть удобная синхронизация между серверами. И, да, не приходится насиловать бизнес-логику дополнительным разбиением на 100500 функций, потому что immutable переменные и прочие ограничения.
                                            • 0
                                              Абсолютно верное замечание.
                                              • 0
                                                Как я понимаю, ничего похожего на OTP и supervision tree там в комплекте не идёт? На самом деле крайне важная вещь.
                                                • 0
                                                  Нет, не идёт. Стандартная библиотека выглядит неплохо, но супервизоров при необходимости нужно реализовывать самим. Кстати, мне кажется, в Go это сделать «правильно» под конкретную задачу с использованием горутин и каналов несколько проще, чем было бы в Erlang на spawn_link, не будь стандартных поведений.
                                                  По удобству супервизоров, конечно, Erlang впереди.
                                              • –1
                                                Говоря другим языком, они создали веб сервер для хранения состояния игроков, это значит, что каждый игрок, который ирает в данный момент, обслуживается отдельным актором внутри Erlang VM

                                                Решение проблемы фактически архитектурное. И аналогичный «актор», написанный на любом другом языке дал бы такой же прирост производительности.
                                                • +1
                                                  Т.о. берем EventMachine и делаем акторов?
                                                • +2
                                                  вот почему все постоянно говорят про параллелизм (concurrency)
                                                  Не стоило переводить concurrency как «параллелизм» (parallelism). Это совершенно разные, хоть и связанные, концепции: Rob Pike: Concurrency Is Not Parallelism

                                                  Эрланг хорош не только и не столько встроенной поддержкой акторов, а ещё и наличием отличных примитивов для построения сложных отказоустойчивых систем, «поведений» (behaviours); серверов, обработчиков событий, супервизоров, приложений. Без OTP Erlang был бы совсем не так интересен.
                                                  И, конечно, нужно упомянуть практическую возможность горячей замены кода.
                                                  • 0
                                                    Да, кстати, Erlang, как язык звезд с неба не хватает, зато технология отличная.

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое