Всем привет!
Уважаемые коллеги, использующие Erlang или просто кто в курсе , просветите в чем выражаются преимущества от использования Erlang-а в проектах, в отличии например от C#? В каких проектах Erlang наиболее силен и опять же за счет чего ?
Подход к www.erlang.org делал, но за несколько вечеров не осилил

Здравствуйте, pavel74, Вы писали:

P>Всем привет!
P>Уважаемые коллеги, использующие Erlang или просто кто в курсе , просветите в чем выражаются преимущества от использования Erlang-а в проектах, в отличии например от C#? В каких проектах Erlang наиболее силен и опять же за счет чего ?
P>Подход к www.erlang.org делал, но за несколько вечеров не осилил

Стоило в этом и других раделах форума лучше искать.

P>Всем привет!
P>Уважаемые коллеги, использующие Erlang или просто кто в курсе , просветите в чем выражаются преимущества от использования Erlang-а в проектах, в отличии например от C#? В каких проектах Erlang наиболее силен и опять же за счет чего ?
P>Подход к www.erlang.org делал, но за несколько вечеров не осилил

Java vs. Erlang
Why I chose erlang (very, very long story)

От себя.

Легкость в создании систем клиент-сервер (например), отсутствие проблем с сериализацией данных (функции term_to_binary, list_to_binary и т.д.), упрощенная работа с двоичными данными (см. bit syntax), наличие весьма неплохих сопутствующих библиотек (inets, file_lib, crypto и так далее), простой (простейший?) способ общения между процессами, first-class functions (не объяснить, что такое, пока сам не попробуешь ), guards

pavel74,

P>Всем привет!
P>Уважаемые коллеги, использующие Erlang или просто кто в курсе , просветите в чем выражаются преимущества от использования Erlang-а в проектах, в отличии например от C#? В каких проектах Erlang наиболее силен и опять же за счет чего ?

1. Функциональный язык, который позволяет сочетать "грязные" конструкции с чистыми и (важно!) отделять грязные конструкции от чистых.
2. Лёгковесные действительно независимые друг от друга процессы (взаимодействие описывается _явно_).
3. Soft realtime.
4. Хорошо портируемый рантайм (ему даже не нужна поддержка многопоточности из ОСи).
5. Инкапсуляция ошибок. Если внутри процесса произойдёт ошибка, то она не затронет другие процессы, если это не прописано _явно_.
6. Возможность как локального так и удалённого обнаружения ошибок.
7. Горячий апгрейд кода.
8...

...и как следствие поддержка создания отказоустойчивых и/или распределённых систем реального времени.

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

Может быть к этому в конце концов придёт Джава или ДотНет, пока трудно сказать. Тенденция есть.

LCR>5. Инкапсуляция ошибок. Если внутри процесса произойдёт ошибка, то она не затронет другие процессы, если это не прописано _явно_.

Это, кстати, надо бы расписать в "Философии", потому что там такое же описывалось для Оберона, но никто так и не смог объяснить точно что и как

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Может быть к этому в конце концов придёт Джава или ДотНет, пока трудно сказать. Тенденция есть.

В каком-то смысле уже идут.
http://research.microsoft.com/os/singularity/

Вот только ты забыл добавить следущие характеристики с которыми не все согласны:
9. Интерпретирвемый язык.
10. Отустувие статической типизации.

Использовать в риалтайм системах может и можно, а вот написать на оном реалтайм-рантайм вряд ли. Хотя железо сейчас конечно многое позволяет, так что как знать.

Мне вот интересно, а на чем написан рантайм Эрлэнга? Сдается мне, что все те же С/С++.

Здравствуйте, VladD2, Вы писали:

VD>Вот только ты забыл добавить следущие характеристики с которыми не все согласны:
VD>9. Интерпретирвемый язык.

А как же HiPe?

Немного перефразирую свой предыдущий вопрос:
Хотелось бы услышать от тех, кто РЕАЛЬНО, использует Erlang в своих проектах, КАКИЕ ощущения от его использования, какие СИЛЬНЫЕ стороны от использования erlang-а ВЫ для СЕБЯ подметили, какие неудобства... ????

Синтаксис я пока не осилил, но если это динамический типизируемый язык (типа Ruby или Smalltalk) — значит должна быть мега-выразительность языка, но что-то я опять же не заметил, может все таки плохо смотрел?

Здравствуйте, Lazy Cjow Rhrr, Вы писали:


