What's all this fuss about Erlang?

Автор оригинала: Joe Armstrong
  • Перевод
by Joe Armstrong

Никто не в состоянии предсказывать будущее — но я сделаю несколько обоснованных предположений.

Предположим, что Intel правы, что их проект Keifer выстрелит. Если это случится, то 32-х ядерные процессоры появятся на рынке не позже 2009-2010.

Ничего удивительного здесь нет. Sun уже продает восьмиядерные Niagara с 4-мя «hyperthreads» на каждом ядре, что эквивалентно 32-ум ядрам.

Это разработка, которая осчастливит программистов на Erlang. Они 20 лет ждали этого события, и теперь настало время расплаты.

Хорошие новости для Erlang-программистов:

На N-ядерном процессоре ваша программа будет работать в N раз быстрее.



Верно ли это?

Почти. Пока что еще рановато об этом говорить, но мы оптимистичны (дико оптимистичны — я не видел такого оптимизма за последние 20 лет!).

В некоторых случаях вам придётся немного подправить ваш код — когда я запускал свою программу генерации документации для Erlang на Sun Niagara (эквивалентно 32-х ядерному процессору), то изменения коснулись лишь одной строчки кода (поменял map на pmap — извиняюсь за тех. подробности, pmap это просто «параллельный map»).

Программа (которая генерировала 63 документа из вики-разметки) стала работать в 7 раз быстрее. Не в 32 раза, конечно — но, я уверяю вас, намного быстрее (впоследствии выяснилось, что узким местом был дисковый I/O, а так как он не был распараллелен, то мы уперлись в семикратный прирост :).

В Ericsson, где я работал, и где был разработан Erlang, мы портируем некоторые приложения на 4-х ядерные процессоры — и знаете, что? После легкого допиливания они работают практически в 4 раза быстрее. У нас уже терпения не хватает дождаться 80-ядерных камешков, с которыми Intel играется в лабораториях…

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

Переменные и параллелизм


C давних времён (диких 20 лет назад) существуют две модели параллелизма:
  • С разделяемой памятью (shared state)
    На обмене сообщениями (message passing)

    С тех пор весь мир пошел по одному пути (разделяемая память), ну а мы выбрали другой.

    Лишь очень малое количество языков пошло по дороге параллелизма на обмене сообщениями — к примеру, Oz и Occam.

    Говоря о параллелизме на обмене сообщениями мы постулируем: «разделяемой памяти нет». Все вычисления производятся в изолированных процессах и единственный способ обменяться информацией — асинхронный обмен сообщениями.

    Так чем же это хорошо?

    Параллелизм с разделяемой памятью построен на принципе «изменяемого состояния» (буквально — память, которую можно менять). Все языки вроде C, Java, C++ и т.п. несут в себе понятие «памяти», которую мы можем менять.

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

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

    Чтобы предотвратить одновременную запись в разделяемую память, нам потребуется механизм блокировок. Назовите его мьютексом или синхронизированным методом, да как хотите, так и назовите — это останется блокировкой.

    Если программа рушится в критическом регионе (т.е. в то время, когда включена блокировка) — то это катастрофа. Все остальные программы не знают, что делать.

    Как программисты решают эти проблемы? Они молятся. На одноядерном процессоре их программы могут «просто работать», но на многоядерном — всё падает.

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

    В Erlang нет изменяемых структур данных


    (вообще говоря, есть, но это неважно)

    Нет изменяемых данных → нет блокировок.
    Нет изменяемых данных → легко распараллелить.

    Ну и как же мы осуществляем параллелизацию? Легко — программист разбивает решение проблемы на несколько параллельных процессов.

    Этот стиль программирования называется…

    (барабанная дробь)

    Concurrency Oriented Programming


    Erlang — не про объекты. У него своя метафора.

    Объекты не в моде. Встречайте параллелизм.

    Мир — параллелен. Куча событий вокруг нас происходит одновременно. Я бы не смог вести свой автомобиль по шоссе, не понимая принцип параллельности на интуитивном уровне — чистой параллельности на обмене сообщениями, чем мы и живём.

    Представьте группу людей. У них нет общего состояния.

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

    Это то, чем является параллельное программирование в своей сути.

    Мы словно скрываем изменяемое состояние внутри объекта — то самое свойство, которое делает паралеллизацию до невозможности сложной проблемой.

    И это работает?


    Да. Erlang используется по всему миру в хай-тек проектах, где требуется надежность. Флагманский проект на Erlang, разработанный Ericsson, шведской телефонной компанией — коммутатор AXD301. В нём более двух миллионов строк Erlang'а.

    AXD301 — это девять девяток надежности (да, ваши глаза вас не обманывают — 99.999999999%). Пять девяток считаются хорошим показателем (downtime — 5.2 минуты в год). Семь девяток практически недостижимы… но нам удалось достичь 9-и.

    Благодаря чему? Отсутствие разделяемой памяти плюс продвинутая модель восстановления из крэшей. Вы можете прочитать обо всём этом подробнее в моей диссертации на Ph.D.

    Пользователи Erlang'а?

    • те, кто «в теме»
      стартапы
      Ericsson
      wings, программа для 3D-моделирования
      ejabberd, IM-сервер для jabber/XMPP
      tsung, многопротокольный инструмент для распределенного тестирования нагрузки
      yaws, высокопроизводительный веб-сервер
      тысячи хакеров, мечтающих: «вот бы заюзать это на моей работе в офисе»


      А Erlang сложный?


      Нет. Но он необычный.

      У Erlang нет «похожего на C синтаксиса, чтобы было полегче учить». Он не «объектно-ориентированный», у него нет «переменных» и он — «функциональный язык программирования».

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

      Вам наверняка уже стало интересно, как выглядит код на Erlang. Язык предполагает повсеместное использование синтаксиса pattern matching (сопоставления с образцом) — вот маленький пример кода на Erlang (взято из новой книги о нём):

      -module(geometry).
      -export([area/1]).

      area({rectangle, Width, Ht}) -> Width * Ht;
      area({square, X}) -> X * X;
      area({circle, R}) -> 3.14159 * R * R.



      Скомпилируем его и запустим в оболочке Erlang:

      1> c(geometry).
      {ok,geometry}

      2> geometry:area({rectangle, 10, 5}).
      50

      3> geometry:area({circle, 1.4}).
      6.15752



      В общем-то, несложно… Вот Java-код, делающий то же самое:

      abstract class Shape {
        abstract double area();
      }

      class Circle extends Shape {
         final double radius;
         Circle(double radius) { this.radius = radius; }
         double area() { return Math.PI * radius*radius; }
      }

      class Rectangle extends Shape {
         final double ht;
         final double width;
         Rectangle(double width, double height) {
           this.ht = height;
           this.width = width;
         }
         double area() { return width * ht; }
      }

      class Square extends Shape {
        final double side;
        Square(double side) {
          this.side = side;
        }
        double area() { return side * side; }
      }



      От переводчика: код на Erlang, создающий два процесса ping и pong, пингующие друг друга несколько раз:

      -module(pingpong).

      -export([start/0, ping/2, pong/0]).

      ping(0, Pong_PID) ->
         Pong_PID! finished,
         io:format(«ping finished~n», []);

      ping(N, Pong_PID) ->
         Pong_PID! {ping, self()},
         receive
           pong ->
             io:format(«Ping received pong~n», [])
         end,
         ping(N — 1, Pong_PID).

      pong() ->
         receive
           finished ->
             io:format(«Pong finished~n», []);
           {ping, Ping_PID} ->
             io:format(«Pong received ping~n», []),
             Ping_PID! pong,
             pong()
         end.

      start() ->
         Pong_PID = spawn(pingpong, pong, []),
         spawn(pingpong, ping, [3, Pong_PID]).



      Вывод:

      1> c(pingpong).
      {ok,pingpong}
      2> pingpong:start().
      <0.36.0>
      Pong received ping
      Ping received pong
      Pong received ping
      Ping received pong
      Pong received ping
      Ping received pong
      ping finished
      Pong finished



      Где мне достать Erlang?


      Скачайте его с erlang.org

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

Похожие публикации

