Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
Предположим простую задачу — обработка данных: есть 1) вход (пусть это будет всегда работающий сервер, с которого мы всегда можем прочитать число функцией getServerValue()); 2) Erlang программа на N компьютерах, которая должна раз в секунду вызывать getServerValue() и как-то ее обрабатывать (скажем, прибавлять единичку); 3) удаленный GUI на С++, запущенный на дополнительном компьютере (может тут имеет смысл добавить еще один локальный узел Erlang).
Теперь каждый из N компьютеров под Erlang системой может быть выключен в произвольный момент времени, но гарантируется, что хотя бы один работает всегда. Например, включены K1 K2 K3, через минуту работает только K2, еще через минуту K2 K3 (включился), потом К2 выключается и остается только K3, и т.д.
Какие посоветуете стандартные решения для безопасного автоматического распределения задач по компьютерам и переподключения GUI и насколько сложная получается программа и конфигурация супервизоров (мониторов) для перезапуска процессов?
Здравствуйте, mnf, Вы писали:
mnf>Добрый день!
[cut]
OTP Desing Principles читал?
К примеру эту главу?
По кластерам ещё вот эта статья наверное будет интересна.
А по поводу задачи — а сервер — это что? Почему не на Эрланге же? Для C++ можно сишную ноду организовать, на плюсах есть epp для более удобной работы с erl_interface.
Здравствуйте, mnf, Вы писали:
mnf>Добрый день!
mnf>Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
We want to make a bank server. The bank server models the behaviour of a real bank. You can deposit money with the bank, query the status of your account and take money out of your account.
Banks, being suspicious by nature do not let you take out more money than you have in your account.
Banks are worried about security and like to offer round-the-clock services. If one of their computer fails they still like to serve their customers. In the event of a failure they like everything to work as if the failure had not occurred. In particular even of a failure they do not want you to remove more money from you account than you have deposited ...
Здравствуйте, Курилка, Вы писали:
К>К примеру эту главу?
Правильно ли я понимаю "Все задействованные ноды должны иметь одинаковое значение параметра distributed и параметра sync_nodes_timeout, иначе поведение системы не определено.", что нельзя к запущенной работающей системе добавить еще один резервный компьютер (cp4@cave) без перезапуска всего? Или предлагается заранее сделать config c сотней фиктивных узлов, а запускать на двух-трех? Тут хорошо рассказано про перезапуск всего приложения, но есть еще и контекст, который тоже нужно как-то передавать (в нашем примере, пусть требуется хранить 3 последних результата GetServerValue()).
К>По кластерам ещё вот эта статья наверное будет интересна.
Здесь немного больше про сохранение состояния: "The key idea is that exactly one server process is responsible for dispatching client requests and updating the states of all servers to keep them in sync.", но появляется вопрос про этот "sync" в случае локальных состояний и сообщений (а не только возвращаемых значений, которые, как мне показалось, и запоминаются). Например, в случае краха { sendCommand(1); sendCommand(2) }, нам придется полностью перезапустить этот процесс, и возможно контроллер получит подряд command(1), command(1), command(2), а то и command(1), command(2), command(1), command(2). Еще интереснее ситуация, когда сервер уже получил ответ gen_server_cluster:handle_call, но успел синхронизовать его только с частью узлов (развалился в update_all_server_state), тогда, в зависимости от того, кто возьмет управление, будут вызваны разные процедуры, некоторые дважды. Т.е. не совсем понятно, как организовывать "транзакционность". Может я не все понимаю (точнее ничего не понимаю в Erlang, как и писал раньше), но на этом этапе мне просто хотелось бы выяснить его применимость к данному классу задач не слишком вникая в детали реализации конкретных модулей. Н-р: "да, существует принципиальная возможность в 10-20 строчках кода организовать расширяемый кластер с полным сохранением внутреннего состояния в случае сбоя N-1 компьютеров", т.е. что-нибудь для начинающих.
Кстати, я не случайно упомянул в первоначальной задаче "раз в секунду" — можно ли из "Erlang soft real-time" сделать нормальный "hard real-time" какими-нибудь требованиями к программе и оборудованию (скажем, "если в программе самый длинный путь исполнения request/reply не более 100 команд, OS отдает не меньше 80% 1Ghz СPU на N — 1 гарантировано работающих компьютерах и в задаче нет вызовов внешних библиотек, то гарантирутся время отклика X мс."), и если нельзя, то почему?
К>А по поводу задачи — а сервер — это что? Почему не на Эрланге же?
Это удаленный "ввод", скажем контроллер, с которого можно прочитать данные по ModBus (два канала на два компьютера) или удаленный TCP сервис, и Erlang туда не влезет. Пока для простоты рассматривается теоретическая задача с тремя составляющими ("ввод", "обработка", "вывод"), реальная же будет чуть-чуть сложнее — десятки (может больше) IO контроллеров и управляющих клиентов и нужно понять, как это сделать проще и надежнее, может Erlang и не самый перспективный вариант (это и есть самый главный вопрос — "что же лучше").
Здравствуйте, mnf, Вы писали:
mnf>Здравствуйте, Курилка, Вы писали:
К>>К примеру эту главу? mnf>Правильно ли я понимаю "Все задействованные ноды должны иметь одинаковое значение параметра distributed и параметра sync_nodes_timeout, иначе поведение системы не определено.", что нельзя к запущенной работающей системе добавить еще один резервный компьютер (cp4@cave) без перезапуска всего? Или предлагается заранее сделать config c сотней фиктивных узлов, а запускать на двух-трех? Тут хорошо рассказано про перезапуск всего приложения, но есть еще и контекст, который тоже нужно как-то передавать (в нашем примере, пусть требуется хранить 3 последних результата GetServerValue()).
Если често — сам пока с такой схемой не разбирался. Вообще у меня в текущей задачке проще схема — есть центральный диспетчер/координатор и, скажем так, "рабочие ноды", которые регистрируются в центральном процессе. Делается довольно просто, но всёж самодельная схема. В отличие от приведённого в доках.
Ну а про фиктивные ноды — наверное да. Т.е. делается некий прогноз, до каких масштабов надо масштабировать, типа того.
А вообще лучше спроси в erlang questions, тебе авторы ответят заметно более обстоятельно и авторитетно, я думаю.
К>>По кластерам ещё вот эта статья наверное будет интересна. mnf>Здесь немного больше про сохранение состояния: "The key idea is that exactly one server process is responsible for dispatching client requests and updating the states of all servers to keep them in sync.", но появляется вопрос про этот "sync" в случае локальных состояний и сообщений (а не только возвращаемых значений, которые, как мне показалось, и запоминаются). Например, в случае краха { sendCommand(1); sendCommand(2) }, нам придется полностью перезапустить этот процесс, и возможно контроллер получит подряд command(1), command(1), command(2), а то и command(1), command(2), command(1), command(2). Еще интереснее ситуация, когда сервер уже получил ответ gen_server_cluster:handle_call, но успел синхронизовать его только с частью узлов (развалился в update_all_server_state), тогда, в зависимости от того, кто возьмет управление, будут вызваны разные процедуры, некоторые дважды. Т.е. не совсем понятно, как организовывать "транзакционность". Может я не все понимаю (точнее ничего не понимаю в Erlang, как и писал раньше), но на этом этапе мне просто хотелось бы выяснить его применимость к данному классу задач не слишком вникая в детали реализации конкретных модулей. Н-р: "да, существует принципиальная возможность в 10-20 строчках кода организовать расширяемый кластер с полным сохранением внутреннего состояния в случае сбоя N-1 компьютеров", т.е. что-нибудь для начинающих.
Чтот читал-читал, так и не смог понять описываемую ситуацию. Про 10-20 строчек сомневаюсь.
По поводу синхронизации состояния есть ещё один вариант — mnesia, правда это скорей для заметных его объёмах и там ещё надо решать вопросы подключения новых нод (дабы синхронизовались таблицы).
+ замечание: в эрланге нет по сути понятия компьютеров, есть ноды, в пределах одного хоста может быть их несколько. mnf>Кстати, я не случайно упомянул в первоначальной задаче "раз в секунду" — можно ли из "Erlang soft real-time" сделать нормальный "hard real-time" какими-нибудь требованиями к программе и оборудованию (скажем, "если в программе самый длинный путь исполнения request/reply не более 100 команд, OS отдает не меньше 80% 1Ghz СPU на N — 1 гарантировано работающих компьютерах и в задаче нет вызовов внешних библиотек, то гарантирутся время отклика X мс."), и если нельзя, то почему?
Вопрос поднимался несколько раз, поищи, например, здесь. Насколько помню строго хард сделать не получится, были какие-то заморочки с приоритетами планировщика Эрланга.
К>>А по поводу задачи — а сервер — это что? Почему не на Эрланге же? mnf>Это удаленный "ввод", скажем контроллер, с которого можно прочитать данные по ModBus (два канала на два компьютера) или удаленный TCP сервис, и Erlang туда не влезет. Пока для простоты рассматривается теоретическая задача с тремя составляющими ("ввод", "обработка", "вывод"), реальная же будет чуть-чуть сложнее — десятки (может больше) IO контроллеров и управляющих клиентов и нужно понять, как это сделать проще и надежнее, может Erlang и не самый перспективный вариант (это и есть самый главный вопрос — "что же лучше").
Тут подобными задачами вроде как gandalfgrey занимался и был вроде как очень доволен Эрлангом. Т.к. я не он, то подробностей не скажу.
Здравствуйте, Gaperton, Вы писали:
mnf>>Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
G>Читай короткий туториал G>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html
Такую систему с двумя полностью независимыми серверами, которые даже не синхронизируют свои внутренние состояния, можно написать практически на чем угодно. В чем преимущества именно Erlang непонятно (а они несомненно должны быть, просто эта статья не о том). os:cmd("rm -rf *") в distributed Erlang вообще пугает, радует, что можно обойтись без него.
G>Читай длинный и исчерпывающий мануал "Making reliable distributed systems in the presence of software errors" G>http://www.erlang.org/download/armstrong_thesis_2003.pdf
eao197>... не дает конкретных рецептов построения систем на Erlang-е.
Не могу не согласиться
Здравствуйте, mnf, Вы писали:
mnf>Здравствуйте, Gaperton, Вы писали:
mnf>>>Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
G>>Читай короткий туториал G>>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html mnf>Такую систему с двумя полностью независимыми серверами, которые даже не синхронизируют свои внутренние состояния, можно написать практически на чем угодно. В чем преимущества именно Erlang непонятно (а они несомненно должны быть, просто эта статья не о том). os:cmd("rm -rf *") в distributed Erlang вообще пугает, радует, что можно обойтись без него.
Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете. Сервера в этом простом примере, кстати, синхронизируют свое внутреннее состояние. Если вас distributed erlang пугает, и вас радует, что можно обойтись без него — обходитесь без него, в чем проблема . Кто заставляет-то — предметом первой необходимости Erlang у нас не является пока слава богу.
G>>Читай длинный и исчерпывающий мануал "Making reliable distributed systems in the presence of software errors" G>>http://www.erlang.org/download/armstrong_thesis_2003.pdf mnf>eao197>... не дает конкретных рецептов построения систем на Erlang-е. mnf>Не могу не согласиться
Соглашайтесь . Пользуйтесь конкретными рецептами построения отказоустойчивых систем на С++ — их, верно, сильно больше, и головой наверно при этом думать не надо .
Здравствуйте, Курилка, Вы писали:
К>Вопрос поднимался несколько раз, поищи, например, здесь. Насколько помню строго хард сделать не получится, были какие-то заморочки с приоритетами планировщика Эрланга.
Вроде бы есть порты Ерланга под QNX и что-то еще, в которых люди правили планировщик и сборку мусора. Получился, по описанию, ПОЧТИ ХАРД реалтайм.
К>Тут подобными задачами вроде как gandalfgrey занимался и был вроде как очень доволен Эрлангом. Т.к. я не он, то подробностей не скажу.
Гм. Не совсем такими, пожалуй. У меня тоже была распределенная сборка и обработка данных, но организация системы совершенно другая.
1. Есть Ерланговские ноды, непосредственно забирающие данные с прибора по TCP/IP. Они могут отвечать на запрос сервера по архивам, но текущие они заливают сами в сервер.
2. Ежели сервер окочурился по какой-то причине ( питание исчезло, сеть легла, глюки... ), то через некое время происходит переключение на следующий сервер из списка.
3. Если сдохла нода нижнего уровня, то сервер ее перезапускает
4. Перезапуском серверов занимается активный в данный момент сервер-концентратор, с которого и берут данные диспетчеры. В него же заливаются данные от серверов среднего уровня, серверов вычислений и пр.
Это очень упрощенная схема, конечно. Но работает очень устойчиво
Здравствуйте, Gaperton, Вы писали:
G>Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете. Сервера в этом простом примере, кстати, синхронизируют свое внутреннее состояние. Если вас distributed erlang пугает, и вас радует, что можно обойтись без него — обходитесь без него, в чем проблема . Кто заставляет-то — предметом первой необходимости Erlang у нас не является пока слава богу.
Оно конечно ! Если уж гайки отвинчивают при помощи двух отверток, то без Ерланга тем более можно обойтись 8))
G>Соглашайтесь . Пользуйтесь конкретными рецептами построения отказоустойчивых систем на С++ — их, верно, сильно больше, и головой наверно при этом думать не надо .
Извинитття ! Работающих рецептов для С++ маловато, и насколько же они все заморочены ! Вот головой в этом случае точно думать не надо будет — ею надо будет колотиться об стол в расстройстве.
Между прочим, даже на Тикле получается в разы проще, чем на С++, всякая распределенность. Вот на предыдущей работе оставил я скриптик на Тикле ( около 200 строк ), который покрывает значительную часть функциональности софтины, написанной на С++ и весящей под 100 К строк. Причем работает УСТОЙЧИВЕЕ...
Так что не надо давать "Вредных Советов". Г.Остер это сделал уже давно
Здравствуйте, Gaperton, Вы писали:
G>Читай короткий туториал G>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html
Туториал хороший, только не рассматривается одна проблема — "split brain". Если у нас теряется связь между первым и вторым сервером (но сами серверы при этом работают!), то у нас в итоге получится inconsistent база-данных.
Для решения этой проблемы можно использовать такие методы: Кворумный диск — сервер может работать, только если у него есть доступ к этому диску. Добавляет single-point-of-failure, но на практике достаточно надежно.
Работать только если у нас есть связь с более чем 50% узлов в кластере (для этого нужно минимум три узла).
Различные комбинации на эту тему: работать, если у нас есть связь с более чем 50% кворумных дисков, работать только если есть связь с кворумным диском или более 50% узлов и т.п.
Здравствуйте, Gaperton, Вы писали:
G>Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете.
Куда уж нам уж. Мы академиев не кончали.
На Эрланге коммерческих проектов с высокими требованиям по надежности не делали. Как, полагаю, и ты.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Читай короткий туториал G>>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html C>Туториал хороший, только не рассматривается одна проблема — "split brain". Если у нас теряется связь между первым и вторым сервером (но сами серверы при этом работают!), то у нас в итоге получится inconsistent база-данных.
Интересно, как в этом случае ведет себя мнезия — ведь это она выполняет репликацию. Я думаю, на самом деле все будет в порядке. Но правда любопытно.
C>Для решения этой проблемы можно использовать такие методы: C> C> Кворумный диск — сервер может работать, только если у него есть доступ к этому диску. Добавляет single-point-of-failure, но на практике достаточно надежно.
Ну, дисков они не разделяют. Мнезия реплицирует таблицы через эрланговские сообщения — двухфазным или трехфазным коммитом.
Вообще, в эрланге этому подходу соответствует супервижн три, достаточно грамотно его построить, ничего другого не нужно.
C> Работать только если у нас есть связь с более чем 50% узлов в кластере (для этого нужно минимум три узла).
Узлы кластера можно увязать в супервижн три, и держать резервного супервизора — тогда все просто и понятно — мы трактуем недоступный узел как отвалившийся. Думаю, так будет нормально. Опять же, интересно, как такие проблемы решает мнезия.
C> Различные комбинации на эту тему: работать, если у нас есть связь с более чем 50% кворумных дисков, работать только если есть связь с кворумным диском или более 50% узлов и т.п.
Ну, типа того. В эрланге стратегию фолт-толеранса полностью выбирает программист, тока опять же — супервижн вместо кворумных дисков. C>
Здравствуйте, eao197, Вы писали:
G>>Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете.
E>Куда уж нам уж. Мы академиев не кончали.
Что-то не понял иронии. Тебе что, исходники megaco, inets, и mnesia читать проще простого туториала с задачей, которую ты легко на любом языке повторишь? Да флаг тебе в руки, господи. Бери стандартную либу и читай исходники, умный ты наш. Академиев он блин не кончал.
E>На Эрланге коммерческих проектов с высокими требованиям по надежности не делали. Как, полагаю, и ты.
Не делал, говоришь? Так чего выступаешь? Может — сказать чего хочешь, а?
Здравствуйте, gandalfgrey, Вы писали:
G>>Соглашайтесь . Пользуйтесь конкретными рецептами построения отказоустойчивых систем на С++ — их, верно, сильно больше, и головой наверно при этом думать не надо . G>Извинитття ! Работающих рецептов для С++ маловато, и насколько же они все заморочены ! Вот головой в этом случае точно думать не надо будет — ею надо будет колотиться об стол в расстройстве.
Да лана, пусть себе колотится, а мы, обезьянки, посмотрим! Этож прикольно.
G>Между прочим, даже на Тикле получается в разы проще, чем на С++, всякая распределенность. Вот на предыдущей работе оставил я скриптик на Тикле ( около 200 строк ), который покрывает значительную часть функциональности софтины, написанной на С++ и весящей под 100 К строк. Причем работает УСТОЙЧИВЕЕ... G>Так что не надо давать "Вредных Советов". Г.Остер это сделал уже давно
Почему это не надо? Очень даже надо . Тебе надо, чтобы все подряд на Эрланге писали? Я вот тут, допустим идеи для стартапа обдумываю разные, и в мои планы совершенно не входит массовое проникновение Эрланга в мэйнстрим. Пусть пишут на Сишарпе, или голом С. Вот С++ с Йавой — это, блин, уже хуже, но тоже ничего.
Здравствуйте, Gaperton, Вы писали:
G>Да лана, пусть себе колотится, а мы, обезьянки, посмотрим! Этож прикольно.
Как-то это негуманно...Поглумиться, конечно, тоже неплохо, но надо и меру знать
G>Почему это не надо? Очень даже надо . Тебе надо, чтобы все подряд на Эрланге писали? Я вот тут, допустим идеи для стартапа обдумываю разные, и в мои планы совершенно не входит массовое проникновение Эрланга в мэйнстрим. Пусть пишут на Сишарпе, или голом С. Вот С++ с Йавой — это, блин, уже хуже, но тоже ничего.
А что Жабба ? Она никак не спасет отцов русской демократии. Мой сотоварищ, нынче работающий в другой конторе, недавно писал — у них изваяли CRM на Жабе, так ей не хватает 8 ГИГ памяти ( оперативной ), чтобы запустииться. Не работать, нет — просто запуститься. Так что тот коллектив как бы разработчиков в печали и унынии...
И вообще, Жаба — это "КОБОЛ наносит ответный удар". Таких же зомбей плодит ( или они сами туда тянутся ). "Fresh BRAINS !" (с) Возвращение живых мертвецофф 5
Здравствуйте, gandalfgrey, Вы писали:
G>И вообще, Жаба — это "КОБОЛ наносит ответный удар". Таких же зомбей плодит ( или они сами туда тянутся ). "Fresh BRAINS !" (с) Возвращение живых мертвецофф 5
Здравствуйте, Gaperton, Вы писали:
G>Интересно, как в этом случае ведет себя мнезия — ведь это она выполняет репликацию. Я думаю, на самом деле все будет в порядке. Но правда любопытно.
Я не использовал Мнезию для серьезной работы, так что не смотрел туда особо внимательно.
Сейчас попробовал найти в доке — похоже, что никак не обрабатывает:
There are several occasions when Mnesia may detect that the network has been partitioned due to a
communication failure.
One is when Mnesia already is up and running and the Erlang nodes gain contact again. Then Mnesia
will try to contact Mnesia on the other node to see if it also thinks that the network has been
partitioned for a while. If Mnesia on both nodes has logged mnesia down entries from each other,
Mnesia generates a system event, called inconsistent database, running partitioned network,
Node which is sent to Mnesia’s event handler and other possible subscribers. The default event handler
reports an error to the error logger.
...
C>>Для решения этой проблемы можно использовать такие методы: C>> Кворумный диск — сервер может работать, только если у него есть доступ к этому диску. Добавляет single-point-of-failure, но на практике достаточно надежно. G>Ну, дисков они не разделяют. Мнезия реплицирует таблицы через эрланговские сообщения — двухфазным или трехфазным коммитом. G>Вообще, в эрланге этому подходу соответствует супервижн три, достаточно грамотно его построить, ничего другого не нужно.
Кворумный диск (точнее, вообще любой кворумный ресурс) используется и если нет разделения дисков, он просто позволяет гарантировать, что система находится в consistent state.
C>> Работать только если у нас есть связь с более чем 50% узлов в кластере (для этого нужно минимум три узла). G>Узлы кластера можно увязать в супервижн три, и держать резервного супервизора — тогда все просто и понятно — мы трактуем недоступный узел как отвалившийся. Думаю, так будет нормально. Опять же, интересно, как такие проблемы решает мнезия.
Насколько я понимаю, supervisor tree не решает эту проблему — просто сдвигает ее со стороны worker nodes на сторону супервизоров. То есть, если у нас отказывает корневой супервизор, то нам надо решить кому стать следующим корнем. И там все те же самые проблемы.
Кстати, мы вообще смотрели как проще делать реплицируемую базу. В итоге, остановились на кластерной файловой системе OCFS2 с избыточной связностью хостов. Там сценарий со split-brain возможен, но для этого требуются очень нереальные условия (падение сразу нескольких интерфейсов на разных хостах, причем одновременно).
Здравствуйте, Курилка, Вы писали:
К>Смотрится оригинально после статеек аля Erlang, the next Java
Посмотрел. Мужик пишет, что Ерланг — это круто, и он будет следующей Жабой по ПОПУЛЯРНОСТИ и весомости. То, что на Жабе пишут все, кому не лень — это я и так отчетливо вижу. На КОБОЛе писали еще больше...
А упоминания про ООП, который в Ерланге моделируется процессами — тоже известная и не новая песня, хотя и верная во многом.
Жаба очень хороша для написания монстров, выползших из упокоищ. Ползущих медленно и распадающихся на ходу. Насколько я помню, самый большой проект на Ерланге — 1.2 М строк ( это пресловутый AXD 301 ). 800 К строк на Жабе — это проект среднего размера, или даже меньше.
Здравствуйте, gandalfgrey, Вы писали:
G>Посмотрел. Мужик пишет, что Ерланг — это круто, и он будет следующей Жабой по ПОПУЛЯРНОСТИ и весомости. То, что на Жабе пишут все, кому не лень — это я и так отчетливо вижу. На КОБОЛе писали еще больше...
Эээ, у тебя есть оф. статистика?
Имхо тогда программеров было как минимум на пару порядков меньше G>А упоминания про ООП, который в Ерланге моделируется процессами — тоже известная и не новая песня, хотя и верная во многом. G>Жаба очень хороша для написания монстров, выползших из упокоищ. Ползущих медленно и распадающихся на ходу. Насколько я помню, самый большой проект на Ерланге — 1.2 М строк ( это пресловутый AXD 301 ). 800 К строк на Жабе — это проект среднего размера, или даже меньше.
Ну дак это пока, хотя конечно он более краток, но нет предела индусописательству
А пресловутый вроде 2 млн строк по последним цифрам вроде
. Кто заставляет-то — предметом первой необходимости Erlang у нас не является пока слава богу. 
