9 февраля 2009 в 17:36

Erlang в Рисоваське, часть 1 — обзор языка

В этой и последующих статьях (часть 2) я хочу рассказать про язык программирования Erlang/Эрланг, его использование в нашем проекте Рисоваська, а также какие приложения и готовые модули (большинство которых тоже написаны на Эрланге) мы использовали в серверной части.

Поискав на Хабре по теме Erlang/Эрланг, понял, что тема освещена мало, есть всего пара действительно хороших статей на тему языка (например, отличная статья от создателя языка в переводе alex_blank What's all this fuss about Erlang? написанная понятным, доходчивым языком). Именно поэтому хочется остановиться сначала на самом языке и его отличиях от традиционных языков.

Виртуальная машина и ноды


Для начала хочется пояснить, что программы, написанные на Эрланге выполняются только внутри виртуальной машины, которая в терминах Эрланга называется нода (node). Есть версии виртуальной машины (или Erlang/OTP) под большинство операционных систем (Windows, Linux, Mac OS, FreeBSD, читал, что Эрланг запустили даже на iPhone). Так как ее исходники на C открыты, то компиляция под любую операционную систему не представляет проблем. На одном компьютере может быть запущено несколько нод, хотя это нужно редко. Каждая нода должна иметь свое уникальное имя, чтобы коммуницировать с другими нодами на других компьютерах сети. Если взаимодействие с другими нодами в сети не предполагается, то нода может не иметь имени. Имя ноды имеет следующий формат: «имя @ IP или название компьютера». Например, пример для локальной сети: test@192.168.0.101. Существует так же и свой компилятор эрланговских программ в родной код процессора: HiPE (high-performance native code compiler). Он входит в состав Erlang/OTP. Самое большое ускорение HiPE дает при работе с бинарными данными (почти десятикратное) и с плавающей арифметикой (foating point arithmetic), в остальных случаях прирост скорости незначительный.

Переменные, значения которым можно присвоить только один раз


Что же такого прикольного есть в Эрланге, чего нет в других языках и что так ломает мозг программистам на традиционных языках программирования (С, Delphi, Basic и т.д.)?

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

Рекурсия


А как же мне реализовывать, например цикл, если значение переменной менять нельзя? Рекурсией! Вот простейший пример на Эрланге возведения в степень N числа X:

raising(1, _X, Result) ->
Result;
raising(N, X, Result) ->
raising(N-1, X, Result*X).


Компактно и красиво. Например raising(3, 10, 10) вернет 1000. Кстати, можете написать и raising(2000, 2, 2). Увидите очень большое число, но вычисления выполнятся без проблем. Тут скрыто еще одно интересное свойство Эрланга: он не имеет строгой типизации переменных, но об этом позже.

Рекурсия – это же плохо, скажете вы! Но не в Эрланге, если рекурсия написана, как хвостовая рекурсия (tail recursion), то есть, когда после вызова функцией самой себя больше ничего не выполняется. Пример выше, как раз пример хвостовой рекурсии: после raising(N-1, X, Amount*X) ничего нет. И тогда виртуальной машине не нужно запоминать вызовы функции в стеке. Она их сразу забывает, поэтому это работает очень быстро и нет ограничения на число вложенностей.

Процессы


Все что выполняется на ноде, является либо отдельным процессом, либо частью другого процесса. Процессы могут порождать другие процессы и следить друг за другом. Каждый процесс имеет свой уникальный номер, называемый PID. Причем, что очень важно, PID уникален не только на одной ноде, но и на всех нодах в сети! Свой собственный PID процесс может узнать вызвав функцию self(). Вот пример запуска нашей функции в качестве отдельного процесс:

Pid = spawn(?MODULE, raising, [3, 10, 10]).

Любому процессу помимо PID можно дать уникальное имя:

register(unique_name, Pid).

После этого к такому процессу удобно обращаться по имени с любой ноды в сети, не зная его PID.

Опять же может возникнуть вопрос, что работает все это медленно. Ну уж нет! Во-первых, процессы в Эрланге не имеют никакого отношения к процессам операционной системы (у Эрланга свой планировщик процессов). На обычной средней машине простые процессы запускаются примерно со скоростью 350.000 в секунду. Может быть процессы отъедают много памяти? Совсем не много: от 4кб на простейший процесс. К тому же процессы можно усыплять (hibernating) сразу после запуска, тогда можно сократить размер памяти вообще до 1кб на один процесс.

Чтобы взаимодействовать между собой, процессы могут посылать сообщения друг другу:

Pid ! {self(), hi}.

Причем, синтаксис не меняется от того посылаешь ли сообщение процессу на той же самой ноде или на другом компьютере сети!

А вот так сообщения принимаются процессом:

receive
{Pid, hi} ->
Pid ! hello;
OtherMessage ->
Io:format(“I received some strange message: ~p~n”, [OtherMessage])
end.


Согласитесь, код отправки и приема сообщений очень компактен. В примере выше, процесс будет ждать вечно, пока не получит сообщение. Можно этого избежать, добавив в конструкцию receive блок “after N”, где N- количество миллисекунд ожидания получения сообщения.

Главные особенности


Вкратце в Эрланге:
  • Создание и разрушение процессов очень быстрое.
  • Передача сообщений между процессами очень быстрая.
  • Вы можете запустить очень много процессов (на практике запускали 20 миллионов процессов на одной ноде, в теории до 120 миллионов).
  • Процессы ничего не разделяют между собой и полностью независимы.
  • Главный способ взаимодействия между процессами: послать сообщение.

А вот и хорошая статья описывающая создание comet-сервера обслуживающего один миллион одновременных коннектов на Эрланге: http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3/ (статья состоит из трех частей). На Эрланге такая задача решается достаточно легко.

Типы


Любой переменной в Эрланге можно присвоить значение любого типа. Но так же можно и проверить какого типа значение в данной переменной, используя встроенные функции (is_integer, is_binary и т.д.). Обычно отсутствие строгой типизации в языке считается недостатком, но на практике я убедился, что чаще это преимущество и сильно повышает гибкость программы. К тому же, чтобы избежать потенциальных ошибок с типами, в состав Эрланга входит статический анализатор Dialyzer, выявляющий такого рода ошибки.

Супервизоры


А теперь перейдем к по-настоящему интересным свойствам среды разработки Erlang/OTP. Программы, написанные в Эрланге считаются обычно не просто надежными, а сверхнадежными. Как же это получается? Все просто. Все приложение написанное на Эрланге, упрощенно говоря, делится на супервизоры (supervisor – специальный процесс наблюдающий за дочерними процессами) и рабочие процессы, выполняющие основную работу. Более подробно вы можете почитать об этом в OTP Design Principles. Есть даже такое смешное понятие в Эрланге: «дай процессу умереть». И это действительно так. Если процесс находиться под супервизором, то в случае своего падения, он будет перезапущен супервизором. Вообще у супервизора можно гибко настраивать его поведение в случае падения дочернего процесса. Например, он может в такой ситуации остановить все дочерние процессы и запустить их все заново. Это нужно в ситуации, когда дочерние процессы, как-либо зависят друг от друга и падение одного, может привести к неработоспособности остальных.

Таким образом программа построенная на принципах OTP будет выглядеть в виде дерева процессов:
Дерево процессов
Рисунок взят из OTP Design Principles

Учитывая, что супервизоры не выполняют никаких вычислений, а только наблюдают, то вероятность их падения стремиться к нулю. Конечно же может упасть вся нода целиком, например из-за нехватки памяти, но и тут есть решение: можно запустить специальный процесс операционной системы, наблюдающий за нодой и перезапускающий ее через определенное время. Есть и другой вариант: распределенные приложения (Distributed Applications) – это такие приложения которые могут работать на нескольких нодах. Причем в один момент времени, приложение работает только на одной ноде. В случае падения ноды, на которой работает такое приложение, оно автоматически перезапускается на следующей ноде в списке. Список нод, где может работать распределенное приложение можно менять динамически в процессе работы.

Работа с бинарными данными


У Эрланга действительно быстрая работа с бинарными данными (особенно в связке с HiPE), поэтому на нем очень естественно писать обработку входных бинарных данных, вплоть до работы с отдельными битами. Тут в сравнении с Java 6 Эрланг выигрывает в несколько раз по скорости работы.

Недостатки


Статья была бы не полной, если не сказать и о основных недостатках Эрланга:
  • отсутствие поддержки Unicode строк (всеми избитый недостаток языка, правда уже этой весной обещают добавить их поддержку в Erlang R13B; ждем),
  • медленная математика, писать на нем какие-то серъезные математические расчеты неэффективно,
  • небольшое кол-во дополнительных библиотек (хотя все самое необходимое присутствует и число библиотек постоянно растет все же еще далеко до такого разнообразия, как в .NET или C),
  • отсутствие отлаженной и быстрой графической библиотеки, поэтому писать клиенские приложения на Ерланге я бы не стал (конечно есть, например, wxErlang, но библиотека еще далека до завершения).

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

Продолжение следует


На этом я пожалуй закончу первую статью, она и так уже получается достаточно большая. В следующих статьях я расскажу про использование распределенной базы Mnesia (которая входит в Erlang/OTP), использование Amazon S3 и Amazon EC2.

Пишите, плз, в комментариях к этой статье, о каких особенностях языка хотелось бы узнать более подробно.

Продолжение цикла статей — часть 2.
Анатолий Востряков @vostryakov
карма
98,0
рейтинг 0,0
Похожие публикации
Самое читаемое Разработка

Комментарии (68)

  • +1
    Толик, спасибо огромное за статью!

    Надеюсь, что теории уже скоро будет достаточно для того, чтобы показать как именно Erlang работает на серверах Рисоваськи.
  • +3
    отличное начало. жду продолжения.
    • +1
      Спасибо! Продолжение обязательно будет!
  • +6
    Программу не разу не видел, говорят не плохая, но название… меня оно жутко бесит:) Но это конечно мои проблемы.
    Так держать, молодцы!
    • +2
      аналогично… тяжело себе представляю, как сказать серьезному заказчику «давайте в рисоваське это обсудим»
      • 0
        Смотря какой заказчик. Если это дизайнерское бюро, то вполне можно порисовать с будущим работником в рисоваське при приеме на работу или посмотреть, как рисует фрилансер. Наши знакомые именно так и хотят ее использовать :)
        Все же Рисоваська в данный момент не является заменой традиционных IM: ICQ, Jabber, Skype. Но мы планируем интеграцию, в первую очередь с Jabber.
        • 0
          Скорее вам стоит предусмотреть работу по XMPP и дать возможность использовать сторонние jabber-аккаунты.
          • 0
            Думаем в этом направлении. В каком-то виде обязательно будем делать. Но мы не собираемся конкурировать с традиционными текстовыми IM-клиентами. Наша особенность — именно рисование и это останется главным. А текстовое общение будет — как дополнительная особенность.
    • 0
      Спасибо :) Ниже комментарий писал тоже тебе, но по неопытности написал не туда :)
  • 0
    Спасибо!
  • 0
    Замечательная статья! Чувствуется, что вы разбираетесь в Erlang. Очень простым языком объясняете. Заинтриговали вы меня Эрлангом :) интересный язык
    • 0
      Сам очень доволен языком, поэтому так и пишу :) А начал я его изучать всего-то в июле. Он действительно простой и быстро входишь в дело.
      • 0
        Если начали изучать в июле, то сколько писали Рисоваську по времени? o_O
        • 0
          Я немного ошибся, мы начали выбирать язык для сервера в июне и с середины июня уже начали изучать Эрланг. А сервер Рисоваськи в целом закончили за 4,5 месяца.
          • 0
            Шустро вы. А сколько человек работало, в каком темпе и каковы были познания остальных членов команды?
            • 0
              Работало двое. Мои познания в серверном программировании невелики. Дима же, является большим экспертом и архитектором серверных решений. Собственно он и выбрал Эрланг. Работали в обычном темпе, по 8-10 часов, то есть не по 12 часов каждые сутки :) В этом смысле сам Эрланг позволяет писать серверные решения действительно быстро.
              • 0
                Т.е. Дима erlang уже знал или просто знал интуитивно, что лучше начать писать сервернуя часть на erlang'е и вы оба с нуля начали изучать его?
                • 0
                  Скорее второе. Мы оба изучали с нуля Эрланг.
                  • 0
                    Похвально. :)
                    А сервер на erlang — имеется ввиду только сервер для обслуживания клиентских апликаций или web часть в том числе?
                    Может Вы бы могли коротко написать об архитектуре (конфигурация компа/компов, что на чем написано) и о текущей нагрузке?
                    • 0
                      Это только application server. Я буду писать в следующих статьях о внутреннем устройстве. Скорее всего через одну статью, так как следующую пишу исключительно про Амазон.
  • 0
    >Пишите, плз, в комментариях к этой статье, о каких особенностях языка хотелось бы узнать более подробно.
    OTP Design Principles ;)
    • 0
      Хорошо, я постараюсь написать более подробно про это в следующей статье. Пока можешь почитать по приведенной ссылке документацию Эрланга, там достаточно понятно все написано.
      • 0
        Ну я эрланг ещё давным давно изучил и успел забросить :) Тогда документация была только официальная и больше всего нехватало внятного описания OTP с реальными примерами. Приходилось копать мэйллисты итп, но когда наконец дошли до меня все прелести otp, остальное изучение пошло гораздо проще.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          А это кто/что?
    • 0
      Насколько позволял размер статья более подробно про OTP Design Principles написал во второй статье:
      habrahabr.ru/blogs/erlang/51796/
  • 0
    Оч. уважаю erlang за его подход к процессам и параллельности. Кстати, помоему erlang использует не только лёгкие процессы но и системные трэды, не так ли? Иначе ОС не даст одному трэду два ядра сразу.
    А, я как раз работаю над проектом (just for fun and aducation) по созданию Scheme VM, и я планирую перенять многие плюсы эрланга, так что у меня тоже будет свой OTP с блэкджэком и шлюхами :)
    • 0
      Если Erlang и использует системные трэды, то это происходит глубоко внутри виртуальной машины и самих программ на Эрланге не касается, то есть эрланговский код от этого никак не меняется сколько бы ядер не было в процессоре. К сожалению про внутреннее устройство виртуальной машины я имею только поверхностное представление.
      Удачи вам в создании своей VM!
    • 0
      OTP это не только ценный мех^W^W лёгкие процессы, но и 100-150 мегабайт библиотек, облегчающих разработку проектов.
    • 0
      эрланг запускает планировщик в отдельном ОС трэде на каждое ядро процессора(если конечно не задавать число планировщиков вручную)
  • 0
    Спасибо, интересно, тем более, что сам сейчас понемногу ковыряю его для небольшого серверного приложения.

    Было бы интересно взглянуть на работу с сетью.
    • 0
      В следующей статье напишу про mochiweb — легковесный браузер написанные на Эрланге, который мы применяли для своей системы.
  • 0
    Я бы еще упомянул про CEAN (по аналогии с перловым CPAN — Comprehensive Erlang Archive Network).
    Там как раз и находятся те библиотеки, которых меньше чем в .NET и Си, но в принципе хватит для многих прикладных нужд. Также имеется одноименный модуль — аналог CPAN.pm, rubygems и подобных.
    • 0
      В следующих статьях хотелось бы увидеть портирование какого-нибудь, необязательно сложного, сетевого приложения с любого другого языка. Ну и больше про паттерны поведения OTP (gen_fsm, gen_server), примеры их использования и т.п.
      • 0
        Да, буду писать про OTP в следующей статье. А вот про пример портирования несложного приложения с другого языка, пока ничего написать не смогу, так как пока у меня такого опыта нет. Мы свою систему писали с нуля сразу на Эрланге.
      • 0
        А смысл портирования? Все равно если мы хотим какой-то алгоритм реализовать и на эрланге, то писать код приложения реализующего его придется все равно с нуля.
        • +1
          смысл в том, чтобы показать реализацию одного и тогоже алгоритма разными парадигмами программирования.

          поскольку стиль эрланга, как я понимаю, шибко отличается от стиля алголо-подобных языков
          • 0
            Пока я пас по этой теме. Нет опыта написания серверов на нескольких языках. Пока я пишу сервер только на Эрланге. Но как будущую тему для статьи буду иметь ввиду :)
        • 0
          Ну почему же с нуля? Я предполагал портирование с эффективным использованием особенностей Эрланга (с применением OTP библиотек, например). Чтобы четко обозначить сравнительные преимущества/недостатки.
      • 0
        Насколько позволял размер статья более подробно про OTP Design Principles написал во второй статье:
        habrahabr.ru/blogs/erlang/51796/
        Буду еще писать дальше в следующих статьях пример сетевого приложения на Эрланге, но без примера портирования, так в этом не специалист.
    • 0
      Спасибо за наводку. Изучаю, что там есть интересного. Нашел там одну библиотеку для работы с JPEG и PNG. Прикольно, может пригодиться :)
  • 0
    Очень рад, что таки и на хабре появляется больше материалов по данному языку.

    Пару соображений по статье. Мне кажется в пример spawn-а не стоило включать макрос. На сколько помню для приема сигналов что бы процесс жил долго нужно делать рекурсию, а из контекста примера это не очень очевидно. Разве нет?

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

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

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

    P.S. По utf-у кстати в официальной рассылке проскальзыл пост в котором человек писал, что написал модуль работы с utf и Мамут даже испросил этот модуль, но чем все это в итоге закончилось не ясно. Кстати там же предлогали как вариант просто выдернуть кусок кода из функций работы с XML.
    • 0
      Спасибо!

      Да, согласен пример со spawn можно было сделать попроще. Но чтобы процесс жил долго можно просто в нем написать receive something -> ok end. и он будет вечно ждать получения сообщения для него :) То есть рекурсия не обязательна.

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

      Про Амазон замечания учту: напишу и организационную сторону. Про клиент серверное взаимодействие тоже планирую писать в следующих статьях. С примерами насколько позволит размер статьи.

      А с UTF в Эрланге пока глухо, бибилиотеки для нормальной работы с ними написанной на самом же Эрланге я не нашел. Мы лично используем Starling — но он использует библиотеки на C. Нам нужно было преобразование в Upper Case. Конечно просто чтение UTF-строк в эрланге есть, но вот работы с полученными данными потом отсутствует.
    • 0
      Написал статью про Амазоновские сервисы, в том числи и про оплату:
      habrahabr.ru/blogs/hosting/55058/
  • 0
    спасибо.
    очень интересно былобы узнать о новом языке именно на живом примере.
    изучать по мануалам одного любопытства не хватает :)

    переменные отсутствуют также и в достаточно популярном питоне.
    там используется связывание имён с объектами (сами объекты, правда, вполне модифицируемые.)
    обычно называется передача аргументов по ссылке. только тут присваивание по ссылке.
    но вот пока я не увидел именно формулировку «связывание имён с объектами», оставались недопонятыми и scheme, и xslt :)

    при объяснении этой особенности стоит как-то пояснить смысл происходящего.
    потомучто для алгол-ориентированных программистов (на которых нас всех учили в школе) переменная — это и есть объект, и если он не изменяем, то вообще ничего не изменяемо.

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

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

    если же все функции без побочных эффектов, то лишено смысла также и скрытое goto в виде последовательного выполнения действий (поскольку результат предыдущего действия не используется). это тоже может немного поломать мозг привыкшим мыслить progn-конструкциями.
    • 0
      эрланг — строго функциональный язык. переменных там нет, там есть лишь промежуточные именованные данные.

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

      > A = 1. % переменной А не было, теперь она будет «равна» 1
      > B = [1, 2, 3]. % переменная В будет равна списку из трех элементов
      > [A, C, D] = B. % шаблон слева совпадает с списком из трех элементов, первым из которых есть А. В C и D соответственно запишутся 2 и 3
      > [A, C, C] = B. % ошибка, процесс умрет, так как B не совпадает по шаблону со списком [1, 2, 2]
      • 0
        Все же в документации Эрланга и в книге Армстронга они называются переменными, которые могут находится в двух состояниях: связанным и не связанным. Да ходя бы в самом шеле эрланга напиши «A.» и нажми Enter, сообщение об ошибке будет такое: «1: variable 'A' is unbound».
        Но с другой стороны по моему спор чисто о терминологии, называть их переменными или промежуточными именованными данными. Я предпочитаю все же называть их переменными :)
        P.S. Примеры в твоем комментарии все конечно правильные.
        • 0
          я тоже называю переменными но людям, незнакомым с эрлангом лучше сразу объяснять чем переменные эрланга отличаются от переменных императивных языков.
    • 0
      Эрланг — это функциональный язык, но насколько уж строго функциональный не скажу. Я больше практик, чем теоретик. Насколько я знаю, Эрланг писали для практического применения, поэтому синтаксис языка сильно упрощен по сравнению с тем же Lisp и в нем допускаются отклонения от чистой функциональной парадигмы для упрощения написания программ.

      Что качается переменных, они все же называются в Эрланге переменными. Можно объявлять новые в функции. Но ничто не мешает в общем-то писать все на вызовах функций и передаче им параметров. Мне больше нравиться использовать переменные, там где это удобно, так как я все же пришел из мира традиционных языков программирования и не использую строго-функциональную стиль программирования :)
      Заметьте, использование неизменяемых переменных внутри функции нисколько не мешает распараллеливанию и так же отсутствуют побочные эффекты у функции.
  • 0
    А может стоит узел называть узлом, а не нодой?
    • 0
      Придерживаюсь терминологии Эрланга: там они называются нодами. К тому же в эрланге есть ряд комад, например: nodes(). — выдать список нод, с которыми связана данная нода. В общем, чтобы не запутаться самому, лучше называть их нодами. Я уже к этому вполне привык :)
      • –1
        Придерживаюсь терминологии Эрланга: там они называются нодами.

        Вот прямо так по-русски и называются нодами? ;)
        Слово «node» вообще-то именно как «узел» и переводится.
        • 0
          Вы про перевод этого термина на русский! Не сразу понял :) Вообще на русском по моему книг про Эрланг еще нет, поэтому все читал на английском. А так вы правы: «узел» — по русски более правильное понятие.
          • 0
            Я думаю у данного варианта перевода ноги произрастают из XML с его узлами ))

            Собственно я когда читал тоже подумал, отчего же не «узел». Но потом подумалось, что узел это в XML-ях, а тут буквальное «нода» вполне подходит, ведь это очень близко к «хосту» для варианта распределенной системы по нескольким компам.

            А русскоязычный перевод, видимо, будет таковым, каким его устаканит большая часть русскоязычных разрабов.
      • 0
        В терминологии Эрланга происходит обмен между узлами сети
  • 0
    Не знаю, легко ли оценить выигрыш в скорости разработки, но попробуйте. И насколько легко вносит изменения в существующий код?
    • +2
      Я бы сказал очень легко. Я сравниваю со скоростью разработки клиента на C++ и Qt и сервера. Так вот в сервер я вношу изменения раза в 3-5 быстрее, чем в клиента. Я сам сначала удивлялся. Одна из причин: код на Эрланге получается очень компактным по сравнению с C++ изменения обычно вносятся в одном месте, а не в двух-трех местах, как в C++ (я имею ввиду небольшие изменения). Плюс отсутствие строгой типизации переменных часто приводит к тому, что код сервера даже менять не надо, при небольших изменениях на клиенте или в данных обмена между клиентом и сервером.
      Сейчас добавление новой функциональности на сервере, например новой команды в API сервера обычно занимает не больше одного дня.
    • +1
      В Эрланге можно вносить изменения в работающй код, hot code replace типа :)
      • 0
        Написал об этом в следующей статье:
        habrahabr.ru/blogs/erlang/51796/

        Спасибо за напоминание! :)
  • 0
    А горячее обновление версий вы у себя делали? Чтобы по всем правилам OTP :)
    • +1
      По всем правилам OTP мы не делали. Замена версии у нас выполняется пока полной перезагрузкой узла. Но вы напомнили про эту очень хорошую возможность OTP. Обязательно напишу в следующей статье.
      • 0
        я когда смотрел Erlang The Movie, уронил челюсть, что уже тогда можно было на ходу обновить кусок кода.
        • 0
          А что значит «уже тогда»? Даже в более раннем Smalltalk-е есть обновление кода на лету.
          • 0
            Не знал
    • 0
      Написал о горячем обновлении в следующей статье:
      habrahabr.ru/blogs/erlang/51796/

      Спасибо за намек :)
  • 0
    все таки про основы надо больше, как запустить и побавлоаться
    • +2
      Ок, следующую статью целиком посвящу ответам на вопросы в комментариях. Как раз накопилось :) И про это тоже напишу.
    • +1
      Написал про установку Эрланга и первые шаги в своей следующей статье:
      habrahabr.ru/blogs/erlang/51796/

      Спасибо за вопрос!

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