Вышел Erlang R11B

И не одного недостатка! скааазка.. Я взял и сиьел у Морфиуса поистене классную таблетку

а может кто привести приложение server side, написанное на нем?

Интересно.

ejabberd тот на котором работает jabber.ru

>ejabberd тот на котором работает jabber.ru

Помимо ejabberd'а ещё есть Yaws (HTTP-сервер), а также ряд коммерческих продуктов: http://dmoz.org/Computers/Programming/Languages/Erlang/Products/

спасибо, посмотрим.

никогда не понимал, почему не использование тредов ОС является плюсом системы.

если нативные треды не удовлетворяют, то может это повод допилить их, а не изобретать велосипеды?

> Если Вы в данный момент делаете выбор языка программирования для серверного приложения, то крайне рекоммендуется обратить свой взор на Erlang, так как:

> * Erlang не использует треды OS. Напротив, он имеет собственную реализацию легковесных потоков (aka erlang process).

И какой здесь плюс в многопроцессорной системе?

> * Нативная кластеризация.

Переведи на русский!

> * Поддержка обновления кода приложения "налету".

Это как? Самомодификация? Замена частей программы? Воcстановление сеансы после обновления версии?

Ja rabotaju na Ericsson, no naprjamuju s Erlang ja ne svjazan. Tem ne menee, dovolno horosho o nem naslishan ot kolleg po rabote.

Odni iz samih populjarnih ATX stanzij (t.e. avtomaticheskie telefonnie stanzii) ot Ericsson imjut programmnoe obespechenie, realizovannoe na Erlang. Eto bolee milliona strok na Erlange. Sistemi obladajut hard-real time harakteristikami, 99,999% fault tolerance i obsluzhivajut do neskolkih soten tisjach ili dazhe millionov zvonkov odnovremenno.

V izvestnom smisle, Erlang - eto edinstvennij iz funkzionalnih ili logicheskih jazikov, na kotorom bili napisani realnie industrialnie prilozhenija takogo mashtaba. Pochti vse ostalnie jaziki v etih kategorijah ispolzujutsja preimushestvenno dlja akademicheskih issledovanij.

Треды ОС - это общее решение.

Для некоторых задач бывает эффективнее сделать собственную реализацию.

ЗЫ - на ерланге не писал - какие треды в нем - хз.

>> * Erlang не использует треды OS. Напротив, он имеет собственную реализацию легковесных потоков (aka erlang process).

> И какой здесь плюс в многопроцессорной системе?

Читаем новость ещё раз: "Основное новшество - поддержка SMP."

>> * Нативная кластеризация.

> Переведи на русский!

Значит что работа с локальными процессами не отличается от работы с удалёнными, всё прозрачно.

>> * Поддержка обновления кода приложения "налету".

> Это как? Самомодификация? Замена частей программы? Воcстановление сеансы после обновления версии?

Самомодификация нет, остальное да.

>И какой здесь плюс в многопроцессорной системе?

Запусти 100k тредов (даже на SMP-системе) и удивись.

> * Нативная кластеризация. Переведи на русский!

Кластеризация без бубнов - прямо из вирутальной машины Erlang'а. Можно запускать разные процессы на разных нодах.

> * Поддержка обновления кода приложения "налету". Это как?

Обновление кода в работающей программе без перезапуска.

> никогда не понимал, почему не использование тредов ОС является плюсом системы.

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

Трэды OS улучшить до уровня сопоставимого с тредами Erlang не реально. Конечно, если речь идет о традиционных операционках типа Linux. :-)

Именно отсутствие side effects позволяет Erlang'у иметь поистине фантастическую поддержку многопоточности.

Да-а-а, все хорошо и замечательно, а в чем подвох-то? :)

> никогда не понимал, почему не использование тредов ОС является плюсом системы.

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