LCR>1. Функциональный язык, который позволяет сочетать "грязные" конструкции с чистыми и (важно!) отделять грязные конструкции от чистых.
LCR>2. Лёгковесные действительно независимые друг от друга процессы (взаимодействие описывается _явно_).
LCR>3. Soft realtime.
LCR>4. Хорошо портируемый рантайм (ему даже не нужна поддержка многопоточности из ОСи).
LCR>5. Инкапсуляция ошибок. Если внутри процесса произойдёт ошибка, то она не затронет другие процессы, если это не прописано _явно_.
LCR>6. Возможность как локального так и удалённого обнаружения ошибок.
LCR>7. Горячий апгрейд кода.
LCR>8...
LCR>...и как следствие поддержка создания отказоустойчивых и/или распределённых систем реального времени.
LCR>...

Это все конечно прикольно, но ведь еще надо и саму логику приложения писать (т.е. проектировать классы, взаимодействие между ними, ну и код писать) , отлаживаться... Использовать местную стандартную библиотеку (контейнеры, прочие вкусности). Как со всем этим дела?

P>Хотелось бы услышать от тех, кто РЕАЛЬНО, использует Erlang в своих проектах, КАКИЕ ощущения от его использования, какие СИЛЬНЫЕ стороны от использования erlang-а ВЫ для СЕБЯ подметили, какие неудобства... ????

Где-то пробегала ссылка на товариза, который писал сетевой покер для Маков.
И он пробовал для сервера Delphi, Java, haskel и Erlang.
Там, вроде описано

P>Это все конечно прикольно, но ведь еще надо и саму логику приложения писать
P>(т.е. проектировать классы, взаимодействие между ними, ну и код писать)
Нет там классов, в процедурном смысле паскаля/C++
Там используется идея сообщение/ответ, как в Obj.C, Windows GDI.
RPC и DCOM marshalling собственно и состоят в том, чтобы отобразить одну модель на другую

Соотв. вместо пары объект/методы получается пара процесс-поток/сообщения

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

Тут уже говорили, что многопоточные программы (а именно для программ в сотни/тысячи потоков и создавался эрланг) через GUI отлаживать непонятно как. Но есть нюанс. Библиотека Эрланга српоектированна именно так, чтобы многопоточные моменты были вынесены в стандартные давно и хорошо отлаженные "классы", а реальная работа была в однопоточных "классах" под управлением вышеозначенных многопоточных.

Так что отладка пока и для меня вопрос

Здравствуйте, pavel74, Вы писали:

P>Немного перефразирую свой предыдущий вопрос:
P>Хотелось бы услышать от тех, кто РЕАЛЬНО, использует Erlang в своих проектах, КАКИЕ ощущения от его использования, какие СИЛЬНЫЕ стороны от использования erlang-а ВЫ для СЕБЯ подметили, какие неудобства... ????

Использовал не совсем реально, скорее, подпольно, но довольно много. Ощущение: "ну наконец-то!". Т.е. наконец-то сделали язык, на котором можно писать многопоточные распределенные программы, не заморачиваясь посторонними вещами. Стандартная библиотека на удивление хороша — все, что нужно, есть. Чего нет, можно поискать в jungerl. Чужие программы читаются легко и с удовольствием. Словом, ощущения очень приятные. Что касается IDE, то я в свое время изучил Emacs и теперь никаких языков не боюсь. В комплекте поставляется мода erlang.el, плюс можно поставить ESense, чтобы получить нечто вроде Intellisens-а.

Недостатки? Ну, скажем, gui выглядит убого. Даже странно, как они этого добились. Он основан на Tk, а вообще-то по умолчанию tk-шные программы под виндой выглядят не так гадко. Немного помогает очистка содержимого файла gs-defaults (сам файл удалять не надо, только сделать его пустым). Тогда хотя бы курсор мыши становится приличным.
Еще недостаток: модуль генерации документации edoc (аналог javadoc) не дружит с русским языком. Никак не доходят руки починить и послать патч.

В целом: ощущения сугубо положительные. Очень нравится. Хочу еще.

Здравствуйте, VladD2, Вы писали:

VD>Вот только ты забыл добавить следущие характеристики с которыми не все согласны:
VD>9. Интерпретирвемый язык.
Не то чтоб совсем так. Байт-код, порождаемый компилятором, весьма быстр, И не уступит, к примеру, Жабе по скорости. И это именно КОМПИЛЯТОР.

VD>Использовать в риалтайм системах может и можно, а вот написать на оном реалтайм-рантайм вряд ли. Хотя железо сейчас конечно многое позволяет, так что как знать.
Опять-таки не то говорите. Пару лет писал на Ерланге диспетчерские задачи ( мягкий реалтайм ), работу с железом... Время реакции порядка миллисекунд обеспечиваются свободно, причем на весьма дохлом железе.