Комментарии 271

    +6
    Классная статья, спасибо за перевод.
    Над назад у нас был предмет параллельное программирование. Это был первый и последний непростой предмет по специальности после того, как я начал заниматься программированием.
    Тогда жутко понравилось =) Мы писали на С, и из терминалки работали с суперкомпом ВЦ Новосибирского Академгородка. Если честно, прониклись очень немногие в группе, буквально четыре-пять человек, но блин, это было интересно! Вот если бы ещё препод хоть чуть-чуть знал бы этот предмет... Впрочем, хватит ностальгий.
    Всё это я к тому, что параллелизм - это круто и интересно. Скорее всего, именно в эту область я направлюсь, когда мне наскучит (если мне наскучит, "если я позвоню тебе в следующем декабре") веб.
    • НЛО прилетело и опубликовало эту надпись здесь
        0
        О_о абсолютно солидарен, у меня преподавали и тот и другой, про Малышкина вообще ничего хорошего сказать не могу, а вот Корнеев разложил все по полочкам :)
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Среди любителей Erlang-а бытует мнение, что Erlang расшифровывается как ERicsson LANGuage. На самом деле язык назван в честь Агнера Крарупа Эрланга, датского математика, который работал в области телекоммуникаций. Так, единица измерения телекоммуникационного траффика также называется «Erlang».
              0
              > На самом деле
              По имеющейся у меня информации, всё чуточку интереснее. Это сознательная игра слов.
            0
            Корнеев не из МАИ случаем?
              0
              вот откуда он не знаю, но сейчас преподает в НГТУ и, наверное, в НГУ
          +1
          И почему я учусь в какой-то фигне :(
            +1
            Ну, я тоже проникся, даже курсяк на эту тему писал. К сожалению, кроме меня больше не проникся никто, и то что препод досконально знал и понимал предмет — не помогло…
            0
            Угу. Очень даже может быть, что процессы - это как раз то, чего не хватает другим функциональным языкам, чтобы на них проще писались программы для реального мира. Сообщение - это как раз та форма переменной, которая не слишком переменная, но позволяющая проводить декомпозицию программы достаточно свободно.

            Но только автора статьи надо попровать. Асинхронная пересылка сообщений - это основной метод достижения массового параллелизма сегодня. Возьмите хоть суперкомпьютеры (MPI - message passing interface), хоть программирование для Cell (micro MPI). Хоть Linda, хоть куча ещё всяких разных инструментов. Так что Erlang не такой уж и уникальный.
              0
              Поправка следующая: мы сначала берём языки с общей памятью, а потом начинаем к ним прикручивать сбочку методы работы с сообщениями. Получается... так себе. На Erlang же это всё встроено в язык. Проблема в том, что всё-таки он необычный и всё-таки он функциональный. Не так много народу может это осилить (хотя когда-то и C/C++ для многих какзался кошмаром, так что может всё и не так страшно).
                0
                Не, у разработчиков эрланга изначально была цель сделать язык, которому можно быстро научить нового человека — и он действительно очень простой, местами даже слишком.
                  0
                  Не соглашусь. Erlang всё же один из самых простых языков программирования. Да, немного необычно, циклы организовывать через рекурсию и вручную протаскивать состояние между несколькими функциями, но к этому быстро привыкаешь. И благодаря возможности разбить всё на процессы это не напрягает, как, например в Haskell, где программы быстро превращаются в сплошные абстракции.

                  Просто в качестве примера: у нас одна контора в городе которая, если её не ограничивают в выборе языка, пишет всё на Erlang'е. Так новички осваивают язык практически за неделю. Он действительно простой.

                  Вот. А насчёт прикручивания методов сбоку... Так тоже по-разному бывает. Хотя, если честно, мне не понятно, что именно делает Erlang таким удобным.
                0
                У ерланга есть есть одна мааленькая проблемка, сложные системы на нем писать существенно сложнее, чем на C++ или Java или любом другом объектном языке.
                  +1
                  Человеку без практического опыта написания сложных распределёных систем, существенно проще писать на ерланге, чем на ++ или Java. Единственная сложность с которой я столкнулся - это когда работаешь со специфичными данными и понимаешь что нецелесообразно их хранить в ets. Хотя не знаю что там сейчас, уже несколько лет не слежу за изменениями.
                  А сравнение с объектными языками - это как минимум говорит о том, что вы не написали ниодного приложения на языке подобном ерлангу. Может тогда бы вас осенило, что объектность там ни к чему.
                    0

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

                    В зависимости что писать.


                    А сравнение с объектными языками - это как минимум говорит о том, что вы не написали ниодного приложения на языке подобном ерлангу.

                    Как минимум я читал спецификации erlang и знаю что такое функциональное программирование. И я не говорил что там нужна объектность. Я говорю о построении на нем сложных систем. Решение не иметь изменяемых переменных выйдет боком при написании систем где в случае объектной модели таких переменных много и они изменяются часто. Сугубо говоря в случае erlang если вам это потребуется то прийдется писать много много мелких кусков и плодить много много процессов. Или же думать как это оптимизировать именно под erlang.
                      +1
                      Решение не иметь изменяемых переменных выйдет боком при написании систем где в случае объектной модели таких переменных много и они изменяются часто.

                      Читается: сложно скопировать один в один существующую ООП программу, где переменных много и они изменяются часто.
                      Далее вы сами даете решение
                      в случае erlang если вам это потребуется писать много много мелких кусков и плодить много много процессов
                      Дейстидельно много много процессов это хорошо, а в случае erlang и очень дешево, там процесс стоит меньше, чем процесс и поток в C#, Java, etc.
                        0

                        Далее вы сами даете решение

                        Я просто представляю как это можно сделать в Erlang.


                        Дейстидельно много много процессов это хорошо, а в случае erlang и очень дешево, там процесс стоит меньше, чем процесс и поток в C#, Java, etc.

                        Вот тут-то и возникает проблема. Много процессов это много сообщений между ними и чем больше их там больше сообщений. Это кстати является бичем всех микроядреных ОС. И именно по этому микроядреные ОС не получили широкого распрастранения.
                          0
                          Чем больше сообщений между ними - тем сложнее писать на ерланге по сравнению с Си++/Жава?
                            0
                            Это вообще не привязано к языку. Просто в C++/Java вам это может вообще не понадобиться.
                              0
                              Нет, тем менее эффективна такая параллельная программа, больше времени тратиться на сообщения, чем при использовании (D/R)MA.
                            0
                            меньше - это слабо сказано :) Он практически ничего не стоит по сравнению с полноценными трэдами. И плодить их нужно миллионами )
                              0
                              Если не сложно, поясните пожалуйста, каким же образом Erlang создаёт "потоки", они не завязаны на потоках системы? Откуда такая дешевизна?
                                0
                                не завязаны.
                                Уже плохо помню как всё там сделано, но насколько мне не изменяет память - то их преемптив переключение между процессами(ерланга) происходит с помощью простого счётчика вызова встроенных функций(не помню как они зовутся). А процесс - это маленькая структурка с входящей очередью сообщений, линками на другие процессы(чтобы оповещать при смерти итп) и ещё всякие мелочи.
                                  0
                                  Тогда из этого сразу следует, что это "нужно миллионами" процессов не будут работать параллельно, плюс будут тратить время на общение с менеджером, в итоге должно работать медленнее, чем если бы мы запустили потоков столько, сколько процессов.
                                    0
                                    Сколько процессов будет параллельно работать зависит от кол-ва ядер, процессоров, нодов в сети и как вы всё это настроите :)
                                    Да, будут тратить, будут работать медленее до того как начнут массово появляться железяки с большим кол-вом ядер. И тут уже встанет вопрос - а на чём проще разрабатывать приложения под такие мощности, в случае с ерлангом - это уже готовое и проверенное решение с которым легко научиться работать.
                                      0
                                      Так и думал, что все фразу про "очень много" не больше чем миф. И всё прекрасно понимают, что быстрее чем в N Раз на N потоках не сделать. Так что не нужно там ничего пложить тысячами и миллионами. Поживём-увидим, как будет идти распространиние Эрланга в массы :)
                                        0
                                        *плодить* и, разумеется, *распространение*.
                                          +1
                                          >И всё прекрасно понимают, что быстрее чем в N Раз на N потоках не сделать. Так что не нужно там ничего пложить тысячами и миллионами.
                                          Создание процессов не для увеличения производительности, это идеология, где каждый объект в этом параллельном миру должен быть независимым процессом, к которому можно обращаться только с помощью сообщений.
                                          И для создания крупного приложения в любом случае придётся плодить миллионы процессов, иначе его не написать.
                                      0
                                      За универсальность нужно платить. Если процесс в Эрланге дешовый по сравнению с вызовом создания процесса на WinAPI под виндой, то это не означает, что он будет эффективнее процессов в какой-нибудь *nix системе, или фаст тредов какого-нибудь микроядра.

                                      Яркий пример, в Mac OS, еще до версии X, существовало API (и сейчас свое отживает) Carbon. Оно использует свой собственный Thread Manager и не завязывается на тридах системы. И если в 9-ке это работало нормально, то как оказалось в последствии, карбоновские cooperative threads имеют неслабый перформанс пенальти по сравнению с preemtive threads микроядра Mach L4, на котором основана Mac OS X.
                                        +1
                                        Всё мы прекрасно знаем :)
                                        нажми меня
                                          0
                                          Ну извиняюсь. Нитки в Linux - они очень неторопливые, как известно. В микроядрах они гораздо эффективнее реализованы обычно. Про Mach не знаю, но, например, в QNX на два порядка все примитивы быстрее работают, чем аналогичные в Linux.
                                            0
                                            И, кстати, совершенно, например, не понятно, за счёт чего выигрывают в этом тесте системы с собственным runtime для нитей/процессов. Например, вполне может быть, что там всё выполняется последовательно в одной нити, кооперативно. Естественно, это будет быстрее. Вобщем, разбираться надо. Только параллелизма это никак не прибавляет системе.
                                              0
                                              просто в системе с собственными процессами (вроде Erlang) их исполнение размазывается по "настоящим" процессам OS

                                              т.е. если у вас в Erlang будет миллион процессов — все 4 ядра вашего Core Quad будут полностью загружены ими

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

                                                P.S. И снова я вижу эту странную цифру - миллион. Согласитесь, на 4х ядрах посчитать даже интеграл будет быстрее разбив его на 4 куска, чем на миллион и тратить время на их переключение/создание.
                                                  0
                                                  так для интеграла у вас и будет 4 куска

                                                  а там где нужен миллион - будет миллион

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

                                                  "в других" языках вы ограничены потоками ОС, которые слишком тяжелые и их количество сильно ограничено ОС
                                                    0
                                                    Да ну. Не правда. Такой мелкозернистый параллелизм можно реализовать при помощи кооперативной многозадачности. Будет то же самое, и можно будет не париться. Только вопрос в том, а надо ли? Может лучше решать задачу в терминах асинхронного I/O и не тратиться зря на коммуникацию между нитями?
                                                  0
                                                  alex_blank> т.е. если у вас в Erlang будет миллион процессов — все 4 ядра вашего Core Quad будут полностью загружены ими

                                                  Только в случае, если Erlang для выполнения своего миллиона задействует 4 или больше процессов или потоков ОС! А если там один процесс и один поток, то весь миллион виртуальных процессов эрланга будет сидеть на одном ядре.
                              –1
                              Позновательно. Думаю — наверняка в скором времени появится какой-нибудь objectErlang :) было бы железо доступно, а чем его загрузить найдут.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                +3
                                Больше бы таких статей на Хабре! Интересно, особенно для тех кто из другого лагеря программистов - веб :)
                                Было бы неплохо видеть такого рода статьи про разные ЯП - что для чего, с чем едят и что щас в них актуально и где используется.
                                Познавание окружающего мира - это круто.
                                  0
                                  — «Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру на Эрлонг, 3Д-экшон суть такова...

                                  просто интересно на нем можно делать нечто вроде игр и прочего? я могу слабо представить сложный проект без ооп
                                    0
                                    См. вот например 3D редактор wings3D, на чистом ерланге.
                                      0
                                      Но как же этот wings3D жостко тормозит... :(
                                      0
                                      Единственная вещь из OOP-языков, которая действительно необходима в сложных системах - это слабая инкапсуляция (packages в Java, namespaces в C++). Всё остальное - не так важно, а пакеты напрямую к OOP отношения не имеют.
                                        0
                                        если я правильно понимаю, то объект в ерланге представлен потоком. А поток так-же принимает и посылает сообщения к другим, как объект дергает другие объекты за методы....
                                          0
                                          да, аналогия похожая
                                        0
                                        Очень интересная статья. Спасибо!
                                          0
                                          На самом деле обьектно-ориентированный подход укладывается в рамки привычного восприятия мира. Поэтому его и толкают в универах на младших курсах. На самом деле уже сложились некие базовые принципы написания "правильного" кода, и в них ООП жестко доминирует.

                                          Erlang - интересный, а главное - "живой", но пока ещё не вошедший в широкое использование язык. Как часто бывает, "самый лучший" не всегда становится мейнстримом. Потому что программисты, реализующие подобные задачи, должны иметь серьёзный опыт работы - т.е. начинать им в любом случае приходилось с сишника. А отказаться уже хорошо изученного языка довольно сложно.

                                          objectErlang - бред. Слишком разные концепции написания кода.
                                            +1
                                            Если кому интересна параллельная разработка на .Net, Microsoft выпустила библиотеку Microsoft’s Parallel Extensions Library
                                              0
                                              Стиль статьи идеально подходит под формат "магазин на диване".

                                              "Мы представляем вам революционно новое устройство, с ним вы сможете работать в 10, 20, и даже в 30 раз быстрее! Мы предлагаем вам параллелизм! ДЕВЯТЬ ДЕВЯТОК НАДЕЖНОСТИ!! Заказывайте прямо сейч^W"
                                                +1
                                                Серебрянная пуля параллельного программирования? А как быть в ситуациях когда нужно синхронизировать потоки при доступе к разделяемому ими ресурсу на запись (такие задачи довольно часто имеют место быть, например БД)? И вообще, если заостряете внимание на параллельном программировании, то и приводите примеры по теме, а не показывайте очередной Python vs Java vs NET.

                                                У меня есть подозрения, что такую асинхронную архитектуру обмена сообщениями можно без проблем построить на ООП языках (с тем же самым повышением производительности).
                                                  0
                                                  Угу, у интела даже есть DLL'ка которая сама это делает, с программой, которая о параллельности вообще ничего не знает.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                      0
                                                      Можно. Только порождение процессов или потоков будет жрать больше ресурсов. Хотя далеко не факт что решение на erlang при этом будет жрать меньше ресурсов из-за этого.
                                                        0
                                                        Вообще можно, см. actors в Scala — они по мотивам эрланга сделаны.
                                                        Но в случае эрланга фишка в том что весь дизайн языка построен вокруг этой модели, ей удобно пользоваться и сломать что-то очень сложно. То, что два процесса не могут иметь разделяемых данных — это одна из основных фишек, а не недостаток.

                                                        Насчет расделяемого ресурса — в двух словах, создается специальный серверный процесс, который общается с этим ресурсом, а остальные общаются с этим процессом посредством тех же сообщений.
                                                          0
                                                          >То, что два процесса не могут иметь разделяемых данных — это одна из основных фишек, а не недостаток.
                                                          могут, ets :)
                                                            0
                                                            Как обычно, "ну, если ооочень нужно.." ;)
                                                          0
                                                          насколько мне изветсно, в ерланге есть встроенная или просто отдельный проект БД, так что если не использовать напрямую обычные базы, то все ок
                                                            +1
                                                            она называется mnesia
                                                          0
                                                          Что бы там не говорили программисты, есть такая жесткая вещь, как практика.
                                                          А на практике встречается такая задача:

                                                          На 8-ядерном сервере с 16 гектарами оперативки нужно запустить 4 серверных приложения для Windows Server 2003. При этом необходимо обеспечить максимальное быстродействие. Ни одно приложение не относится к разряду "самопальных", называть их не буду, но кто хоть раз в жизни администрировал крупные офисы (больше 1000 машин) их отлично знают.

                                                          Сразу был установлен винсервер, на него поставили 4 сервиса, раскидали их по разным процессорам. Производительность не устраивала.

                                                          Поставили ксен и 4(!) винды. На каждую по сервису. Производительность выросла на 18%

                                                          Мораль: "Угу, у интела даже есть DLL'ка которая сама это делает, с программой, которая о параллельности вообще ничего не знает." - полнейший бред. Мультитредность должна закладываться на этапе проектировки дизайна проекта, а если этого нету - ни одна дллька не поможет.
                                                            0
                                                            Речь видимо идёт не о распараллеливание по функциям, а о распараллеливании циклов и тому подобных вещей. А это интелловский компилятор действительно делает и действительно даёт прирост в нужное количиство раз при большом объёме вычислений.
                                                            0
                                                            Спасибо за перевод :)
                                                            Но некоторые вещи вызывают удивление, возможно и из-за того что я не в курсе этого языка.
                                                            Каким образом модель с передачей сообщений в рамках одного процессора может быть лучше чем модель с общей памятью? Мне думается что в такой ситуации не стоит изучать специально Erlang, а пользоваться C + OpenMP, так будет быстрее и проще, и время на пересылку сообщений тратиться не будет.
                                                            Для приведённых в статье применений я не оспариваю полезность этого языка, но он не становиться популярным именно потому, что распараллелить и убыстрить код можно и другими, менее затратными способами, и пока что этого вполне хватает :)
                                                            Думаю не всё так просто и с написанием крупных приложений. Наверняка там код не такой прозрачный, как в примере, и нужно уже самому продумывать и прописывать взаимодействие процессов, блокировки и пересылки. И тогда по затраченному времени на написание это не будет быстрее, чем тотже MPI...
                                                              0
                                                              Там на самом деле 'хитрая' пересылка сообщений. Данные не копируются, а передаются по указателю. В парадигме static single assignment (то есть без переменных) это можно сделать. Фактически, сообщения эти реализованы поверх особого сборщика мусора. Это если речь идёт о процессах, работающих внутри smp или numa. А если это всё на другой коробке через сеть, то всё прозрачно для программиста копируется. На самом деле - очень мощная штука. И очень удобная, уступающая в удобстве разве только компилятору, который за вас циклы распараллеливать будет. Но не все программы состоят из 'умножений матриц' :) А писать на MPI ГОРАЗДО сложнее, чем на Erlang. С его pattern matching'ом на структурированных сообщениях. Вот.

                                                              В HPC Erlang по другой причине не используется - он, конечно, относительно быстрый, но матрицы на нём не поумножаешь достаточно эффективно и экономно.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  0
                                                                  Не факт, что будет эффективно. Надо привязываться ко внутренним типам данных Erlang, что может существенно ограничить производительность. Хотя, конечно, от задачи зависит.
                                                                +3
                                                                Каким образом модель с передачей сообщений в рамках одного процессора может быть лучше чем модель с общей памятью?

                                                                На одном одноядерном процессоре - никак. А вот если ядер 30-50, то это уже беда: каналы связи между процессорами перегружаются, доступ в кеш "чужого" процессора жутко томозной, etc. Собственно идеальный процессор для языков с передачей сообщений выглядит примерно так, но есть одно но: язык-то на подобные процессоры рассчитан, а вот имеющиеся реализации - пока нет.

                                                                Мне думается что в такой ситуации не стоит изучать специально Erlang, а пользоваться C + OpenMP, так будет быстрее и проще, и время на пересылку сообщений тратиться не будет.
                                                                Предел - где-то 8-16 ядер, дальше уже накладные расходы от общей памяти начинают перевешивать.

                                                                Multicore - пока ещё молодое направление, но похоже назревает очередная (после появления ООП) революция...
                                                                  0
                                                                  Предел - где-то 8-16 ядер, дальше уже накладные расходы от общей памяти начинают перевешивать.

                                                                  Но ведь и затраты на пересылку при таком количестве взаимодействующих процессов будут велики?
                                                                    +1
                                                                    Хм. Так общая память тоже построенна на передачи сообщений: процессоры пуляются друг в друга запросами и ответами по общей шине или по сети (NUMA). Это, конечно, всё автоматизировано и программист этого не видит, но тем не менее. При этом протоколы должны быть достаточно сложными, чтобы для программиста поддерживалась иллюзия общей памяти. А сложные алгоритмы означают сложное и относительно медленное оборудование. Явная пересылка сообщений гораздо проще реализуется в аппаратуре, а благодаря всяким иерархическим коммутаторам (например, технологий много на самом деле) может распространятся не на всю систему, а только на те узлы, которые в обменах учавствуют.

                                                                    В итоге, несмотря на то, что кажется, что работы делается больше, всё может работать гораздо эффективней. Смотрите на тот же Cell. Или на всякие mesh-процессоры (это когда куча ядер связана квадратной сеткой из каналов связи). Ну и как историческй факт: советские транспьютеры, построенные на основе парадигмы с пересылкой сообщения обладали отличной производительностью. У нас на них до сих пор кое-что расчитывают.
                                                                      0
                                                                      Согласен. Но где вы в моих постах увидели разговор про NUMA или распределённые системы с общей памятью? Я говорю про использование многоядерных процессоров, в которых можно не использовать пересылку сообщений, а использовать DMA к общей памяти на аппаратном уровне.

                                                                      Думаю не стоит мешать в одну кучу всё многообразие существующих архитектур, в 09:59 я хотел сказать лишь о преимуществе (судя по переводу) OpenMP над Erlang на одной машине с множеством ядер, видимо это было не так истолковано :)
                                                                        +1
                                                                        Именно про них (подчеркну: про многоядерные, SMP и NUMA - машины с общей, а не с распределённой, памятью тоже - я и говорю :) Прочитайте о протоколах поддержки согласованности кэшей (даже согласованность L1 кэшей надо поддерживать, если у вас L2 общий). Да и просто об обмене данными с памятью. Да и даже про внутреннюю организацию процессоров. Все современные сложные цифровые устройства построены на парадигме пересылки данных. Даже собственно сами модули памяти - это устройства, которые принимают запросы и отвечают на них. И это, вобщем-то, относительно медленные устройства. Например, по PCI-Express данные можно гнать со скоростью гораздо большей, чем их можно считывать из памяти, или записывать. Так что, пересылка сообщений не обязательно должна быть медленней, чем даже чтение значения переменной из памяти в регистр.
                                                                          0
                                                                          Ну вот речь и зашла о низкоуровневых примитивах, которые основаны на особенностях архитектуры. Что лишний раз доказывает то, что концепция языка играет совсем не самую важную роль при распаралеливании и оптимизации. Нужно учитывать специфику задачи и целевую архитектуру. Потому, разрекламированая универсальность Эрланга похожа на миф :)
                                                                            0
                                                                            Ну... Думается, что нельзя архитектуры рассматривать отдельно от приложений. Всё же системы сейчас строятся под конкретные задачи. И то, в какой парадигме будут создаваться приложения играет важную роль. А в Эрланге что не универсальное? Любой алгоритм записать можно... Всё универсально.
                                                                              0
                                                                              Мы же выше решили, что для HPC он не так уж и подходит, на данный момент пока что.
                                                                              Я вижу его применение в основном для разнообразных "серверов", где нужно относительно небольшое(сотни?) число потоков, которые выполняют в один момент разные задачи, и без интенсивного обмена данными между собой. Хотя и остаётся вопрос, зачем для этого использовать именно Erlang :)
                                                                        0
                                                                        Хотя я похоже снова на HPC зацикливаюсь :)
                                                                  0
                                                                  А может мне кто-нибудь пояснить, вот пример в конце, он уже ускорен в 4 раза на четырехядерном процессоре или еще что-то надо делать? Еще хотелось бы знать, как erlang работает на windows, каким образом он в одном winapi процессе умудряется делать распаралелливание без тех же winapi потоков? Раскрывается ли erlang на windows?
                                                                    0
                                                                    На четырехядерном процессе будет 4 "настоящих" потока ОС, в которых будут исполняться десятки тысяч эрланговских потоков.
                                                                      0
                                                                      на 4хядерных не интересно :) можно писать под одноядерный на Си без распараллеливания и будет работать быстрее. Но когда будет 32ядра и больше...
                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                          0
                                                                          Зависит от того как будешь писать на ергланге и на Си, можно и на ерланге писать немасштабируемый софт. Да, изначально на ерланге проще, но это всё относительно и зависит от опыта. Ну кроме поиска ошибок, отладки, и хот-апдейтов которые ерланг предоставляет изкаропки, этого у ерланга не отнять :)
                                                                            0
                                                                            Ну. Опять же не факт :) Вопрос в том, как именно на Си писать. Ничего ведь не мешает в точности повторить те процессы, которые происходят в runtime Erlang'а. Да вобщем-то это и на уровне библиотек (pth, например) делается.

                                                                            Да и потом, никто не мешает на Erlang'е написать программу, которая не будет масштабироваться. И масштабируется хорошо только определённый класс задач. Который хорошо разбивается на процессы. Но такое разбиение не всегда возможно.
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                –1
                                                                                Поддерживаю, особенно учитывая, что проблемы распараллеливания как правило носят содержательный, фундаментальный характер, они вообще не имеют отношения к конкретному языку программирования. Язык программирования - это всего ли ФОРМА выражения мыслей, но он сам по себе не является СОДЕРЖАНИЕМ.
                                                                                Кстати run-time среды языков типа Erlang написаны на том же "C" или "C++".
                                                                                Вообще конечно не имею ничего против функциональных языков - но не стоит превращать их в религию, думая, что они автоматически решают фундаментальные проблемы, тогда как язык это лишь способ записи мыслей (алгоритмов), сам по себе он не может решить проблемы. Плохо только тогда, когда язык мешает.
                                                                                  0
                                                                                  проблема распараллеливания имеет самое прямое отношение к языку, вы очень сильно ошибаетесь и вводите в заблуждение других читателей этой ветки

                                                                                  вот вам простой пример: в Haskell можно запускать выполнение любой функции в параллельном потоке потому что сама семантика языка гарантирует отсутствие скрытых зависимостей от других контекстов исполнения (например чтения-записи в общую память или же какого-либо I/O с интерфейсами OS, могущими привести к этому)

                                                                                  то есть, это поведение зашито в саму модель языка Haskell

                                                                                  в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости — и в общем случае эта задача там неразрешима
                                                                                    0
                                                                                    Только не стоит забывать, что это "распараллеливание" не совсем точное понятие и выполняться программа будет на отведённых для выполнения потоках.
                                                                                    Так что в итоге это не даёт каких-то особых преимуществ перед хорошо написанным кодом на C(++), кроме как включение параллелизма в концепцию языка. Но это избавление от сложности распараллеливания в C(++) наверняка имеет и недостатки в виде более сложной реализации некоторых вещей на Erlang'е.

                                                                                    в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости — и в общем случае эта задача там неразрешима

                                                                                    В общем случае не всякая "программа" может быть откомпилирована, а не всякая откомпилированная будет правильно работать, не так ли? Всё-таки C++ и Erlang вроде бы компилируемые языки, стоит смотреть больше на качестко и скорость работы полученного байткода, чем на время компиляции.

                                                                                    P.S. Я не против этого языка, но не нужно же считать его панацеей.
                                                                                    P.P.S. Мне даже уже интересно стало, если в Эрланге всё так не связанно друг с другом, то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков? :)
                                                                                      0
                                                                                      >>Так что в итоге это не даёт каких-то особых преимуществ перед преимуществ перед хорошо написанным кодом

                                                                                      .. а так же перед хорошо написанным кодом на x86-опкодах, угу

                                                                                      давайте не будем толочь воду в ступе

                                                                                      мы же здесь не про сферических коней в вакууме — есть Эрланг, на нём хорошо распараллеленый код писать в разы проще, чем на C++, это и есть основной concern

                                                                                      >> чем на время компиляции.

                                                                                      при чём тут время компиляции? я говорил про то, что задача автоматического параллелизма разрешима в C++ лишь в частных случаях, а в Erlang - в общем

                                                                                      >> Всё-таки C++ и Erlang вроде бы компилируемые языки

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

                                                                                      >> P.S. Я не против этого языка, но не нужно же считать его панацеей.

                                                                                      забавно, покажите мне место в статье или в комментариях к ней, где утверждается: "Эрланг — это панацея, ребяты!"

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

                                                                                      делаете процесс, принимающий сообщение "записать кусок байтов в файл"

                                                                                      все остальные процессы посылают сообщение с байтами этому процессу
                                                                                        0
                                                                                        Не путайте Erlang c Haskell. В Erlang есть функции, для которых не выполняется referntial transparency. Возьмите ту же работу с файлами.

                                                                                        Вот. А если говорить о Haskell, то решение многих задач на нём очень быстро превращается в головную боль. Я не говорю про все задачи. Но очень многие важные. Например, физика. Например, задачи на графах. Например, моделирование процессов. Всё же миру нужны состояния, а манады их инкапсулируют уж очень негибко. Да ещё и таким способом, что вычисления строго последовательные выходят. И никак их не расцепить.

                                                                                        Таким образом, чистые функции теоретически - это хорошо. Но на практике они сильно органичивают программиста и имеют свои накладные расходы, когда приходится реализовывать нечто, что без состояний - никак. И если в рамках Си, например, компилятор может быть крутым и выявить ref.trans. функции, и программисту ничто не мешает их писать, то в случае чистого функционального подхода, программисту постоянно будет мешаться stateless. Можно посмотреть любой большой проект на Haskell и убедится в этом.

                                                                                        Вот. Что хотелось сказать. Функциональное программирование хорошо, как концепт. Но для реальной жизни его надо расширять как-то. Вот Erlang его расширяет процессами - это совсем не функциональный подход. ML императивными конструкциями... И наоборот. Многие императивные языки сейчас расширены функциональными возможностями. Тот же C++ с boost'ом. Есть даже варианты расширения Си, и даже расширения с целью быстро писать параллельные программы. Вроде T-системы.

                                                                                        Так что вот. Не нужно в абсолют возводить теорию, которая не проверена практикой (то есть, экспериментом).

                                                                                        P.S. Кстати, stackless python или rinda, или тот же smalltalk, тоже позволяют общаться тысячам потоков вполне себе плавно. И не функциональность этих систем этому не мешает.
                                                                                          0
                                                                                          я про Haskell и ссылочную прозрачность и не говорил

                                                                                          в Erlang код не параллелится per function, просто там процесс и способы их коммуникации — это примитивы языка, что и обеспечивает целостность программы, в отличие от низкоуровневого C++
                                                                                            0
                                                                                            Но это не на автомате.
                                                                                              0
                                                                                              В смысле - это не автоматическое распараллеливание. А встроенные процессы/нити есть во многих языках. В Erlang что хорошо, так это удобная работа с этими сообщениями. Но ничто не мешает этот message matching сделать в рамках и другой системы.
                                                                                                0
                                                                                                Можно. Только невольно приходит на ум, что Армстронг прав в своём шутливом дополнении к десятому правилу Гринспуна (которое, как мы помним, о Лиспе):
                                                                                                Any sufficiently advanced concurrent program contains an ad hoc, informally-specified, bug ridden, slow implementation of half of Erlang.

                                                                                                Вообще, почитайте диссертацию Армстронга «Making reliable distributed systems in the presence of software errors» (она есть в свободном доступе). Там он очень подробно и доходчиво объясняет, почему Эрланг именно такой и никакой другой, какие цели преследовались при создании языка и платформы и т. д. Распараллеливаемость с целью повышения быстродействия в духе HPC никогда не была краеугольной задачей. Надёжность, масштабируемость, распределённость — для этого делался Эрланг, и со своими задачами он отлично справляется.
                                                                                                И вот буквально в последние год-полтора в связи с бумом многоядерников начался (в том числе усилиями самого Армстронга, и большое ему за это спасибо) весь этот hype, о котором статья.
                                                                                                  0
                                                                                                  Только обратил внимание, что статья тоже ссылается на диссертацию. В любом случае, почитать её стоит.
                                                                                                0
                                                                                                Другой - это императивной, например.
                                                                                          0
                                                                                          Кроме компилятора есть еще и программист. То, что не может сделать компилятор - может за него сделать программист. Кто бы спорил, что функциональные языки потенциально избавляют программиста от изрядной части работы по распараллеливанию кода на нижнем уровне - это и стимулировало research в области функционального программирования.
                                                                                          Но, во-первых, это преимущество по большей части носит чисто теоретический характер, когда в умных книжках рассуждают об автоматических преобразованиях программ, редукциях и лямбда-исчислении. На практике же компиляторы функциональных языков - доступные нам в ощущениях, а не те, о которых ходят легенды - не умеют сами распараллеливать вычисления так хорошо, как следует из теории. Они вообще не очень-то сильны как компиляторы в машинный код, а тем более как распараллеливающие компиляторы. Вместо этого разработчики сред стараются вынести все, связанное с распараллеливанием в run-time - оно и понятно, так намного проще, ведь не нужно привлекать большую науку с переднего края при написании компилятора.
                                                                                          Отсюда и появление всяких конструкций явного параллелизма в, казалось бы, "чистых" функциональных языках, которые могли бы и сами этот параллелизм выявить.
                                                                                          А во-вторых, на практике за все приходится платить. Функциональные языки избавляют нас от траха мозгов с низкоуровневым распараллеливанием кода - но своим pattern matching, динамической типизацией, сборкой мусора, типичной для них компиляцией в байт-коды и т.п., привносят столько накладных расходов, что это де-факто съедает выигрыш от автоматического распараллеливания.
                                                                                          Не говоря уже о том, что мыслить в такой форме возможно, но неудобно - по сравнению с императивными языками. Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".
                                                                                            0
                                                                                            >> Они вообще не очень-то сильны как компиляторы в машинный код, а тем более как распараллеливающие компиляторы.

                                                                                            это верно, как компиляторы в эффективный машинный код они сегодня — тупое говно

                                                                                            здесь есть 2 проблемы:

                                                                                            1. академикам влом реализовывать алгоритмы из своих PhD диссертаций в реальных компиляторах (попробуйте разобраться в сорцах GHC какого-нибудь — да там чёрт ногу сломит), у них просто нет мотивации никакой этого делать, им за это никто не заплатит

                                                                                            2. фундаментальная математическая проблема — неразрешимость программ в общем случае, что следует из теоремы Гёделя о неполноте — это означает, что "серебряную пулю" никто и никогда не создаст

                                                                                            >> Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".

                                                                                            когда у меня голова болит за производительность — и я беру в руки C

                                                                                            потому что если мне нужно решать задачу в терминах архитектуры PC, то глупо использовать для этого абстракцию над ней
                                                                                              0
                                                                                              А каким образом связана проблема написания эффективного компилятора с функцинального языка и теорема Гёделя?
                                                                                                0
                                                                                                зависит от того, что для вас — эффективный компилятор

                                                                                                вот я хочу компилятор, который мог бы анализировать код на предмет незавершаемости (логических ошибок, могущих привести к бесконечному циклу для некоторых input'ов)

                                                                                                и это только самый простой пример (самое актуальное это, наверное, анализ worst-case execution time для автоматической мемоизации и замены ленивости на энергичность)

                                                                                                это невозможно в Тьюринг-полном языке

                                                                                                решение есть — программировать на ограниченных языках, где эти проблемы разрешимы в общем случае, но мне пока неизвестны ни примеры, ни то, насколько это могло бы быть удобно
                                                                                                  0
                                                                                                  Хм... А зачем? Язык программирования - это не средство анализа алгоритма, а средство его записи для некой системы исполнения. Если вы хотите проанализировать алгоритм, так на то есть куча других методов. Те же TLA или Abstract State Machines. Где всякие неполадки в алгоритме вылавливаются очень быстро. В конце концов, можно просто подоказывать теоремы, в том числе и автоматически, в том числе и об программе на императивном языке (даже если есть side-эффекты).
                                                                                                    0
                                                                                                    Язык программирования - это не средство анализа алгоритма

                                                                                                    да ну, а я вот, к примеру, не мыслю Haskell без статической типизации и гарантий exhaustiveness паттерн-матчинга

                                                                                                    что это, как не средства анализа алгоритма?
                                                                                                      0
                                                                                                      Это не средства анализа программы, imho. Это инструмент для того, чтобы избежать некоторых ошибок в его записи. И типизация, и разбор случаев это всё из этой оперы. Ну... Можно так смотреть, по-моему. Можно и с этими инструментами написать корявую программу с корявым алгоритмом. Ну да, кое что будет отловлено.

                                                                                                      Но это всё же не средства анализа, а механизмы для генерации корректного кода. Статическая типизация, кстати, именно для этого предназначена, imho: полиморфизмы всякие, перегрузки функций и тому подобное.

                                                                                                      И, вобщем-то, полный pattern matching нужен тоже для генерации кода, функция должна как-то работать для ВСЕХ значений аргументов, к которым она применяется. Если бы какой-то вариант не был бы описан, то как должна была бы выполнятся программа? Генерировать исключения? Но в Haskell их нет, без специальных монад. Поэтому они пошли по такому вот пути. Всё это махровое моё личное мнение, конечно. Но, вроде, так тоже можно к этому подходить.
                                                                                                0
                                                                                                связанЫ, то есть.
                                                                                                0
                                                                                                >> На практике же компиляторы функциональных языков - доступные нам в ощущениях, а не те, о которых ходят легенды - не умеют сами распараллеливать вычисления так хорошо, как следует из теории.

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

                                                                                                Проблема не в компиляторах, а в том, чтобы эффективно записать программу в функциональной форме, да ещё и так, чтобы она потом эффективно работала. Это настоящий challenge. То есть, понятно, что ping/pong запишется. А вот та же распределённая база данных? Да ещё такая, которая искать умеет эффективно? Где нужно индексы строить за n*log(n) железно, а не с вероятностью, как в quicksort? Это уже начинает вызывать проблемы.
                                                                                            0
                                                                                            согласен
                                                                                            0

                                                                                            производительность программы на С ограничена

                                                                                            Это чем же?


                                                                                            Да и стоимость разработки программы на С намного выше...

                                                                                            В какой области и для чего? Я согласен, что erlang будет хорошо работать в сфере коммуникаций и т.п. подобных задач, которые хорошо укладываются в модель erlang. Но вот писать на нем прикладной софт... к примеру тот медиа-проигрыватель или IM-клиент это знаете из разряда мазохизма.
                                                                                              0
                                                                                              Ну. IM-клиент - это тоже коммуникация. И пишется довольно просто. И не только IM. А проигрыватель проигрыватель из-за кодеков, да - уже мазахизм.
                                                                                                0
                                                                                                Я говорю не про CLI IM-клиент, а про что-то типа Pidgin хотя бы. И мне не кажется что это будет просто. А проигрыватель сложно будет не только из-за кодеков, но еще из-за вывода на экран.
                                                                                                  0
                                                                                                  >а про что-то типа Pidgin хотя бы
                                                                                                  проблема с UI?! см. Wings3d

                                                                                                  >но еще из-за вывода на экран
                                                                                                  с этим как раз не будет никаких проблем :)
                                                                                                    0
                                                                                                    Вы сами пробовали? Как правило вывод на экран в функциональных языках крайне не удобен.
                                                                                                      +1
                                                                                                      Эрланг — гибридный язык. Тело отдельно взятой функции — практически обычный императивный код.
                                                                                                    0
                                                                                                    В качестве GUI в стандартной поставке идет TK, неплохо с erlang стыкующийся по стилю, как мне показалось. Wings3D использует SDL. В теории, можно сделать биндинги и для других библиотек UI.
                                                                                                      0
                                                                                                      Не в биндингах дело, а в том что реализация интерфейса пользователя на императивном языке реализуется проще чем на функциональном.
                                                                                                        0
                                                                                                        Erlang императивен в достаточной мере. Да и отдельно взятый Tcl/Tk, на котором базируется стандартный GUI, не назовешь чисто императивной системой.

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

                                                                                                        PS. Я, конечно, не буду спорить, что Erlang изначально для создания GUI-приложений не предназначен. Но, тем не менее, получаться может вполне неплохо.
                                                                                                          0

                                                                                                          Я, конечно, не буду спорить, что Erlang изначально для создания GUI-приложений не предназначен. Но, тем не менее, получаться может вполне неплохо.

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

                                                                                                          посмотрите, к примеру, Functional Reactive Programming — есть даже JavaScript-фреймворк в этой парадигме (FLAPJAX)

                                                                                                          там вы декларативно (а не императивно) описываете интерактивность — что позволяет с легкостью реализовать это в любом функциональном языке

                                                                                                          кстати, WPF/XAML в .NET 3 — живой пример этому (Bindings в XAML — это FRP), ведь XAML это вполне себе декларативный язык, многое можно сделать в нём даже без императивного code behind
                                                                                                            0
                                                                                                            Извините меня, но вы не считаете, что приобразовывать GUI в dataflow а затем их обрабатывать довольно странное IMHO дело и требует дополнительной прослойки между GUI тулкитом (который кстати как раз написан на императивном языке) и собственно фукнциональным языком? В случае веба это конечно удобно поскольку там уже есть такая прослойка, которая в указанной вами парадигме может быть тоньше. Но вот в случае GUI мне кажется она будет толще.
                                                                                                              0
                                                                                                              а чем в вашем понимании интерфейсы в вебе отличаются от "GUI"?

                                                                                                              не вижу никакого криминала, кстати, в преобразовании declarative -> imperative, декларативный код сам по себе святым духом исполняться не будет ведь

                                                                                                              а FRP возможен в любом языке, хоть в C

                                                                                                              функциональное/декларативное программирование не привязано к языку, просто в языке, который на семантическом и синтаксическом уровне поддерживает такой стиль — это делать проще, только и всего

                                                                                                              к примеру, в .NET всё это дело прекрасно живет в среде императивного C#, просто из-за негибкости языка пришлось сделать доп. декларативную прослойку в виде XAML, в случае Haskell или Erlang этого делать бы не пришлось
                                                                                                                0

                                                                                                                а чем в вашем понимании интерфейсы в вебе отличаются от "GUI"?

                                                                                                                Вообще-то они различаются подходами и механизмами. И кстати очень сильно.


                                                                                                                не вижу никакого криминала, кстати, в преобразовании declarative -> imperative, декларативный код сам по себе святым духом исполняться не будет ведь

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


                                                                                                                функциональное/декларативное программирование не привязано к языку.

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

                                                                                                                  не вижу разницы — это интерфейс человек-машина, мышкоклавиатурновизуальный

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

                                                                                                                  >> Пока не появится машины которая будет выполнять функциональный язык на уровне железа будет всегда наблюдаться преобразование функционал в императив.

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

                                                                                                                  >> Но вот количество затраченных ресусров может сильно различаться для разных задач.

                                                                                                                  именно это я и сказал — FRP проще в функциональном языке

                                                                                                                  а учитывая то, что FRP проще "императивной интерактивности" следует то, что программировать GUI в функциональных языках — проще
                                                                                                                    0

                                                                                                                    не вижу разницы — это интерфейс человек-машина, мышкоклавиатурновизуальный

                                                                                                                    Механизмы что заложенны в их основе и то как они организовываются различны и очень сильно различны. Сравните к примеру CGI с тем же QT или GTK и поймете чем разница.


                                                                                                                    просто сегодня еще есть это разделение из-за несовершенства технологий, а завтра его уже не будет

                                                                                                                    Для того чтобы убрать разницу вам потребуется немного немало, а сломать нафиг весь современный веб.


                                                                                                                    такого железа никогда не появится

                                                                                                                    В 70-80 годах строили lisp машины. В их разработке кстати участвовал Столлман.


                                                                                                                    именно это я и сказал — FRP проще в функциональном языке

                                                                                                                    Вообще-то я говорил про то что многие задачи проще решаются на императивных языках.

                                                                                                                    а учитывая то, что FRP проще "императивной интерактивности" следует то, что программировать GUI в функциональных языках — проще

                                                                                                                    Ну если вы так настаиваете, то я вам советую написать простой почтовый GUI-клиент который имеет настройку pop3 ящика отображения списка почты пометку того что оно прочитанно и вывод письма в виде плантекста, сначала на erlang а затем на императивном языке. К примеру java, а затем сравните объем кода который потребуется для работы логики интерфейса.
                                                                                                                      0
                                                                                                                      >> Сравните к примеру CGI с тем же QT или GTK и поймете чем разница

                                                                                                                      CGI - это common gateway interface? ну и как его можно сравнивать с GUI фреймворком? это же разные вещи

                                                                                                                      вот например Yahoo UI library для яваскрипта и GTK очень даже можно сравнить

                                                                                                                      >> В 70-80 годах строили lisp машины.

                                                                                                                      это были просто беспомощные игрушки, они были слишком сложные, чтобы работать эффективнее, чем Core 2 :)

                                                                                                                      сложные вещи не работают

                                                                                                                      >> Вообще-то я говорил про то что многие задачи проще решаются

                                                                                                                      многие — это какие? не будьте голословны

                                                                                                                      я пока не вижу ни одной large-scale задачи, которая проще решается на императивном языке

                                                                                                                      существует критерий эффективности рендеринга в hardware execution модель — здесь императивные языки, безусловно, обладают большим потенциалом, т.к. они ближе к этой модели

                                                                                                                      но чтобы простота и в императивном языке — я такого не видел

                                                                                                                      >> Ну если вы так настаиваете, то я вам советую написать простой почтовый GUI-клиент

                                                                                                                      я вас уверяю, что на Erlang кода будет меньше и он будет чище, чем с Java — это подсказывает мне мой опыт в императивных и функциональных языках

                                                                                                                      сделать для Erlang биндинг к какому-нибудь рендереру для рисования "квадратиков и кнопочек" — много ума не надо

                                                                                                                      разумеется, если мне надо будет написать почтовый клиент для десктопа — я возьму WPF а не erlang, потому что для Erlang надо писать биндинги, а WPF уже сегодня работает из коробки
                                                                                                                        0

                                                                                                                        CGI - это common gateway interface? ну и как его можно сравнивать с GUI фреймворком? это же разные вещи

                                                                                                                        То что это разные вещи я знаю и без вас. Это вы уверяете, что нет никакой разницы между обычным веб-приложением и десктоп-приложением. А вообще эта разница есть.


                                                                                                                        вот например Yahoo UI library для яваскрипта и GTK очень даже можно сравнить

                                                                                                                        Их можно сравнить только как средства построения интерфейса.


                                                                                                                        сложные вещи не работают

                                                                                                                        Среда обеспечивающая работу Erlang сложна, но при этом она работает.



                                                                                                                        не будьте голословны

                                                                                                                        GUI-приложения, различные десктопные окружения аля KDE.


                                                                                                                        я пока не вижу ни одной large-scale задачи, которая проще решается на императивном языке

                                                                                                                        Какие из? Таких задач довольно много. К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.


                                                                                                                        я вас уверяю, что на Erlang кода будет меньше и он будет чище, чем с Java — это подсказывает мне мой опыт в императивных и функциональных языках

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


                                                                                                                        сделать для Erlang биндинг к какому-нибудь рендереру для рисования "квадратиков и кнопочек" — много ума не надо

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


                                                                                                                        разумеется, если мне надо будет написать почтовый клиент для десктопа — я возьму WPF а не erlang, потому что для Erlang надо писать биндинги, а WPF уже сегодня работает из коробки

                                                                                                                        Это просто целесообразнее и даст более быстрый результат. Собственно о чем я и толкую.
                                                                                                                          0
                                                                                                                          >> А вообще эта разница есть.

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

                                                                                                                          >> Среда обеспечивающая работу Erlang сложна, но при этом она работает.

                                                                                                                          вам кажется — на самом деле, оптимизирующий компилятор C++ с поддержкой OpenMP на порядок сложнее виртуальной машины Эрланга

                                                                                                                          >> GUI-приложения, различные десктопные окружения аля KDE.

                                                                                                                          хочется продолжить: .. операционные системы :)

                                                                                                                          *thumbs up*

                                                                                                                          >> чтобы получить меньше кода чем на императивном языке

                                                                                                                          вообще-то, объем код сокращается не языком, а программными абстракциями, например — FRP

                                                                                                                          абстракции проще моделировать на функциональном языке — это факт

                                                                                                                          >> К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.

                                                                                                                          а я бы использовал там Erlang - для распределенности, а числодробилку вынес бы в C-код

                                                                                                                          получилось бы очень эффективно и малой ценой

                                                                                                                          многие числодробильные задачи раскладываются на scatter/gather, т.е. параллелизм по данным
                                                                                                                            0

                                                                                                                            для меня, как для пользователя — разницы нет

                                                                                                                            Пользователя вообще не волнует что там работает. Но мы то свами смотрим изнутри а не снаружи.


                                                                                                                            а самом деле, оптимизирующий компилятор C++ с поддержкой OpenMP на порядок сложнее виртуальной машины Эрланга

                                                                                                                            Компилятор с виртуальной машиной сравнивать не корректно. Если кто-то начнет сделает компилятор Erlang то я не думаю что он будет напорядок проще чем компилятор C++ с поддержкой OpenMP.


                                                                                                                            хочется продолжить: .. операционные системы :)

                                                                                                                            И они тоже. :)


                                                                                                                            вообще-то, объем код сокращается не языком, а программными абстракциями, например — FRP

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


                                                                                                                            абстракции проще моделировать на функциональном языке — это факт

                                                                                                                            Не всегда. Зависит от предметной области. Я просто когда диплом писал читал одну замечательную работу в которой математики моделировали биллинг математическими методами. Мягко говоря это было нечто. Особенно порадовало то как они выводили ту модель которая бы позволила им универсально обрабатывать услуги.


                                                                                                                            а я бы использовал там Erlang - для распределенности, а числодробилку вынес бы в C-код
                                                                                                                            получилось бы очень эффективно и малой ценой

                                                                                                                            И требовала бы человека который все это знает. К тому же OpenMP это тоже позволяет, хотя возможно и более затратно нежели это делает Erlang.


                                                                                                                            многие числодробильные задачи раскладываются на scatter/gather, т.е. параллелизм по данным

                                                                                                                            Вот на это Erlang хорошо заточен в силу того куда он специализируется. Для софтовой начинки различного телекоммуникационного оборудования очень удобная штука.
                                                                                                                              0
                                                                                                                              >> Если кто-то начнет сделает компилятор Erlang

                                                                                                                              у эрланга и так есть JIT-компилятор HiPe, да и мы сейчас сравниваем существующие уже сегодня решения для параллелизма — Эрланг проще на порядок и на прикладном уровне эффективнее, чем C++ с OpenMP, факт

                                                                                                                              >> К тому же OpenMP это тоже позволяет

                                                                                                                              OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено — какой смысл запускать моделирование погоды на одном компе, пусть и с 32-ядерным процессором

                                                                                                                              P.S. тред уже слишком затянулся, хабр начинает глючить при таком уровне вложенности
                                                                                                                                0
                                                                                                                                OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено

                                                                                                                                Уже может, есть Intel Cluster OpenMP.

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

                                                                                                                                  на Erlang'е распределенную систему сделать в разы проще, чем на C++

                                                                                                                                  вы понимаете, что железо сегодня стоит дешевле, чем работа квалифицированых C++ программистов, обеспечивающих отсутствие в необходимости покупать это железо?
                                                                                                                                    0
                                                                                                                                    Где вы в нём видите "разы"? Я выше уже говорил про кластерный вариант OpenMP, например, который сведёт на нет любые преимущества.

                                                                                                                                    А когда начнётся бум, программист на Erlang будет стоить соизмеримо с программистом на C.
                                                                                                                            0

                                                                                                                            К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.

                                                                                                                            Значит, он еще просто не популярен в этой отрасли. Кстати, наверняка, зря не используют. В моем понимании, Erlang там очень подойдет.
                                                                                                                              0
                                                                                                                              Не факт, что подойдет. Все сильно зависит от задачи. Если там большой упор на числодробление, то лучше будет чистый C.
                                                                                                                                0
                                                                                                                                числодробление эффективнее разнести на кучу разных компов — а для этого лучше Erlang
                                                                                                                                  0

                                                                                                                                  лучше будет чистый C

                                                                                                                                  Который рискует проиграть в других факторах - скорость и стоимость разработки, надежность, масштабируемость...
                                                                                                                                  Хотя это все уже вопрос реализации.
                                                                                                                                +1
                                                                                                                                К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.
                                                                                                                                Да что уж говорить, в таких задачах и Fortran до сих пор используют, и не жалеют об этом ;)
                                                                                                                                  0
                                                                                                                                  Фортран обычно используют исторически поскольку перенести на другой язык кучу кода довольно трудоемкая задача.
                                                                                                                                    0
                                                                                                                                    Знаю, та ещё морока переписывать, учитывая различие в хранении матриц и индексировании с единицы.
                                                                                                                              +1

                                                                                                                              Сравните к примеру CGI с тем же QT или GTK

                                                                                                                              Вот тут вы смешиваете теплое с мягким. CGI к UI не имеет отношения явно.

                                                                                                                              сломать нафиг весь современный веб

                                                                                                                              Собственно, к этому дело и идет. А вообще, что вы имеете ввиду под "современный веб"?

                                                                                                                              написать простой почтовый GUI-клиент

                                                                                                                              Занятная идея для саморазвития, надо попробовать. =)
                                                                                                                                0

                                                                                                                                Вот тут вы смешиваете теплое с мягким. CGI к UI не имеет отношения явно.

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


                                                                                                                                Собственно, к этому дело и идет. А вообще, что вы имеете ввиду под "современный веб"?

                                                                                                                                http протокол и собственно методы взаимодействия клиента и сервера.


                                                                                                                                Занятная идея для саморазвития, надо попробовать. =)

                                                                                                                                Попробуйте. Для понимания почему это не стоит делать это сделать стоит.
                                                                                                                                  0
                                                                                                                                  >> http протокол и собственно методы взаимодействия клиента и сервера.

                                                                                                                                  вот недавно писал терминал на Flex/ActionScript с сервером на PHP — никакого http протокола я не видел, работал на уровне SOAP-вызовов

                                                                                                                                  пересылку по HTTP за меня делала программная абстракция

                                                                                                                                  и "взаимодействие клиента и сервера" свелось в коде к прямому вызову функций
                                                                                                                                    0

                                                                                                                                    вот недавно писал терминал на Flex/ActionScript с сервером на PHP — никакого http протокола я не видел, работал на уровне SOAP-вызовов

                                                                                                                                    Во флеше так можно. Еще четыре года назад мы предлагали одному товарищу написать интерфейс целиком на флеше, а с сервером обмениваться при помощи XML. А я вообще-то говорил про взаимодействие браузера с сервером через протокол http.
                                                                                                                                      0
                                                                                                                                      Flex это и есть флеш (абстракция над ним)

                                                                                                                                      >> А я вообще-то говорил про взаимодействие браузера с сервером через протокол http.

                                                                                                                                      угу, вот мой терминал работает в браузере и взаимодействует с сервером через протокол http — хоть я напрямую и не работаю с http

                                                                                                                                      что я делаю не так? :)

                                                                                                                                      как мне увидеть разницу-то?
                                                                                                                                        0
                                                                                                                                        В случае флеша вы его не увидите. Но флеш вообще-то не является частью бразуера. И если я удалю флеш-плагин, то ваш сайт перестанет рабоать. К тому же в случае флеша http не более чем транспорт используемый для SOAP.
                                                                                                                                          0
                                                                                                                                          нет, ну вы конечно сейчас забрели в какие-то логические дебри

                                                                                                                                          флеш является частью браузера, пусть и опциональной

                                                                                                                                          точно так же можно сказать — javascript не является частью браузера, ведь его можно отключить!

                                                                                                                                          короче, ответьте на вопрос — чем для программиста десктоп-приложения отличаются от веб-приложений?

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

                                                                                                                                    Аналог CGI есть внутри каждого фреймвока аля QT

                                                                                                                                    А можно более конкретно? Что вы назовете аналогом CGI в том же QT? Я просто не могу провести аналогию... Вообще, AFAIK, CGI - это стандарт имеющий мало отношения к непосредственно интерфейсу пользователя, это интерфейс связи.

                                                                                                                                    Далее, латентность. Как она зависит от парадигмы языка реализации интерфейса? Латентность, в данном случае, вопрос лишь канала связи.

                                                                                                                                    http протокол...

                                                                                                                                    А это-то причем? Для кода UI это все закрыто бесчисленными абстракциями.
                                                                                                                                      0

                                                                                                                                      Вообще, AFAIK, CGI - это стандарт имеющий мало отношения к непосредственно интерфейсу пользователя, это интерфейс связи.

                                                                                                                                      Это скорее интерфейс преобразования. Он преобразовывает полученные сервером от бразуера пользователя данные в более удобосваримый формат. В случае QT эта та часть которая переводит нажатие клавиши пользователя в событие которое затем вызывает какой либо метод.


                                                                                                                                      Далее, латентность. Как она зависит от парадигмы языка реализации интерфейса? Латентность, в данном случае, вопрос лишь канала связи.

                                                                                                                                      А причем тут парадигма языка реализации интерфейса? Я про парадигму самого интерфейса. Методики построения эффективных веб-интерфейсов и десктоп-интерфейсов различаются.


                                                                                                                                      А это-то причем? Для кода UI это все закрыто бесчисленными абстракциями.

                                                                                                                                      При том что в каждом вебфремворке его прийдется учитывать и использовать.
                                                                                                                                      Да скажите вы вообще веб-приложения писали?
                                                                                                                                        0
                                                                                                                                        >> Методики построения эффективных веб-интерфейсов и десктоп-интерфейсов различаются.

                                                                                                                                        это неправда, они ничем не отличаются

                                                                                                                                        говорю вам, как разработчик вебсервисов и десктоп-приложений
                                                                                                                                          0
                                                                                                                                          Если вы пишете на флеше то не различается.
                                                                                                                                            0
                                                                                                                                            интересно, а вот если я на javascript пишу, то, типа, различается?

                                                                                                                                            вот я использую jQuery и Yahoo UI library — библиотеки для яваскрипта, и тоже — ничем не отличается
                                                                                                                                          0

                                                                                                                                          вы вообще веб-приложения писали?

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


                                                                                                                                          Я про парадигму самого интерфейса.

                                                                                                                                          Простите, а что есть императивность и декларативность в случае интерфейса? Точнее, являются ли они чем-то кроме методики реализации его?

                                                                                                                                          Веб-фреймворк - это уровень абстракции, "учитывать и использовать" это его задача. Причем тут непосредственно UI, о которых изначально шла речь?

                                                                                                                                          Это скорее интерфейс преобразования.

                                                                                                                                          Это интерфейс связи между UI и серверной частью. Формально говоря, это даже интерфейс связи между веб-сервером и непосредственно обаботчиком. Повторяюсь, причем здесь собственно UI?
                                                                                                                                            0

                                                                                                                                            Точнее, являются ли они чем-то кроме методики реализации его?

                                                                                                                                            Если вы вернетесь к началу то увидите что я говорил про подходы реализации.


                                                                                                                                            Веб-фреймворк - это уровень абстракции, "учитывать и использовать" это его задача. Причем тут непосредственно UI, о которых изначально шла речь?

                                                                                                                                            Повторяюсь, причем здесь собственно UI?

                                                                                                                                            UI тут вообще не причем. Я говорил про разные подходы используемые при создании web-приложения и desktop-приложения. Если вы считаете что нет никакой разницы, то скажите мне что одинакового у django MVC-вебфреймворка и у QT-тулкита именно на уровне реализации.
                                                                                                                                              0
                                                                                                                                              Погодите. А мы вообще с чего начинали разговор. Точнее, причем тут уровень реализации? Естессна, там ничего одинакового нет.
                                                                                                                                                0
                                                                                                                                                Дааа. Мы похоже как котёнок и щенок которые ели сосиску, встретились по середине :)))
                                                                                                                        +2
                                                                                                                        Да, раз уж пошел разговор за GUI. А не кажется ли вам, что большая часть фреймворков, по меньшей мере на десктопе, построена на сообщениях? Да, вокруг этого есть ОО-обертки, но механизмы сообщений все еще активно используются. Теперь взглянем на Erlang, и что мы видим? Ту же концепцию сообщений, только в профиль. Т.е. для взаимодействия с большей частью UI-систем Erlang подходит просто-таки на уровне концепции.
                                                                                                                          0
                                                                                                                          В случае erlang вам прийдется вместо каждого объекта плодить процесс, что приведет к усложению кода. И как мне кажется вызов метода объекта по событию будет менее трудоемко. Я отлично понимаю что создание процесса в ерланге дешево, но поблема у вас начнет возникать когда их будет много.
                                                                                                                            +1

                                                                                                                            вызов метода объекта по событию будет менее трудоемко

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

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

                                                                                                                            Процесс плодить для каждого примитива не придется. Значительная часть примитивов обслуживается фремворком или ОС.
                                                                                                                              0

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

                                                                                                                              Не забывайте еще про генерацию.


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

                                                                                                                              Это сильно зависит от их количества.


                                                                                                                              Процесс плодить для каждого примитива не придется.

                                                                                                                              Это уже будет зависеть от задачи и того как реализовано.
                                                                                                                                0

                                                                                                                                Не забывайте еще про генерацию.

                                                                                                                                На уровне Erlang VM, опять таки, это должно быть очень оптимизировано. Разницы-то особой и нет, что фреймворк поймает сообщение от ОС и вызовет метод объекта, что фреймворк отправит соответственное сообщение процессу.


                                                                                                                                Это сильно зависит от их количества.

                                                                                                                                Которое уже зависит "от задачи и того как реализовано".

                                                                                                                                Кстати, еще интересно, что "тяжеловеснее" - множество процессов, обменивающихся сообщениями, или множество объектов, обменивающихся вызовами методов. =)
                                                                                                                                  0

                                                                                                                                  Кстати, еще интересно, что "тяжеловеснее" - множество процессов, обменивающихся сообщениями, или множество объектов, обменивающихся вызовами методов.

                                                                                                                                  Зависит от реализации обмена сообщениями и переключения между процессами. Так что может быть и тяжеловеснее.
                                                                                                                                    0
                                                                                                                                    Ну, это само собой разумеется. Я вообще изначально старался избегать вопроса производительности, чтобы избежать конкретики, ибо производительность уже зависит в-основном от реализации.
                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                  0
                                                                                                                  А стоимость обучения персонала?
                                                                                                              0
                                                                                                              Отличный язык, когда создадут 128 ядерный процессор, он станет работать также быстро, как вас старый С на дуал коре. Отличный язык.
                                                                                                                +1
                                                                                                                да ты ебанись
                                                                                                                  +1
                                                                                                                  А вы озадачьтесь вопросом, насколько производителен будет "старый С" на 128-ядерном процессоре.
                                                                                                                  +3
                                                                                                                  Я что-то не очень понимаю каким образом (барабанная дробь) Concurrency Oriented Programming связано с вычисление площади кружочка.
                                                                                                                  Почему-бы не привести в пример какое-то более мотивированное и связанное с сутью языка применение.
                                                                                                                  Честно говоря, уже утомили примеры кода "как я в одну строчку пишу никому не нужный функционал, а на Java/C++/C# эта функция занимает 5 строчек, хотя ее кроме как на уроке информатики никто никогда не напишет".
                                                                                                                    0
                                                                                                                    статья написана техническим "евангелистом" — задача была поднять интерес общественности к Erlang, а не грузить техническими подробностями

                                                                                                                    это что-то вроде интро

                                                                                                                    пример кода был дан чтобы показать мощь pattern matching для декомпозиции структур данных / мульти-диспатча — на Erlang только так и программируют
                                                                                                                      0
                                                                                                                      btw, добавил в конец статьи пример с ping-pong
                                                                                                                      0
                                                                                                                      Пример очень похож на маркетинговую политику компании Ectaco - что мешало все определения классов на яве запихать в библиотеку, ведь это и сделано на примере Erlang? А в остальном - наверное правда... в институте писал простенькие игрухи, где каждым юнитом AI управлял отдельный поток - и на многоядреных процессорах было опять же пропорциональное увеличение производительности... Но это все сугубо ИМХО
                                                                                                                        0
                                                                                                                        в Vendetta Online, AI на сервере как раз на ерланге сделали :)
                                                                                                                          0
                                                                                                                          у мну все на дельфе было - результат один - если проектировать сразу под многоядреные системы - (квази)такая картина будет наблюдаться независимо от языка реализации
                                                                                                                        0
                                                                                                                        Ну и толку в этой рекламе? Покажите мне серьезный работающий пример. Черт возьми, да хотя бы один паттерн. Я знаю как пользоваться гуглом, я нашел какую-то книгу, но пока такого примера нет в этом посте, он для меня просто реклама, восторженное эссе маркетолога ниочем.
                                                                                                                          0
                                                                                                                          вы зря.
                                                                                                                          на ерланге пишут часто. CouchDB - последнее что мне попадалось.
                                                                                                                            +1
                                                                                                                            Скорее всего это и есть реклама. Попытка заинтересовать людей Эрлангом.
                                                                                                                            Тоже неплохо.
                                                                                                                              0
                                                                                                                              Amazon SimpleDB — плохой пример?
                                                                                                                                0
                                                                                                                                предполагается, что тех, кого заинтересует Erlang сами найдут любые технические подробности — в том же гугле

                                                                                                                                >> восторженное эссе маркетолога ниочем

                                                                                                                                не "ни о чём", а про Erlang

                                                                                                                                без рекламы вы бы про Erlang вообще не услышали
                                                                                                                                  0
                                                                                                                                  перефразирую: зачем реклама такая длинная? Я потратил 5 минут своего времени на фигню. Я честно пытался найти в тексте что-то стоящее.
                                                                                                                                    0
                                                                                                                                    вы потратили 5 минут времени на то, чтобы узнать, что есть вот такая штука — Erlang, и "о чём" эта штука

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

                                                                                                                                    вам что, надо Hello World но в терминах message-passing? классический пример "ping-pong" или thread ring? вы потратите куда больше времени, чем 5 минут на то, чтобы разобрать такой код на незнакомом языке, а практическая ценность такого кода не больше, чем "вычислить площадь с pattern matching"

                                                                                                                                    хотите "реальных примеров" — скачайте ejabberd в исходниках
                                                                                                                                      0
                                                                                                                                      мне кажется Вы прекрасно поняли что я имел ввиду. Но все-таки я поясню: я захожу на хабр, открываю пост с интересным заголовком и вижу спам, я пробегаю глазами первый абзац - это все ещё спам, второй - нет результата. Но заголовок интересный а пост большой, я продолжаю читать. Я прочитываю ВЕСЬ пост, все несколько абзацев спама и не нахожу ничего интересного, т.е. вообще ничего. Уберите рекламные обороты и текст сократится в 3 раза, а то и больше.

                                                                                                                                      Мне не нравится что прочитав так много я получил так мало, вот и всё. Если бы пост был маленьким, то я бы просто ознакомился с ним и успокоился.
                                                                                                                                        0
                                                                                                                                        специально для вас — добавил в конец статьи пример с ping-pong

                                                                                                                                        спама на хабре хватает, а это статья, которая полезна людям, разрабатывающим распределенные приложения (скалируемый server-side, например, в контексте веба)

                                                                                                                                        >> второй - нет результата.

                                                                                                                                        почему же, есть результат — посмотрите на кол-во комментов к статье, куча народу сегодня узнали про Erlang

                                                                                                                                        >> Уберите рекламные обороты и текст сократится в 3 раза, а то и больше.

                                                                                                                                        и что от статьи останется? "есть вот такая штука Erlang, да, вот такие-то цифры показывают то-то", очень интересная статья

                                                                                                                                        а главное, что тогда задачи своей она не выполнит — не вызовет интереса
                                                                                                                                          –1
                                                                                                                                          ну не знаю, не знаю. Я обычно статьи написанные в таком стиле пропускаю на автомате. А интерес можно вызывать и по другому, ближе к техническим деталям.
                                                                                                                                            0
                                                                                                                                            >> ближе к техническим деталям

                                                                                                                                            ну это будет совсем другая статья и не совсем про Erlang

                                                                                                                                            к примеру, чтобы объяснить нетривиальность распараллеливания в языках с shared memory надо целую книгу написать

                                                                                                                                            без таких "рекламных" статей у языка никогда не появится такого же комьюнити, как у Ruby или Python — Erlang существует уже пару десятков лет, но до недавнего времени о нём вообще никто не слышал
                                                                                                                                +1
                                                                                                                                сравнивать erlang с Си (как там люди вверху делали) - абсурд. На си для 128-ядерного сервера всегда будет можно написать монстроидальное приложение, загрузив сервер на максимум. Вот только времени это займёт - тонну.

                                                                                                                                Сравнивать ерланг по производительности с чем-то там ещё вообще нет смысла. Суть-то в том, что даже на питоне занять 128 ядер можно (пока) только форкая процессы. Тут 3 месяца назад была задачка - многопоточный парсинг лога, которая превратилась в конкурс (погуглите). Так вот там на ерланге за полчаса кто-то наваял малююююсенькую штучку которая просто разорвала питон и все остальное (даже си). Ребята всполошились и понеслась... в течении недели все улучшали код на разных языках. Питон потом обогнал ерланг (но ТАКОЙ ценой, стоило только посмотреть что было в исходниках чтобы понять сложность). Затем кто-то вывел в перёд перл, и так он там и остался. Вот только код на перле тоже был сумасшедшим. И всего на чуть-чуть процентов быстрее чем на ерланге =). Собственно - полчаса vs неделя? Ни один сервер не стоит столько денег, сколько составила бы разница в стоимости разработчиков для большого проекта.
                                                                                                                                  0
                                                                                                                                  А подробности можно?
                                                                                                                                    0
                                                                                                                                    поиск в Google: "Wide Finder"
                                                                                                                                    0
                                                                                                                                    можно ссылку?
                                                                                                                                      0
                                                                                                                                      Проект называется Wide Finder
                                                                                                                                      Все началось с публикации Tim Bray http://www.tbray.org/ongoing/When/200x/2… и проект продолжил шествие
                                                                                                                                      * http://www.tbray.org/ongoing/When/200x/2…
                                                                                                                                      * http://www.dalkescientific.com/writings/…
                                                                                                                                      0
                                                                                                                                      ээ.. вы про это?
                                                                                                                                      http://www.tbray.org/ongoing/When/200x/2…
                                                                                                                                      далеко не с первой попытки в 10 раз проиграл руби на дуалкоре
                                                                                                                                        0
                                                                                                                                        а вы правила читали? Какой дуалкоре нафик.
                                                                                                                                          0
                                                                                                                                          э, дуалкор появился позже.
                                                                                                                                          покажите мне лучше где там малюсенькая штучка на ерланге за полчаса с лучшим результатом? 300+ строк эрланга против 130 питона и уж тем более 60 перла - это не "малюсенькая", а про полчаса я совсем не нашёл. Java'ы со Scala'ой, жаль, ещё нету, хотя я больше groovy люблю :)
                                                                                                                                            0
                                                                                                                                            да вы же уже результаты смотрите конечные. Эрланга вариантов там и то куча =). Вначале был эрланг который рвал всех (условием был минимум 8-ядерник SUN) и был достаточно прост.

                                                                                                                                            Если бы вы почитали о вариантах на перле и питоне - там не в количествах строк дело, а в абстракции логики. mmap io, chunked reading... это всё весело, но использовать постоянно - нереально (не разумно сложно). Стоит ещё иметь ввиду что задача-то предельно простая =). При более сложной задаче это будет в разы сложнее.

                                                                                                                                            Эрланг тоже не строками мерить надо, а сложностью. Для всех кто понимает эрланг и питон решение на эрланги выглядит проще, чем решение на питоне =).
                                                                                                                                              0
                                                                                                                                              ээ, линк на результаты вы сами дали, это раз, пруфлинк про полчаса и малюсенькую я так и не увидел. Энивэй, жду результатов scala\java
                                                                                                                                                0
                                                                                                                                                ну.. сорри но сейчас уже довольно непросто найти все что происходило =)

                                                                                                                                                там когда запостили впервые о Wide Finder - куча блогов писали о нём, так вот через полчаса кто-то сразу на эрланге прислал решение. В упор не помню кто, а шарахаться по рсскам и анализировать кто же это был - мне тяжеловато. Хотите верьте, хотите - нет =).
                                                                                                                                                  0
                                                                                                                                                  ну, на нет и суда нет ;)
                                                                                                                                        0
                                                                                                                                        А насколько я помню, ситуация была как раз наоборот. Изначально писалось на Erlang, а вот другие уже соревновались с ним. http://www.tbray.org/ongoing/When/200x/2… , а на русском всю суть можно прочитать http://softwaremaniacs.org/blog/2007/10/…
                                                                                                                                        0
                                                                                                                                        выше был пример про атс, но от себя скажу, что если вы пользуетесь сотовой связью, то даже и не подозреваете что эрланг работает на вас каждый день) очень много продуктов эриксона реализовано на эрланге. чаще всего это оборудование радиоподсистемы. gprs-комплекс, а именно sgsn эриксон - чистый эрланг, ну и железо sun) надежность этого продукта действительно высока. да, забавный момент. в швеции чуть ли не каждая вторая компания, делающая продукты для телекома пишет на эрланге.
                                                                                                                                          0
                                                                                                                                          Для телекома эта штука очень удачна.
                                                                                                                                            0
                                                                                                                                            и для веба тоже

                                                                                                                                            просто раньше об этом как-то никто не задумывался
                                                                                                                                          –1
                                                                                                                                          А почему пример кода - не "Hello World"? :))
                                                                                                                                            0
                                                                                                                                            Слишком предвзято. Тот же пример с площадью взять - нужные либы уже есть в Erlang и ими пользуются. Если эти либы были бы написаны для Java, код также был бы из трех строк (со статическими методами Square(..)). Не говорю, что язык плохой, говорю, что стоит почитать другие источники.
                                                                                                                                              0
                                                                                                                                              чтобы читать другие источники — надо сначала заинтересоваться Erlang'ом

                                                                                                                                              в этом и заключается задача статьи
                                                                                                                                                +1