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

M>Действительно. Ведь Эрланг — это только message passing. Или Эрланг — это только 100500 процессов. /o\ И вообще, мы говорим строго и исключительно об Эрланге.

M>Слушайте, это разве действительно такая проблема — прочитать, что именно я пишу, а?

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

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

F>>это твой виртуал?
S>Нет, просто учитывая раздел было странно увидеть в нём кого-то адекватного, вот и запомнилось.

ясно, понятно

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

M>- С++. Стандарт С++11. http://en.cppreference.com/w/cpp/thread Уровень примерно на уровне WinAPI середины 90-х. Потоки, мьютексы. Ну еще есть futures.

Дальше можно не читать. Идеология языка С++ — необходимый минимум, всё остальное реализовывается сторонними библиотеками. И даже std::thread это всего лишь часть библиотеки stl без которой жили 20 лет. Сторонних
библиотек с самыми разными идеологиями многопоточности вагон и маленькая тележка, от студенческих поделок до гигантов индустрии типа Mictosoft или Intel.

M>- C#? Objective-C? Ruby? Php бггг? кто там еще есть в индексе? Все то же самое и одно и то же.

А это ещё один шедевр. Ну к примеру в C# уже давно ни кто не использует Thread, ибо есть целая кучам
современных механизмов для реализации монопольности. Только вы почему-то об этом всём ни чего не знаете.
Лучше бы почитали какую-нибудь книжку по C# чем графоманить такой большой и глупый пост.

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

...

M>Твое упорное нежелание понимать, что тебе пишут, просто удивительно.

Подозреваю, это связано с твоим изложением.

1 у тебя всё что касается эрланга и его VM, это табу(пудозреваю, и для тебя самого).
2 как решаются задачи вне эрлага ты не представляешь, ибо нет опыта
3 с эмоциями ты справиться не можешь

Так шта

M>>Слушайте, это разве действительно такая проблема — прочитать, что именно я пишу, а?
I>Может тебе поработать над качеством изложения ? Да и вообще, сложилось ощущение, что для тебя определенные темы в Эрланге — табу.

С качеством изложения у меня все в порядке. Есть одна только мааааааленькая проблема:

К сожалению, множество нечистоплотных людей решило, что они не будут стараться понимать написанное, и приложило множество усилий к тому, чтобы обсуждать все что угодно, только не топик. Оставим это на их совести. В топике было множество попыток от neFormal'а и meadow_meal'а вернуть обсуждение на нужные рельсы. Кто хотел понять, понял. Кто не хотел — на них не обижаются.

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

M>Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.

можно сократить без потери смысла:
— в эрланге ты разбираешься только на уровне базвордов
— в остальных системах не разбираешься вообще

в общем, типичный портрет фанатика, который уверен что только apple, linux или что-нибудь ещё решает все мировые проблемы

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

M>Твое упорное нежелание понимать, что тебе пишут, просто удивительно.
M>У тебя есть конкретные возражения по тому, что я написал? Ну именно возражение, а не битье себя пяткой в грудь в стиле «у меня клиенты создают 100500 потоков без управления».

Я согласен с so5team, он несколько раз опровергал именно что твои тезисы. Есть разные параллельные задачи, которые решаются разными способами. Ты перечислил всякие GUI-потоки, задачи телекома и т.д.
У so5team были конкретные возражения с примерами: OpenMP, например. Что это такое, для чего, как выглядит? Внезапно, этот стандарт поддерживается многими компиляторами из коробки и используется как часть языка (языка, а не в качестве сторонней библиотеки!) для организаций параллельных вычислений. Внезапно может оказаться, что программа на С++, использующая OpenMP, окажется более выразительной, более краткой, более производительной и более надёжной, чем аналог на Эрланге.
Что это за программа? Да те же матричные вычисления на, внезапно, кластере. Или решение систем дифуров. Или даже перебор паролей. Или любая вычислительно тяжёлая задача в пользовательском приложении.

Это тот раздел параллельного программирования, для которого Эрланг не создавался, под который не затачивался, который ты упорно игнорируешь в сообщениях собеседников. В своих тезисах ты описываешь лишь те особенности параллельного программирования, под которые так или иначе заточен Эрланг. А вокруг живёт большой мир со своими задачами и своими потребностями, нельзя просто так взять и отвернуться от него.