VD>Мне вот интересно, а на чем написан рантайм Эрлэнга? Сдается мне, что все те же С/С++.
Только С, и никаких ++. Собственно, как и у большинства других компиляторов и сред выполнения.

Здравствуйте, pavel74, Вы писали:

P>Немного перефразирую свой предыдущий вопрос:
P>Хотелось бы услышать от тех, кто РЕАЛЬНО, использует Erlang в своих проектах, КАКИЕ ощущения от его использования, какие СИЛЬНЫЕ стороны от использования erlang-а ВЫ для СЕБЯ подметили, какие неудобства... ????

Плюсы Ерланга :
Очень легковесные процессы. Я запускал на домашней машине 200 000 процессов без заметных тормозов.
Быстрый и удобный обмен сообщениями. На Пне-4 в среднем занимает 100-300 наносекунд ( в пределах одной виртуальной машины, естественно )
Весьма удобный механизм MATCH PATTERH ( сравнение/совпадение по образцу )
Функции высшего порядка
Очень легкая работа в распределенной среде
Компактный, легко читаемый и достаточно удобопонятный код
Модульная структура, и есть возможность обьединения в пакеты
Весьма изобильные библиотеки. Я построил компилятор спец. языка, пользуясь только штатными средствами Ерланга, за 3 месяца

Минусы :
Как числомолотилка — не покатит. С целыми числами все хорошо, и с большими целыми тоже, а вот производительность на операциях с плавающей точкой — так себе
Нет штатного способа запихать все в один выполняемый файл ( несколько неудобно )
Файловый ввод/вывод мог бы и побыстрее быть. TCP, как ни странно, весьма быстр.

P>Синтаксис я пока не осилил, но если это динамический типизируемый язык (типа Ruby или Smalltalk) — значит должна быть мега-выразительность языка, но что-то я опять же не заметил, может все таки плохо смотрел?
Ерланг ОЧЕНЬ выразителен. Вот пример, который я делал для изучающих язык . Это поиск кратчайшего пути в лабиринте. На мой взгляд, достаточно наглядно и просто. И студенты быстро прониклись...

-module(pfind).
-export([start/0,start/1]).

start()->
start("place.data").

start(Fname)->
Dic=load_data(Fname),
Ldic=link_data(Dic),
StartP=find_pos(Ldic,$a),
EndP=find_pos(Ldic,$b),
io:fwrite("~nstart=~w end=~w ~n",[StartP,EndP]),
IList2=emit_wave(Ldic,[{StartP,0}]],0),
Path=unwind(IList2),
io:fwrite("~nPath=~w ~n",[Path]),
io:fwrite("~nPath length=~w ~n",[length(Path)]),
io:fwrite("~n",[]).

%%% Load data from file into hash
load_data(Fname)->
{ok,Bin1}=file:read_file(Fname),
L1=string:tokens(binary_to_list(Bin1),[10,13]),
{_,Dic}=lists:foldl(fun(Line,{Y,Dic1})->
{_,Dic3}=lists:foldl(fun(C,{X,Dic2})->
{X+1,dict:store({X,Y},C,Dic2)}
end,{0,Dic1},Line),
{Y+1,Dic3}
end,{0,dict:new()},L1),
Dic.

%%%%%% Build links between cells
link_data(Dic)->
dict:fold(fun({X,Y}=K,V,Dic1)->
L1=[{X-1,Y-1},{X-1,Y},{X-1,Y+1},{X,Y+1},{X+1,Y+1},{X+1,Y},{X+1,Y-1},{X,Y-1}],
L2=[Key||Key<-L1,dict:is_key(Key,Dic)],
dict:store(K,{V,L2},Dic1)
end,dict:new(),Dic).

%%%% Find first occurence of tag
find_pos(Dic,C)->
[Pos]=[K||{K,{V,_}}<-dict:to_list(Dic),V==C],
Pos.

%%%%%%% Emit wave
emit_wave(LDic,[Front|_]=IList,Num)->
case step(LDic,Front,[],Num) of
{done,Res}->[Res]|IList];
{LDic1,NF}->emit_wave(LDic1,[NF|IList],Num+1)
end.

%%%%%% Check all points neighbours on wave front
step(LDic,[],NF,_Num)->{LDic,NF};
step(LDic,[{Pt,_}|Rest],NF,Num)->
{_V,Neibs}=dict:fetch(Pt,LDic),
case step_one(LDic,Neibs,NF,Num,Pt) of
{done,Res}->{done,Res};
{LDic1,NF1}->step(LDic1,Rest,NF1,Num)
end.

