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

И все это удовольствие может работать поверх обычной VM (я про JVM или .NET runtime)?



Наверно это хорошо. Только вот насколько это востребовано бывает.

Нет, там своя виртуальная машина, с софт-реалтайм планировщиком и сборщиком мусора. Наверное, можно изобрести что-то подобное поверх JVM или CLR, но насколько близко будет по характеристикам, трудно сказать. С другой стороны, JIT в Эрланге нет, только прямая интерпретация байт-кода или прекомпиляция (HiPE), которая в зависимости от кода даёт прирост скорости в 2-3 раза. То есть в однопоточном коде Эрланг будет медленнее Джавы, где-то на уровне Питона. Но можно подцепить модуль на Си или посадить в Эрланг-кластер узел на Си или Джаве — соответствующие библиотеки есть.

Оно востребовано для того, для чего создавалось: телеком, всякого рода high-load системы.

Одерски сотоварищи внедрили в scala механизм actors наподобие Эрланговского. Руки ещё не дошли, но везде где пишут о scala - громко хвалят систему actors, по большей части за несравненне удобство в работе с ними. Работает оно как раз на JVM, поэтому байт-код итоговый получается один-в-один с обычным Джавным, а значит, предел мощности ограничен несколькими сотнями потоков. Вам решать, много это или мало.

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

Нельзя назвать это экспериментами, jinterface в составе OTP уже чёрт знает сколько, бери и пользуйся...
Cyberax поделился на RSDN примером более удобной интеграции Java и Erlang. Обещают в скором времени отдать в open source.

"Узок их круг и страшно далеки они от народа" (это к вопросу о причинах малой распространённости)

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

Amazon - тоже мне пример, эти маниаки на чем только не пишут 

Или вот IBM купила разработчика CouchDB 
Примеров можно насобирать прилично, маньяки есть везде 

Насколько я понял, эти акторы - по сути реализация на Scala спецификации JTA.



Уже не хватает. Собственно, сегодня старые парадигмы доживают последние дни. Будущее - за асинхронностью и параллелизмом. Закон таков - алгоритм, который может быть распараллелен, должен быть распараллелен, причем это должно происходить автоматически. Собственно, сегодня можно вовсю наблюдать, как куча хардкорщиков занимается тем, что тупо добавляет в свой софт "поддержку еще одного ядра" , а потом бьет пяткой в грудь - мол, у нас используется аж 2 ядра. Эти убогие поделия не более масштабируемы, чем их однопоточные оригиналы. Не сегодня-завтра появятся процессора с сотнями ядер, хотел бы я посмотреть, как они будут параллелить ручками... в общем, java и c# на свалку истории...

Ага формочка которая показывает бухам их годовые отчеты, просто обязана использовать не менее 10 потоков 

А события с клавы, мыши и другие действительно удобно в своих короткоживущих тредах (асинхронных сообщениях) выполнять 
Гуй, это одна из областей где fine grained распараллеливание воспринимается на ура.

А нынешняя парадигма обработки событий уже успела стать неудобной?  

Ну там где есть closures/inner classes, т.е. где "решение проблемы" можно описать сразу же на месте - то да, не отвратно. Но приходиться помнить, что в обработчике много не делаем, ставить worker threads, заполнять очереди pending operations - и всё это ради быстрого отклика от гуя. Многие забивают на это, получаем "тормознутый" софт.

Хоть 10000, если потребуется. Сколько потоков использовать - решает рантайм, и никто другой. Твоя задача - программировать так, чтобы позволить рантайму произвести потоковую оптимизацию.



Истинно так. Кстати, это - уже сегодняшний день. Посмотрите на любой веб-фреймфорк для ui (ext, gwt) - там все построено на асинхронных сообщениях.



Какая нынешняя? Если ты имеешь ввиду стандартный виндовый способ программирования, когда UI работает в одном потоке с основной программой, то это всегда  было не лучшим решением.

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



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