Ещё раз: основная критика именно что твоих тезисов заключается в том, что они описывают лишь те задачи и средства их решения, которые есть в Эрланге и которые он способен решать. То есть проблема не столько в тезисах, сколько в их ограниченности.

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

N>У so5team были конкретные возражения с примерами: OpenMP, например. Что это такое, для чего, как выглядит? Внезапно, этот стандарт поддерживается многими компиляторами из коробки
N> Что это за программа? Да те же матричные вычисления на, внезапно, кластере.

OpenMP основан на shared memory model, так что кластера — вряд ли. можешь назвать хоть один такой компилятор?

N>Это тот раздел параллельного программирования, для которого Эрланг не создавался

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

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

N> Что это за программа? Да те же матричные вычисления на, внезапно, кластере. Или решение систем дифуров. Или даже перебор паролей. Или любая вычислительно тяжёлая задача в пользовательском приложении.

AFAIK, на кластере используются связки из OpenMP (для распараллеливания внутри одной ноды) и MPI (распараллеливание между нодами).

N>Это тот раздел параллельного программирования, для которого Эрланг не создавался, под который не затачивался, который ты упорно игнорируешь в сообщениях собеседников. В своих тезисах ты описываешь лишь те особенности параллельного программирования, под которые так или иначе заточен Эрланг. А вокруг живёт большой мир со своими задачами и своими потребностями, нельзя просто так взять и отвернуться от него.

Кстати говоря, вот еще один совсем свежий пример от NVidia по задействованию мощностей современных GPU: MapD. Что, очевидно, так же находится совсем в другой стороне от тех областей, для которых предназначался как сам Erlang, так и actor model, на базе которой Erlang и построен.

M>>Твое упорное нежелание понимать, что тебе пишут, просто удивительно.
M>>У тебя есть конкретные возражения по тому, что я написал? Ну именно возражение, а не битье себя пяткой в грудь в стиле «у меня клиенты создают 100500 потоков без управления».

N>Я согласен с so5team, он несколько раз опровергал именно что твои тезисы.

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


N>Есть разные параллельные задачи, которые решаются разными способами. Ты перечислил всякие GUI-потоки, задачи телекома и

N>Ещё раз: основная критика именно что твоих тезисов заключается в том, что они описывают лишь те задачи и средства их решения, которые есть в Эрланге и которые он способен решать. То есть проблема не столько в тезисах, сколько в их ограниченности.

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

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

S>Кстати говоря, вот еще один совсем свежий пример от NVidia по задействованию мощностей современных GPU: MapD. Что, очевидно, так же находится совсем в другой стороне от тех областей, для которых предназначался как сам Erlang, так и actor model, на базе которой Erlang и построен.

Мне больше нравится вариант с openacc — не видел ничего более простого в других языках. ) Интересно, если хоть что-то сравнимое (а так же ещё на тему SIMD — тоже же распараллеливание) в Эрланге... )))

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

M>Что такое управлять потоками?

M>Все просто. Мы запустили поток, нам нужно:
M>- Знать, что поток выполняется
M>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой)
M>- Возможно, перезапустить поток, если он завершился
M>- Убить поток, если это необходимо

Зачем всё это? (зачем управлять потоками)
Почему нельзя положиться на рантайм — пусть он управляет. Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.

Что за глупость убивать поток?
Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток?


M>Что такое общаться друг с другом?

M>Все просто. Часто одному потоку надо знать о промежуточном состоянии другого потока или передать в другой поток какое-то свое промежуточное состояние. Как простейшие примеры:
M>- UI поток должен узнать, что что-то изменилось в долгоиграющем потоке, чтобы обновить свое состояние (прогрессбар, например)
M>- Долгоиграющий поток должен узнать, что что-то изменилось в окружающем мире, чтобы продолжить работу (появились новые данные, изменилась конфигурация и т.п.)

Не вижу здесь никакой проблемы: пусть UI узнает. Надо чтоб узнал — сообщи ему об этом, или пусть сам спросит, только не у потока, а у объекта, который ему предоставит Task<T>.Result .
Долгоиграющий поток????
Зачем такое что он делает: ждёт всю дорогу или что-то делает? Если он чего-то ждёт всю дорогу — то чего-нибудь дождётся, если что-то делает, то обрывать его плохая идея — пусть делает, и когда будет готов, то сам проверит.