%%%%%% Check and mark cells around one point
step_one(LDic,[],NF,_Num,_Parent)->{LDic,NF};
step_one(LDic,[Pt|Rest],NF,Num,Parent)->
{V,NB1}=dict:fetch(Pt,LDic),
case V of
$b->{done,{Pt,Parent}};
32->step_one(dict:store(Pt,{Num,NB1},LDic),Rest,[{Pt,Parent}|NF],Num,Parent);
_->step_one(LDic,Rest,NF,Num,Parent)
end.

%%%%%%% Backtrace path from finish to start
unwind([{Coord,Par}]|Rest])->unwind(Par,Rest,[Coord]).
unwind(_Par,[],Path)->Path;
unwind(Par,[Front|Rest],Path)->
[{Coord,Parent}|_]=[{C,P}||{C,P}<-Front,C==Par],
unwind(Parent,Rest,[Coord|Path]).

Здравствуйте, gandalfgrey, Вы писали:

VD>>Мне вот интересно, а на чем написан рантайм Эрлэнга? Сдается мне, что все те же С/С++.
G> Только С, и никаких ++. Собственно, как и у большинства других компиляторов и сред выполнения.

Компилятор Эрланга сделан на эрланге. По крайней мере, его бОльшая часть. Парсер с лексером — точно.

Вы ожидали чего-то другого?

А рантайм, разумеется, на plain C. Было бы странно увидеть там другой язык.

Здравствуйте, Gaperton, Вы писали:

G>Компилятор Эрланга сделан на эрланге. По крайней мере, его бОльшая часть. Парсер с лексером — точно.
Это я криво сформулировал ответ. Вопрос был о рантайме — его я и имел в виду

G>А рантайм, разумеется, на plain C. Было бы странно увидеть там другой язык.
Есть некие странные поделия, в коих используются ++. Но их весьма мало

Здравствуйте, Gaperton, Вы писали:

G>Компилятор Эрланга сделан на эрланге. По крайней мере, его бОльшая часть. Парсер с лексером — точно.
Сейчас посмотрел — целиком на нем. И HIPE тоже.
На С++ в рантайме есть один модуль для КОРБЫ.

Здравствуйте, gandalfgrey, Вы писали:

G> Весьма изобильные библиотеки. Я построил компилятор спец. языка, пользуясь только штатными средствами Ерланга, за 3 месяца
Дык , Когда в основу библиотеки ложится значительная часть фреймворка промышленного коммутатора AXD301, то получается весьма изобильно. Как вам, например, наличие в стандартной библиотеке полного стека мультимедийных протоколов (Megaco)? Или распределенной отказоустойчивой базы данных (mnesia)? А вебсервера (inets)? И все в исходниках.

G> Минусы :
G> Как числомолотилка — не покатит. С целыми числами все хорошо, и с большими целыми тоже, а вот производительность на операциях с плавающей точкой — так себе

Все не так плохо, кстати. Hipe компилирует плавающую запятую по человечески, если на забыть поставить guard на float.
В Erlang maillist есть люди, которые рещают на Erlang DSP-задачи, и производительностью довольны.

Но — если задача состоит в основном из числодробления — то Erlang все равно не лучший выбор.

G> Нет штатного способа запихать все в один выполняемый файл ( несколько неудобно )
Есть работы в этом направлении. Я их не отслеживаю — но скоро все будет хорошо. Если не уже.

Пропущен один серьезный недостаток. Даже два.

1) Операции со строками — слабое место Erlang. Чтобы добиться хорошей скорости, надо использовать binaries для представления строк. По умолчанию, если написать "прпропро" — это будет список целых чисел. Оверхэд на ровном месте в 8 раз. Erlang — не самый лучший выбор для строковых манипуляций, если задача состоит только из них. Он не конкурент перлу.

2) Массивы. В языке нет средств деструктивного изменения массивов. Это — реально плохо и неудобно, так как длинные массивы тормозят.

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

G>1) Операции со строками — слабое место Erlang.

Но все же ejabberd как-то справляется

G>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.

Хммм, а C++ ?

Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, VladD2, Вы писали:

VD>>Вот только ты забыл добавить следущие характеристики с которыми не все согласны:
VD>>9. Интерпретирвемый язык.

WF>А как же HiPe?

Ну да . А насчет "отсутствия статической типизации" можно было бы сказать "Dyalizer".