Кто-нибудь в курсе, реально ли на Erlang по-человечески работать с массивами? Понятно, что императивные конструкции ему противны, но ведь в том же Haskell есть чисто функциональные массивы. Я пару месяцев назад искал такую функциональность, но не нашел. :(

Легковесные потоки _в рамках виртуальной_ машины. И использовать системные потоки (которых в некоторых системах может и не быть) в большом количестве - несколько сотен, очень накладно с точки зрения ресурсов.

"Нативная кластеризация" означает то, что создание распределенных приложений заложено в сам язык программирования.

Еще мне очень понравилась модель Behaiviour'ов - по сути паттернов поведения (типа Template Method). Еще одна хорошая идея - объект класса представляет собой поток, который обрабаывает сообщения.

Не понравился syntax sugar, странный там синтаксис (хотя может не ту траву курил ;) Отсутствие каких-то средств создания UI кроме Tk. Хотя есть достаточно мощные абстракции, по идее не зависимые от конкретной графич. библиотеки. Натравил XML парсер на тестовый XML с русскими буквами - вылетело с ошибками.

Классно, но нехватает многих насущных функций.

> Треды ОС - это общее решение.

> Для некоторых задач бывает эффективнее сделать собственную реализацию.

И забыть о многопроцессорности?

> Читаем новость ещё раз: "Основное новшество - поддержка SMP."

То есть планировкой потоков и раскидыванием их по процессорам занимается Эрланг?

Не надо так уж заливатся. AXЕ, конечно, машинка неплохая, но несколько сотен тысяч или миллионов звонков ОДНОВРЕМЕННО она, конечно, не держит, как их не держит никто. Она может ОБСЛУЖИВАТЬ такое количество абонентов (подключений), но это не значит, что ВСЕ подключения имеют активную сессию в любой данный моемнт времени.

> Кто-нибудь в курсе, реально ли на Erlang по-человечески работать с массивами?

Эффективнее всего будет использование либо словарей (put, get), либо ets, а обычных массивов с возможностью модификации элемента за O(1) там нет.

На 400 000 системных трэдах у Вас сдохнет любой SMP зверь. Но вот 400 000 erlang'овых трэдов спокойно и без напряга будут работать даже на одном процессоре.

Когда процессоров >1, возможно будет создано два узла кластера и на них будут бегать эти трэды. То что это разные узлы - никого не напряжет, так как кластеризация в Erlang сделана прекрасно.

Обратно же, надо иметь в виду, что Erlang ориентирован на _массивную_ многопоточность. Посмотрите на сравнение apache и yaws например.

> И какой здесь плюс в многопроцессорной системе?

Вот я тоже офигел. Яву за зелёные нити все ругали... ;-) Похоже, всё различие в том, как это подают. ;-)))

>>Похоже, всё различие в том, как это подают. ;-)))

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

А поддержка SMP - всего лишь шаг к поддержке "больших систем".

> > Кто-нибудь в курсе, реально ли на Erlang по-человечески работать с массивами? > Эффективнее всего будет использование либо словарей (put, get), либо ets, а обычных массивов с возможностью модификации элемента за O(1) там нет.

А есть ли в Erlang такой вид массивов, что представляют собой неизменяемые объекты с операцией "взять элемент по индексу" и возможностью сконструировать новый такой же объект, указав размер массива, и функцию что по конструирует элемент массива по его индексу? Это не вывело бы Erlang за пределы purely functional языка, но было бы очень удобно.

Пример: Есть массив данных с изображением. Нужно пропустить изображение через размывающий фильтр. При этом создается точно такой же массив но с содержанием U(i) = 0.2*v(i-1)+0.6*v(i)+0.2*v(i+1), где U - новый массив, а v - старый.

А что насчет накладных расходов в green threads и Java threads? :-) В Erlang потоки значительно легковеснее. И по-моему scheduler в Erlang значительно живучее.

>> > Треды ОС - это общее решение.

>> > Для некоторых задач бывает эффективнее сделать собственную реализацию.

>> И забыть о многопроцессорности?

Почему забыть? создаешь кол-во потоков/процессов равное кол-ву процессоров и в них все обрабатываешь.

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

Это форк brinfuck?

> А есть ли в Erlang такой вид массивов, что представляют собой неизменяемые объекты с операцией "взять элемент по индексу" и возможностью сконструировать новый такой же объект, указав размер массива, и функцию что по конструирует элемент массива по его индексу? Это не вывело бы Erlang за пределы purely functional языка, но было бы очень удобно.

Ближе всего к этому его tuples. Конструировать можно сначала список, а потом переводить его в тьюпл.

> Пример: Есть массив данных с изображением. Нужно пропустить изображение через размывающий фильтр. При этом создается точно такой же массив но с содержанием U(i) = 0.2*v(i-1)+0.6*v(i)+0.2*v(i+1), где U - новый массив, а v - старый.

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

Пример - возьми какую-нить СУБД и запусти там 10000 транзакций одновременно.

Я надеюсь ты не думаешь, что нормальная СУБД будет рожать по потоку на каждую транзакцию? :)

Или веб-сервер - аналогично...