M>

M>There is no portable way in C++11 (that I'm aware of) to non-cooperatively kill a single thread in a multi-thread program (i.e. without killing all threads).

И слава богу!
Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.

M>Потому что даже фраза «потоки могут общаться друг с другом» являются китайской грамотой для языков, в которых while(shared_variable != true) execute() является единственным способом общения между потоками

Я, кстати, тоже не совсем понимаю что такое общение между потоками. Пояснишь?
Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.



M>Механизмы и инструменты которые Erlang предоставляет из коробки, выросли напрямую из необходимости соответствовать этим требованиям. По некоторым пунктам:
M>1. Требует возможность создать множество параллельных процессов, которыми надо управлять, и которым надо общаться между собой.
M>2. Требует гарантий на время отклика системы
M>3. Требует механизмов для распределения системы по нескольким компьютером, что тянет за собой множество требований. Например, если умерла система X, система Y должна иметь возможность гарантированно об этом узнать
M>5. Нужны из коробки механизмы управления крупными системами (в случае с Эрлангом — управления множеством процессов)
M>8. Нужно иметь возможность обновить систему, не останавливая ее, что тянет за собой множество требований: как заставить долгоживушие процессы обновить код, что делать со stale code в памяти, как производить апгрейд структур в памяти и т.п.
M>10. В частности: если процесс умирает, он не должен утянуть за собой всю систему. Если процесс умер на машине X, об этом надо гарантированно узнать на машине Y и т.п.

Ты заешь что такое PAGE_FAULT?
Это то, от чего ты не можешь избавиться и то, что лишает тебя любых гарантий на время отклика системы.
В связи с этим, расскажи мне, как Erlang это гарантирует — не верю.

По остальным пунктам тоже комментарии не помешали бы.

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

M>С качеством изложения у меня все в порядке.

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

Я, конечно, понимаю, что уровень дискуссий в СВ обычно низок, и прорабатывать ответы тамошним оппонентам — это зачастую "метать бисер перед свиньями". Однако слишком активное участие в СВ, очевидно, расслабляет, и тебя заносит в общении со значительно более вменяемыми оппонентами. Именно об этом тебе и пытаются сказать. На твоем месте я бы прислушался.

M>>С качеством изложения у меня все в порядке.

CX>Нет. Это объективный наблюдаемый факт. Дискуссии ты ведешь плохо, потому что не утруждаешь себя тщательной проработкой ответов оппонентам.

Я оппонентам отвечаю ровно до тех пор, пока эти самые оппоненты не начинают прыгать из стороны в сторону, переводить темы и придираться к сугубым частностям.

Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я.

M>>Все просто. Мы запустили поток, нам нужно:
M>>- Знать, что поток выполняется
M>>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой)
M>>- Возможно, перезапустить поток, если он завершился
M>>- Убить поток, если это необходимо

Ф>Зачем всё это? (зачем управлять потоками)

Тут наш коллега Ikemefula спрашивает, почему я считаю, что люди не читают, что я пишу. Ну а как еще говорить, если пишешь, зачем управлять потоками, и тут же тебя спрашивают: а зачем управлять потоками?

Ф>Почему нельзя положиться на рантайм — пусть он управляет.

Действительно, ведь рантайм наделен телепатической силой и знает о том, что программист хочет сделать.

Ф>Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.

Для не-Erlang'иста это — нереализуемо даже в самых страшных (или влажных) снах. Не потому что «это не нужно» ©, а потому что другие языки (и доступные для них библиотеки) не предоставляют ни малейшей поддержки для реализации такого.

Ф>Что за глупость убивать поток?
Ф>Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток?
Ф>И слава богу!
Ф>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
Ф>Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира.


Простейший пример, который я чуть ли не в каждой первой десктопной прграмме: фоновые задачи. Например, всякие IDE индексируют файлы для поиска, компилируют программы и т.п. в отдельных потоках, не влияющих на GUI-поток. Ты не поверишь, но возникает необходимость выполнение этих задач прекратить. И таких примеров (управление потоками и прочее, что я описал) сотни. Надо только немного подумать и взглянуть за пределы своих уютных мирков.



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

