Здравствуйте, Sinclair, Вы писали:
S>И решения, написанные энтузиастами в 90х, вымирают, потому что им на смену приходят более вменяемые архитектуры. S>Да-да, те самые, которые внутри себя тащат половину Эрланга.
т.е. эрланг всё-таки не нужен, достаточно того же so5 вместо чистых потоков?
Здравствуйте, Sinclair, Вы писали:
S>>Более того, не нужно забывать, что Web начинался с CGI, а самый простой и надежный способ реализации CGI как раз был в использовании формулы "process per client". S>Ну вот CGI и есть "process per client", и то, что веб начинался с него — и есть иллюстрация к моему тезису о том, что нормальную архитектуру на традиционных платформах делать тяжело. Вместо неё делают "что получится", а потом мы удивляемся, почему Апач, несмотря на почтенный возраст, огромное коммьюнити, и доминирование на рынке, до сих пор не может решить проблемы с быстродействием.
Апачу это просто не нужно. Апач давно занял отличную нишу сервера по умолчанию, который обеспечивает практически все варианты построения лёгкими добавками, а во многих случаях и без них, штатными модулями. Ниша позиции "мы говорим веб-сервер — подразумеваем апач, до тех пор, пока не возникает жёсткой потребности в другом сервере" фундаментальна и надёжна. Отсюда "огромное коммьюнити, и доминирование на рынке". Но при всём при этом он ничуть не фатальный тормоз, а так, умеренное тормозильце. А тратит время в нём в основном не process-per-client, а переусложнённая плагинная система.
Здравствуйте, so5team, Вы писали:
N>>AXD301 имел сишный код, да. В драйверах работы с оборудованием. Для реализации самого Erlang. И в куче других достаточно очевидных для этого мест. S>Из того, что до меня доходит про использование Erlang в реальном мире, складывается ощущение, что Erlang без С или C++ не справляется с более-менее серьезными нагрузками.
Зависит от задачи. Для веб-сервера, как ни странно, эта необходимость минимальна.
Для массы задач по перекладке байт она тоже крошечная — фактически, только для того, чтобы реально добраться до соответствующего железа.
Заметные внешние средства нужны для математики, для длинных асинхронных очередей, дальше не помню.
S>>>Ну и да, доводилось писать софт для работы с GSM/SMPP/UCP на C++. Отлично пишется, удобнее чем на Java и работает быстрее, чем на Erlang-е или какой-нибудь другой динамике. N>>Нужна ли там эта скорость? Или важнее другие характеристики? S>Когда пропускная способность одного SMPP-канала должна превышать 200sms/sec скорость оказывается важна.
200 sms/сек это копейки. Вот если бы ты говорил хотя бы о 20K...
Здравствуйте, Joie de vivre, Вы писали:
N>>И какой объём заката солнца вручную в каждом случае для того, что в OTP уже есть и активизируется, грубо говоря, тремя стандартными строчками?
JDV>Это безусловно плюс, что это очень просто сделать на эрланге. Если это было бы из коробки в той же java, то продукты вроде Zookeeper и компании были несколько проще, но не настолько проще — суть того же Zookeeper-а это алгоритм, которого из коробки нигде нет.
В чём особенности этого алгоритма?
JDV>К тому же под распределенными системами я понимаю не N приложений общающихся через несколько очередей — такую задачу сейчас каждый второй хипстер решает на всяких Redis-ах, а 15 лет назад решали на каком-нибудь J2EE. JDV>Мне интересно как решит эрланг задачи вроде стандартной (в распределенном системе) схемы лидер + последователи, когда один процесс принимает от клиентов команды и реплицирует их на остальные машины, падение лидера должно запустить процесс выбора нового лидера, который потом также начнет принимать команды и т.д. и т.п. JDV>Куда мне смотреть если я такое хочу реализовать на эрланге?
Кластер нод штатными средствами, global-регистрация лидера, failover между экземплярами лидеров (штатный, кажется, работает с реакцией супервизора "упал => говорим другому подхватить").
При необходимости какого-то персиста — mnesia.
Здравствуйте, Ikemefula, Вы писали:
N>>Наша команда самого большого эрлангового проекта наполовину состояла из людей, вообще до того не имевших опыта программирования под заказ или своих проектов более страницы. Входить им было даже легче, чем некоторым до того опробовавшим разные языки и стеки. Отсутствие привычки к императивщине тут, оказалось, помогает. I>Это как, вообще программировать не умели ?
Умели в объёме вузовского обучения и одностраничных скриптов на перле.
I>>>Эту нишу мог бы занять и Node.js, но реально ручная диспетчеризация асинхронного кода это адский АДъ. N>>JIMHO даже не столько ручная диспетчеризация, сколько отсутствие средств диагностики типа "а сколько у нас отложенных заданий помечено тегом Forum", возможности произвести массовый отстрел или модификацию по некоторому критерию, и т.д. I>Если это то что я понимаю, то такие вещи уже появились — куча всевозможных шедулеров, менджеров и тд. Я правда не могу сказать, насколько это эффективно работает, не работал.
Ну если появились, то хорошо. А то я ещё таких не видел. Обычно функциональность такого рода — это то, что делается в лучшем случае в пятом сорте приоритета.
Здравствуйте, vdimas, Вы писали:
V>Асинхронные мьютексы ставят раком всю аснхронность. V>Собсно, как синхронные мьютексы ставят раком вытесняющую многозадачность. V>И точно так же на асинхронных мьютексах возможен тот самый дедлок.
Зато диагностируется и лечится — проще. И сделать адаптивное по каким-то условиям ограничение количества попыток — тем более.
V>И это при том, что асинхронщина толкается как инструмент №1 для избавления от дедлоков, ы-ы-ы.
Именно, безо всяких "ы-ы-ы".
V>А изобретателей асинхронных мьютексов вменяемые разработчики давно послали туда, где им место. V>Это же надо было, вместо того, чтобы создать нужные зависимости, додуматься тупо отпуливать таски в конец очереди... бррр... ))
Не вместо, а вместе. Где не получилось адекватно напланировать зависимостей — отпуливаем, если получилось — то и так работает
Здравствуйте, netch80, Вы писали:
S>>Когда пропускная способность одного SMPP-канала должна превышать 200sms/sec скорость оказывается важна.
N>200 sms/сек это копейки. Вот если бы ты говорил хотя бы о 20K...
Про 20K на один канал не слышал. Про 20K суммарно с нескольких сотен каналов -- да, но это уже масштабы серьезных SMSC, стоимость которых измеряется очень приличными суммами.
Здравствуйте, netch80, Вы писали:
I>>Это как, вообще программировать не умели ?
N>Умели в объёме вузовского обучения и одностраничных скриптов на перле.
Это уже неплохо на самом деле. Вообще, если архитектура спроектирована хорошо, то такие люди очень неплохо справляются, особенно есть есть кому консультировать.
N>Ну если появились, то хорошо. А то я ещё таких не видел. Обычно функциональность такого рода — это то, что делается в лучшем случае в пятом сорте приоритета.
Да, примерно так и бывает. Вот на текущем проекте такое надо было делать сразу, а начали делать ажно спустя два года, как то так.
Здравствуйте, netch80, Вы писали:
N>Не вместо, а вместе. Где не получилось адекватно напланировать зависимостей — отпуливаем, если получилось — то и так работает
Если речь все еще про мутексы, то не надо ничего отпуливать. В большинстве случаев задача уже была готова когда произошел вызов мутекса.
Здравствуйте, neFormal, Вы писали:
F>>>а что надо будет написать, чтобы управиться с UB ? EP>>С чем конкретно? use after delete? F>например, да.
Например завести флаг live для каждого объекта, и счётчик ссылок на этот флаг (на сам флаг, а не объект — то есть эдакий weak_ptr встроенный в компилятор). В этом случае баги подобные use after delete будут отлавливаться в runtime.
Здравствуйте, netch80, Вы писали:
N>Апачу это просто не нужно. Апач давно занял отличную нишу сервера по умолчанию, который обеспечивает практически все варианты построения лёгкими добавками, а во многих случаях и без них, штатными модулями. Ниша позиции "мы говорим веб-сервер — подразумеваем апач, до тех пор, пока не возникает жёсткой потребности в другом сервере" фундаментальна и надёжна. Отсюда "огромное коммьюнити, и доминирование на рынке". Но при всём при этом он ничуть не фатальный тормоз, а так, умеренное тормозильце. А тратит время в нём в основном не process-per-client, а переусложнённая плагинная система.
Это утверждение справедливо до тех пор, пока речь идёт о тестовой нагрузке. Да, при 1 запросе в секунду Апач будет лишь чуть-чуть медленнее какого-нибудь приличного сервера вроде nginx.
Но как только мы начнём наращивать количество параллельных обращений, Апач склеит ласты задолго до того, как nginx хотя бы слегка вспотеет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>>Собственно, хочется выяснить, за счет чего этот пункт удовлетворяется в Erlang-е. M>>За счет рантайма вестимо. S>Это весь уровень ваших знаний? S>Такой ответ не катит. Давайте подробности. Например, есть ли какие-то гарантии по работе receive? Есть ли гарантии по времени активации процессов? Сколько приоритетов доступны процессам в Erlang VM? Есть ли гарантии по временам работы GC?
Зачем тебе подробности, если весь уровень твоей аргументации — это «я умею сделать 100500 потоков, Эрланг не нужен»
Подробности — где-то в документации и презентациях на EUC.
S>>>Ну и, если он таки удовлетворяется, почему Mamut считает, что этот пункт в других платформах в зачаточном состоянии.
M>>Потому что в других платформах рантайм этого не гарантирует, вестимо.
S>Вестимо вы никогда не слышали про Real-Time Java?
Здравствуйте, Mamut, Вы писали:
M>Зачем тебе подробности, если весь уровень твоей аргументации — это «я умею сделать 100500 потоков, Эрланг не нужен»
Уровень моей аргументации таков: глупо требовать повторение отличительных особенностей Erlang-а в других языках программирования, поскольку те же самые задачи вне Erlang-а успешно решались, успешно решаются и будут успешно решаться совсем другими способами.
И таки да, я умею сделать 100500 потоков и мне не придется вручную работать с низкоуровневыми примитивами синхронизации. И таки да, я знаю, сколько это будет стоить, поэтому умею обходиться считанными единицами или десятками системных потоков. Опять же без рукопашной работы с низкоуровневыми примитивами синхронизации.
И таки да, опыт позволяет делать вывод, что очень много где Erlang не нужен.
M>Подробности — где-то в документации и презентациях на EUC.
Отличный ответ. Наглядно демонстрирующий и уровень экспертизы, и уровень инженерной зрелости. Точнее отсутствие таковой, поскольку вы позволяете себе выдавать маркетинговый булл-шит за технические характеристики.
S>>Вестимо вы никогда не слышали про Real-Time Java?
M>Когда появилась она, и когда Эрланг?
Вопрос не во времени появления, а в свойствах и в гарантиях.
M>>Зачем тебе подробности, если весь уровень твоей аргументации — это «я умею сделать 100500 потоков, Эрланг не нужен»
S>Уровень моей аргументации таков: глупо требовать повторение отличительных особенностей Erlang-а в других языках программирования, поскольку те же самые задачи вне Erlang-а успешно решались, успешно решаются и будут успешно решаться совсем другими способами.
S>И таки да, я умею сделать 100500 потоков и мне не придется вручную работать с низкоуровневыми примитивами синхронизации. И таки да, я знаю, сколько это будет стоить, поэтому умею обходиться считанными единицами или десятками системных потоков. Опять же без рукопашной работы с низкоуровневыми примитивами синхронизации.
S>И таки да, опыт позволяет делать вывод, что очень много где Erlang не нужен.
Вот о чем я говорю: все, что ты можешь понять, и о чем можешь говорить, это — «я могу создать 100500 потоков». Все. Для тебя все, что предлагает Эрланг — это 100500 потоков. Ты не способен выбраться из этого способа мышления. В SObjectizer реализовано некоторое подмножество возможностей Erlang'а и ты считаешь, что все — ты заруливаешь Erlang. Ага-ага.
M>>Подробности — где-то в документации и презентациях на EUC.
S>Отличный ответ. Наглядно демонстрирующий и уровень экспертизы, и уровень инженерной зрелости. Точнее отсутствие таковой, поскольку вы позволяете себе выдавать маркетинговый булл-шит за технические характеристики.
Я просто общаюсь с тобой на твоем же уровне. А ты почему-то обижаешься.
S>>>Вестимо вы никогда не слышали про Real-Time Java? M>>Когда появилась она, и когда Эрланг? S>Вопрос не во времени появления, а в свойствах и в гарантиях.
Прекрасно. Дала гарантию real-time. Где остальное?
Я же говорю. Уровень твоей аргументации: из всего списка требований взять ровно один, возвести его в абсолют и говорить только о нем. Ты не способен говорить об общей картине.
— Есть Real-Time Java. В ней есть гарантии real-time. Что в ней есть из других пунктов?
— Есть SObjectizer. В нем есть агенты и возможность создать 100500 потоков. Что в нем есть из других пунктов?
Здравствуйте, Mamut, Вы писали:
M>Для тебя все, что предлагает Эрланг — это 100500 потоков.
Вы приписываете мне чьи-то заблуждения.
Для меня все, что предлагает Erlang -- это динамическая типизация и одна из самых медленных на рынке VM (если говорить о том, что идет из коробки). Плюс куча специализированных библиотек, которая, мягко говоря, не нужна за пределами ниши, на которую претендует Erlang.
M>В SObjectizer реализовано некоторое подмножество возможностей Erlang'а и ты считаешь, что все — ты заруливаешь Erlang. Ага-ага.
Сможете привести цитату, где бы я утверждал, что SObjectizer заруливает Erlang?
Я утверждаю, что Erlang много где не нужен. И там где он не нужен, востребованы другие инструменты, работающие по другим принципам.
Один из примеров был показан с самого начала: расчеты для прогнозов погоды. Посмотрите презентацию, на которую давалась ссылка.
Сами Erlang-еры приводят здесь ситуации, когда pure-Erlang не хватает, нужно использовать написанные на C драйвера, а то и порты.
S>>Отличный ответ. Наглядно демонстрирующий и уровень экспертизы, и уровень инженерной зрелости. Точнее отсутствие таковой, поскольку вы позволяете себе выдавать маркетинговый булл-шит за технические характеристики.
M>Я просто общаюсь с тобой на твоем же уровне. А ты почему-то обижаешься.
Попробуйте подняться на уровень выше. Вам был задан конкретный вопрос: каким образом Erlang обеспечивает гарантии для Soft Real-Time. Это же вы привели в списке требований этот пункт. Ну так потрудитесь подтвердить его чем-нибудь более существенным чем отсылки к некой мифической документации.
S>>>>Вестимо вы никогда не слышали про Real-Time Java? M>>>Когда появилась она, и когда Эрланг? S>>Вопрос не во времени появления, а в свойствах и в гарантиях.
M>Прекрасно. Дала гарантию real-time.
Вот именно, JavaRT дала гарантию, а Erlang нет.
M>Я же говорю. Уровень твоей аргументации: из всего списка требований взять ровно один, возвести его в абсолют и говорить только о нем. Ты не способен говорить об общей картине.
Повторю еще раз, специально для вас. Попробуйте отбросить свое предубеждение о том, что вы знаете, на что способен, а на что не способен ваш собеседник.
Есть Erlang, обладающий определенным набором уникальных свойств. В этом его ценность. Без этих наборов уникальных свойств разговаривать об Erlang-е не было бы смысла. Уже поэтому глупо требовать от других языков наличия в них всех свойств Erlang-а: зачем кому-то нужен еще один Erlang, только с другим синтаксисом?
Далее, уникальные свойства Erlang-а дают возможность решать ряд задач некоторым, характерным для Erlang-а способом (тут как раз и появляются 100500 процессов, механизмы супервизоров, а так же ссылочная прозрачность, благодаря которой сообщений могут летать с ноды на ноду). Это здорово. Для тех задач, где такой подход уместен. И совершенно бесполезно для задач, для которых такой подход неуместен.
Это же очевидная для здравомыслящих инженеров вещь. Ну тут появляется начитавшийся маркетинговых материалов Mamut и начинает требовать показать ему, как на других языках и платформах решаются задачи характерным для Erlang-а способом. И на основании факта о том, что ему таких примеров не приводят, Mamut делает вывод, что другим языкам и платформам до Erlang-а еще пилить и пилить.
На доводы о том, что нет смысла использовать характерный для Erlang-а способ решения таких задач на других языках, которые не обладают уникальными качествами Erlang-а, вы упорно не обращаете внимания. Вам в десятый раз повторяешь простую и очевидную мысль о том, что можно решать такие задачи по-другому, с использованием других инструментов. Поэтому сравнение Erlang-а с чем-либо еще "вообще", без отрыва от конкретного ТЗ, команды, сроков, денег и пр. чрезвычайно важных для софтверного проекта параметров бессмысленно.
Но вы упорно твердите о том, что "Ты не способен говорить об общей картине".
Это нежелание выслушивать собеседников, помноженное на феноменальный уровень экспертизы (neFormal всерьез говорит о "надежности в принципе", вы о реал-тайме), оставляет от упоротых Erlang-еров печальное впечатление. Если бы не участие netch80, kostik78 и meadow_meal эта тема вообще содержала бы ноль целых, ноль десятых полезной информации об Erlang-е.
S>Для меня все, что предлагает Erlang -- это динамическая типизация и одна из самых медленных на рынке VM S>Я утверждаю, что Erlang много где не нужен.
Могу только ответить твоими же словами:
S> Отличный ответ. Наглядно демонстрирующий и уровень экспертизы, и уровень инженерной зрелости.
Здравствуйте, Mamut, Вы писали:
S>> Отличный ответ. Наглядно демонстрирующий и уровень экспертизы, и уровень инженерной зрелости.
M>Что ты вообще делаешь в этом топике?
S>Есть Erlang, обладающий определенным набором уникальных свойств. В этом его ценность. Без этих наборов уникальных свойств разговаривать об Erlang-е не было бы смысла. Уже поэтому глупо требовать от других языков наличия в них всех свойств Erlang-а: зачем кому-то нужен еще один Erlang, только с другим синтаксисом?
S>Далее, уникальные свойства Erlang-а дают возможность решать ряд задач некоторым, характерным для Erlang-а способом (тут как раз и появляются 100500 процессов, механизмы супервизоров, а так же ссылочная прозрачность, благодаря которой сообщений могут летать с ноды на ноду). Это здорово. Для тех задач, где такой подход уместен. И совершенно бесполезно для задач, для которых такой подход неуместен.
S>Это же очевидная для здравомыслящих инженеров вещь. Ну тут появляется начитавшийся маркетинговых материалов Mamut и начинает требовать показать ему, как на других языках и платформах решаются задачи характерным для Erlang-а способом. И на основании факта о том, что ему таких примеров не приводят, Mamut делает вывод, что другим языкам и платформам до Erlang-а еще пилить и пилить.
/o\
Ты вообще тему топика читал? Видимо, нет. Иначе ты бы не прискакал с развивающимся флагом «я умею делать 100500 потоков в SO». Я описал свое мнение на тему почему я считаю, что Erlang заруливает все остальные языки в плане поддержки/реализации многопоточных и распределенных приложений. Единственное о чем ты постоянно говоришь — это о 100500 потоках. Молодец. Прекрасно. Я уже раз пять задал один и тот же вопрос: у тебя есть 100500 потоков, дальше что? Как ими управлять, следить за ними и т.п. В ответ — тишина. Ну кроме того, что ты умеешь создавать 100500 потоков. Ну и смешное сообщение о том, что Kafka является решением /o\
Несмотря на твою (само)уверенность, что ничего, кроме 100500 потоков в многопоточной программе не нужно, это не так. Потому что любое многопоточное приложение как минимум требует управления этими потоками. State of the art в том же C++ можно увидеть в 11-м стандарте: треды, мьютексы и yield. Все остальное пытаются решить — если вообще пытаются — библиотеками. То, что ты неспособен понять, что такое дерево супервизоров, и зачем оно нужно, говорит только о твоей некомпетенции, а не о том, что Erlang не нужен. Если такого дерева нет в стандартной поставке или язык не позволяет его сделать самому с минимальными затратами, программист обречен каждый раз бороться с этим врукопашную. Зачем? Неизвестно. Видимо только ля того, чтобы с умным видом сказать «я могу 100500 потоков, Эрланг не нужен, все, что он предоставляет, специфично». Ну-ну.
В итоге для того, чтобы реализовать распределенную базу данных, например, на Эрланге достаточно того, что есть в стандартной поставке. Для того, чтобы то же самое реализовать на другом языке, андо сначала переизобрести все, что в Эрланге есть, прежде, чем вообще браться за работу. Аналогично для веб-серверов, да и вообще любых приложений, которые имеют хоть какую-то вменяемую многопоточность.
Да в твоем же SObjectizer реализована модель, которая встроена в Эрланг с конца 80-х. Но да, «Эрланг не нужен, он специфичный» и прочая чушь.
Поэтому могу только повторить:
Даже если не обращать внимание на свойства собственно самого языка, то в вашем языке/рантайме должны быть первые шесть пунктов
, чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать свои параллельные и распределенные вычисления и программы.
В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии, и их пытаются решить натягиванием на примитивную основу костыли в виде библиотек, пытающихся эту примитивную основу расширить. Где-то это успешно, если сам рантайм хорош. Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа. При том, что в Эрланге supervision trees реализуются в виде туториала к языку.
Здравствуйте, Mamut, Вы писали:
M>Ты вообще тему топика читал? Видимо, нет. Иначе ты бы не прискакал с развивающимся флагом «я умею делать 100500 потоков в SO».
Тебе разные люди в разной форме задавали один и тот же вопрос — за счет чего Эрланг обеспечивает реалтайм. Ты нигде ни разу не ответил. Были только обезьяньи ужимки "за счет рекламы VM", "смотри в рекламе доке" и прочие "куридопосинения"
Здравствуйте, Mamut, Вы писали:
M>Ты вообще тему топика читал? Видимо, нет. Иначе ты бы не прискакал с развивающимся флагом «я умею делать 100500 потоков в SO». Я описал свое мнение на тему почему я считаю, что Erlang заруливает все остальные языки в плане поддержки/реализации многопоточных и распределенных приложений. Единственное о чем ты постоянно говоришь — это о 100500 потоках.
Mamut, вы не ответили на мой вопрос о том, какие гарантии дает Erlang касательно Soft Real-time. Это не удивительно, поскольку вы ничего про это не знаете, не смотря на свой многолетний опыт работы с Erlang-ом.
Но ответьте, пожалуйста, на более простой вопрос: где я постоянно говорю о 100500 потоках?
Единственный пример, в котором что-то подобное фигурировало, это демонстрация Siclair-у возможности современных 64-битовых версий Windows. Не более того. Причем это не был пример того, что так нужно делать.
Напротив, я здесь уже неоднократно озвучивал простую точку зрения: вне Erlang-а нет смысла создавать большое количество нитей (threads).
M> Я уже раз пять задал один и тот же вопрос: у тебя есть 100500 потоков, дальше что? Как ими управлять, следить за ними и т.п. В ответ — тишина.
Так а что отвечать, если мне в SObjectizer не нужно управлять потоками? Как и тем разработчикам, которые используют CAF, Synca, Akka, Orleans и пр.
На SObjectizer было написано много многопоточного кода, в котором разработчик вообще ничего не знал ни про создание/останов/удаление нитей, ни про мутексы или какие-либо другие примитивы синхронизации. Ничего вообще.
M> Ну и смешное сообщение о том, что Kafka является решением /o\
Kafka является решением для ряда задач. В которых преимущества Erlang-а еще нужно доказывать.
M>Несмотря на твою (само)уверенность, что ничего, кроме 100500 потоков в многопоточной программе не нужно, это не так.
Подтвердите, пожалуйста, факт того, что я это говорил.
M> Потому что любое многопоточное приложение как минимум требует управления этими потоками.
Актуальность этого тезиса зависит от уровня абстракции, на котором идет речь. Но допустим.
M> State of the art в том же C++ можно увидеть в 11-м стандарте: треды, мьютексы и yield.
Кто сказал, что это state of the art?
M> То, что ты неспособен понять, что такое дерево супервизоров, и зачем оно нужно, говорит только о твоей некомпетенции,
Кто вам сказал, что я не понимаю, что это такое и зачем оно нужно?
M> а не о том, что Erlang не нужен.
Еще раз: Erlang много где не нужен. Я не говорил, что он совсем не нужен.
M> Если такого дерева нет в стандартной поставке или язык не позволяет его сделать самому с минимальными затратами, программист обречен каждый раз бороться с этим врукопашную.
Другое дело, что есть и мнение, что нафиг такие вещи в надежном софте не упали. Особенно когда речь идет о mission-critical и safety-critical софте.
M>В итоге для того, чтобы реализовать распределенную базу данных, например, на Эрланге достаточно того, что есть в стандартной поставке. Для того, чтобы то же самое реализовать на другом языке, андо сначала переизобрести все, что в Эрланге есть, прежде, чем вообще браться за работу.
Я где-то это оспаривал? Да, то, что есть в Erlang-е позволяет создать RabbitMQ или CouchDB. Замечательно.
Но сам факт наличия готовых для этого инструментов в Erlang-е не означает, что ничего подобного нельзя сделать на других языках. И за примерами далеко ходить не нужно.
M> Аналогично для веб-серверов, да и вообще любых приложений, которые имеют хоть какую-то вменяемую многопоточность.
А вот тут вы опять садитесь в лужу из-за собственной безграмотности. Есть parallel computing, есть concurrent computing. Многопоточность применяется и там, и там, но для разных целей. Erlang хорош в concurrent computing. Но мало кто из вменяемых людей будет использовать его в parallel computing. Так что может Erlang и хорош для разработки N2O, где нужна вменяемая многопоточность. Но совершенно бесполезен для вычислительных расчетов, где, сурпрайз-сурпрайз, так же нужна вменяемая многопоточность.
M>Да в твоем же SObjectizer реализована модель, которая встроена в Эрланг с конца 80-х.
Вы, блин, пытаетесь actor model выдать за плод жизнедеятельности Джо Армстронга со товарищи из Ericsson-а?
Сходите, хотя бы в Wikipedia, actor model появилась лет за 10-13 до того, как Армстрон вообще пришел в Ericsson.
M> Но да, «Эрланг не нужен, он специфичный» и прочая чушь.
Но да, Эрланг много где не нужен, он специфичный.
M>Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа.
Вы либо ничего не видите за пределами Erlang-овой экосистемы в принципе, либо просто больной.