Вот вот, не важно, как легковесные потоки реализованы внутри, и как там они решают, масштабироваться на SMP или нет. Важна гибкость и единообразие. Только дуракам, тявкающим тут про green threads, этого не понять, они пи-исчисления не учили, и вообще малограмотные до безобразия.

> Оч многие приложения даже если не реализуют собственные потоки используют собственную систему планирования задач. Никакого "велосипеда" в этом нет.

s/многие/немногие/

s/многие/почти все серверные/

Нет. А зачем тебе getting the brains fucked?

>То есть планировкой потоков и раскидыванием их по процессорам занимается Эрланг?

Да. Главное, чтобы в программе были потоки, а планировку и SMP возьмёт на себя Erlang :)

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

> А что насчет накладных расходов в green threads и Java threads? :-)

А ничего. Я говорил, что яву за них ругали. Потому что не нативные. ;-)

> Почему забыть? создаешь кол-во потоков/процессов равное кол-ву процессоров и в них все обрабатываешь.

Т.е., в итоге у нас получилась потоковая модель M:N. И её почему-то все ругают, мол, сложная слишком. ngpt, вон запинали, заменили ntpl.

Думаю что ругают не модель, а реализацию.

Может СУБД должна создавать поток на каждую транзакцию, а веб сервер на каждое соединение? :)

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

И изначально были только процессы и никаких потоков.

Я не понимаю, что плохого в том, что программа сама планирует, что и когда ей выполнить...

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

> Думаю что ругают не модель, а реализацию.

Но Sun тоже от этой можели ушла к 1:1, хотя долго за ней держались.

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

Хотелось бы избежать упоминания "костылей". Единое адресное пространство имеет свои преимущества.

> Я не понимаю, что плохого в том, что программа сама планирует, что и когда ей выполнить...

Смотря как приходится планировать. Если надо просто переключать "потоки" последовательно - всё просто. Если надо управлять потоками в ожидании, то всё сложнее. Ряд функций, ожидающих каких-либо событий завязан на ядро, получается, необходимо иметь двойной набор объектов синхронизации, причём следить, чтобы ядерные вызовы не блокировали программу в целом, т.к. в самом простом случае она вообще может иметь только один поток. Т.е. - сплошные асинхронные вызовы и получение событий. В этом случае userspace-threads полезны только для "сглаживания" работы программы. Неплохо, но есть одно но...

Я никак не могу понять, почему в win остались маловостребованными fibers, а в состав linux/*bsd не входят стандартно библиотеки userspace-threads? (Причём, последнее я бы действительно хотел понять. Неужели все вокруг дураки, только авторы Erlang - умные?)

Я уже говорил чуть выше, что потоки в ОС - это _общее_ решение.

Следовательно userspace threads - это "еще один велосипед".

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

Q. Почему oracle не использует дисковый кеш?

A. Потому что oracle знает лучше операционной системы что и как ему кешировать и кеш ОС ему только мешает.

>Erlang не использует треды OS. Напротив, он имеет собственную >реализацию легковесных потоков (aka erlang process). Попробуйте реализовать в DOS

Хорошая диссертация для "въезжания" в Erlang: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

Множество вопросов, поднятых в треде, там озвучено.

> Следовательно userspace threads - это "еще один велосипед".

*хихикает* Вы бы почитали про те же fibers, полезно. :) Там есть функци: переключиться в волокно такое-то. Всё, то, что надо. Пиши свой шедулер.

Или есть нечто сакральное, что такая библиотека может быть только частью языка, но не общесистемной.

Потому и думаю (ибо мысль использовать есть) - почему почти никто не пользует. Почему нет в *nix...

Ну вот...

На 18й странице как раз и написано зачем они сделали свои треды...

Спасибо :)

Fibers к тредам никакого отношения не имеют

И нечего хихикать...

> Fibers к тредам никакого отношения не имеют

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

Думаю после этой pdf'ки можно завершить дискуссию..

Ну вот в завершении http://en.wikipedia.org/wiki/Thread_%28computer_science%29#Processes.2C_threa...

Доступное объяснение кто такие потоки, процессы и волокна...

Как мы почти одновременно это решили :)

Relationships between processes, threads, and fibers

The operating system creates a process for the purpose of running a program. Every process has at least one thread. On some operating systems, a process can have more than one thread. A thread can use fibers to implement cooperative multitasking to divide the thread's CPU time for multiple tasks. Generally, this is not done because threads are cheap, easy, and well-implemented in modern operating systems.