M>И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка. Смешной момент: всякие лямбды, замыкания и прочая функциональщина прекрасно себе решались Boost'ом, но появление всего этого в С++11 было воспринято просто на ура. Но когда заходит речь о многопоточности, например, внезапно общее отношение кажется таким: все решается библиотеками легко и просто нафига это на уровне языка? Понятно, что это относится не только к С++.

Лямбды в бусте были на основе expression templates, они были малоюзабельны, поэтому их появление в стандарте и восприняли с энтузиазмом. Появление всего остального, в том числе и тредов с мьютексами было воспринято с этузиазмом тупо потому что теперь не нужно тащить буст в виде зависимости. Появление атомиков было воспринято с энтузиазмом потому что даже в бусте их не было. Точнее было в details пространстве имен в библиотеке boost.interprocess и все. Бустовские потоки люди продолжают использовать просто потому что там больше возможностей есть.

M>- С++. Стандарт С++11. http://en.cppreference.com/w/cpp/thread Уровень примерно на уровне WinAPI середины 90-х. Потоки, мьютексы. Ну еще есть futures.
Во первых, futures вполне себе равноценны (если они конечно композируются как надо). На мой взгляд это очень клевая абстракция, она может объединять параллельные вычисления и всякие асинхронные api. В общем, попробуй докажи сначала что furures это что-то плохое.

M>Еще раз повторю. State-of-the-art для практически любого современного языка программирования является: создание OC-потоков и процессов, общение между потоками через разделяемую память, мьютексы. Буквально единицы представляют еще и асинхронные вызовы через futures/promises, но и они обычно являются отдельным потоком/процессом в ОСи с общением через разделяемую память.
Выделенное — очень спорно, требует пояснения или доказательства. State of the art в этой области (С++ и многопоточность) это язык Cilk++ а вовсе не новый стандарт С++. Ну и ты тут про concurrency в основном говоришь, но ведь еще есть параллельность, векторизация. Я могу на С++ написать простой цикл обсчитывающий массив, компилятор его векторизует и он будет работать как целый erlang кластер а еще я могу директивы OpenMP для data parallel вычислений расставить и все будет еще лучше, без всяких mutex.lock (которые тебя так пугают).

M>Еще раз для тех, кто в наглухо запаянном танке: это — state-of-the-art, кодифицированный в стандартах языка и его стандартных библиотеках. О third-party библиотеках я еще не начал говорить.
Это очень спорно, в стандарты обычно включают как раз наоборот, очень старые и всем понятные вещи (мьютексы потоки), а сомнительные вещи не включают (зеленые потоки, акторы и все такое).

M>Если у тебя однопоточное приложение — проходим мимо. Как только потоков становится N > 1, все становится очень печально (в большинстве языков). Потому что потоками надо управлять и потокам надо общаться друг с другом.

State of the art как раз в том, чтобы потокам как раз как можно меньше общаться друг с другом.

M>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? Никакие. Нет таких инструментов. Вплоть до смешного:

M>

M>There is no portable way in C++11 (that I'm aware of) to non-cooperatively kill a single thread in a multi-thread program (i.e. without killing all threads).

Во первых, ты наверное понимаешь почему в ерланге можно остановить процесс. Потому что он исполняет байткод, поэтому VM может проверить — не нужно ли остановить поток и, собственно остановить его. С++ приложение как правило компилируется в нативный код, который нельзя так просто остановить. Есть ОС вызов для того, чтобы убить поток, но вот штука в том, что в документации _ОС_ сказано что его нельзя использовать практически никогда. Тем не менее потоки останавливать можно даже в С++, в boost.thread есть ф-я interrupt, она позволяет прервать выполнение потока. Поток прерывается не в любом месте а в одной из interruption-points (многие вызовы из boost.thread являются interruption points, также их можно вручную расставлять). Можно прервать поток в любом месте, но в этом случае поток не должен выделять память, пользоваться большинством системных вызовов и общаться с внешним миром он должен только через lock-free структуры данных. В этом случае поток можно прибить через TerminateThread. Я точно знаю что такой подход исползовался в одном из известных антивирусов для запуска файловых сканеров, файл скармливался такому потоку через lock free очередь, при этом если сканер работал слишком долго можно было сделать terminate thread и продолжить работу.
В общем, тормознутый байткод можно легко остановить (js в бразуере или VM ерлагна), с нативным кодом все сложнее, это плата за эффективность.

M>В 1993-м году заведующий этой лабораторией Bjarne Däcker сформулировал накопившийся опыт построения телекоммуникационных систем так (цитирую по DÄ2000):

M>

M>1. The system must be able to handle very large numbers of concurrent activities.
M>2. Actions must be performed at a certain point in time or within a certain time.
M>3. Systems may be distributed over several computers.
M>4. The system is used to control hardware.
M>5. The software systems are very large.
M>6. The system exhibits complex functionality such as, feature interaction.
M>7. The systems should be in continuous operation for many years.
M>8. Software maintenance (reconfiguration, etc) should be performed without stopping the system.
M>9. There are stringent quality, and reliability requirements.
M>10. Fault tolerance both to hardware failures, and software errors, must be provided.

M>(tl;dr по списку: люди, которые говорят, что это — маркетинг буллшит просто не имеют ни малейшего понятия, что они несут)
Это я говорил, ну вот например что можно сказать про №5 или про №7? Можно сказать "спасибо кэп", может в 93-м это было чем-то новым, но вот сейчас это все является нормой жизни для любого софтверного проекта. №3 — several computers Крал! Я тебе в той ветке пытался показать что в реальных системах люди без ерланга это все решают, но выяснилось что я читать не умею.

M>По внятности всех размалывает Erlang. Потому что он из коробки предоставляет удобные, мощные, единообразные и предсказуемые инструменты для создания многопоточных приложений. Не удивительно, что эти инструменты медленно, но верно проникают в другие языки и библиотеки других языков. Потому что многопоточность и распределенность — это не сказки для подрастающего поколения времен DOS'а, а суровая реальность, и с убогими thread.create и mutex.lock в ней не выжить. Но еще некоторое время себя можно обманывать, что «подходы Erlang'а не нужны» и т.п. neFormal все парвильно сказал достаточно рано во всей этой дискуссии

Автор: neFormal
Дата: 05.06.15

:
M>[q]

Все эти "суровые распределенные системы" вообще не про языки программирования вообще ни разу.
Все эти сложности, которые исправляли создатели erlang-а в реальных системах чаще всего не встречаются — сложная распределенная система? Можно наплодить процессов общающихся друг с другом, а можно все сделать вокруг share nothing архитектуры написав однопоточные сервисы не общающиеся друг с другом вообще никак (привет 99% веба). Нужна горячая замена кода? Пишем скрипт для выливки (pupet, ansible) выводящий сервисы из балансировки, деплоящий код и рестартующий их по одному. Отказы оборудования — пишем репликацию одинаково на любом языке (chain replication, state machine replication и тд). Ну ты понял в общем.

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

M>Тут наш коллега Ikemefula спрашивает, почему я считаю, что люди не читают, что я пишу. Ну а как еще говорить, если пишешь, зачем управлять потоками, и тут же тебя спрашивают: а зачем управлять потоками?

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

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

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

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

CX>>Нет. Это объективный наблюдаемый факт. Дискуссии ты ведешь плохо, потому что не утруждаешь себя тщательной проработкой ответов оппонентам.

M>Я оппонентам отвечаю ровно до тех пор, пока эти самые оппоненты не начинают прыгать из стороны в сторону, переводить темы и придираться к сугубым частностям.

M>Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я.

Есть очень четкая корреляция — тобой написаное хорошо понимают в основном люди с опытом в эрланге. Это демонстрирует, что ты объясняешь как будто сам себе.

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

Ф>Зачем всё это? (зачем управлять потоками)

а почему бы и нет?

Ф>Почему нельзя положиться на рантайм — пусть он управляет. Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.

плюсопроблемы.

Ф>Что за глупость убивать поток?
Ф>Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток?

ПА-НИ-КО-ВАТЬ! ААА!

Ф>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.

но это же проблема реализации, а не идеи

Ф>Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.

ну да, всё верно.
если технология не позволяет освобождать внешние связи, то всё плохо.

Ф>Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.

да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности.
а чем идея плоха?

M>>Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я.
I>Есть очень четкая корреляция — тобой написаное хорошо понимают в основном люди с опытом в эрланге. Это демонстрирует, что ты объясняешь как будто сам себе.

Есть очень четкая корреляция: люди не понимают написанное даже если там больше половины текста про Эрланг вообще не упоминает. Ты, например, тому тоже яркий пример