Ну, так - шо, грамодяне-эрленгяне? Все - готовы подписаться под словами

"гуру" на счёт трудности применения POSIX threads и про, конкретно, мьютексы, что "... недопоставишь мьютексов - у тебя будут рейс-кондишны, перепоставишь - дед-локи..." ?

Давай рил кейс и язык, на котором надо, сделаю всего за пару сотен

Ау! Дядько, переключись и внимательно почитай, что было написано-спрошено. Отвечайте по теме вопроса, а - не голосам в своей голове...

Лiл

Всё вылил?

Чи цэ - якысь алюзийи на потуги на "украйинську"? :)))

Да

Тоды цэ - не вирно. Залышаеться "ЛОЛ", тому, що - пряма транслытэрация з англиськойи абревиатуры ("lol").

Хорошо, спасибо, буду знать

Вы - не стесняйтесь, спрашивайте. Например, - про те же позикс-потоки или мьютексы... :)))))))

Спасибо, но про них я уже спрашивал в чате изучения украинского языка

Тонко! Хвалю. Любо.:)))

А вы писали многопоточные и асинхронные вебприложения на C/C++?

Что понимать по "веб"? Сетевые драйверы для xBSD и Linux - да, и библиотеки для поддержки некоторых низкоуровневых сетевых протоколов на микроконтраллерах - да. Сетевой обмен с их использованием (трансляция видеопотоков, речи и большого объёма параметров в реал-тайме) - да.

Вебприложения. Типа там сложный динамический вебсайт или сложный REST или какой-нибудь ещё веб API

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

На моём опыте на C++ такое очень сложно делать, и про локи правильно сказано. Как только случается первый deadlock или race condition, который дебаггер уже не поможет воспроизвести, становится очень тяжело. Поэтому люди начинают наперёд мютексы делать на каждый доступ к shared memory, который становится не таким уж и shared

Может быть, это - как раз следствия НЕПОНИМАНИЯ, как правильно проектировать? Всякий инструмент можно обругать, если просто не знать, как его адекватно и "к месту" применять...

Полностью согласен, нужно сначало проектировать и всё продумать. Сначала вы решите что надо бы поменьше мутабельности, как можно больше на стеке, refc или unique хотя бы использовать. Потом вы решите что лучше вообще память не делить, а использовать какую-нибудь систему сигналов, где поток имеет очередь из которой читает только он, а пишет любой кроме него. Потом вы решите что ещё неплохо бы придумать что-нибудь для работы в кластере, чтобы скейлиться можно было. И потом продумаете систему обработки ошибок, пуллинг. Возможно через пару лет вы даже дойдёте до тюнинга affinity и под NUMA... Ничего не напоминает? Так ещё и окажется, что эти ваши решения проектирования, они только ваши, поэтому онбординг каждого нового разработчика будет начинаться с изучения истории проекта от первого дня, под все эти ваши особенные решения. А на ревью придётся очень долго учить, почему мы вот это не используем, и вообще лучше бы вот так писать.

Так я почему и пришёл сюда... За много лет работы в реал-тайме и написания собственных "лисапедов" + работа на QNX и Minix, сформировалось ощущение и виденье, что, в ряде задач, постоянно повторяются одни и те же действия, "паттерны", "дисциплины" и подходы. Некий "общий знаменатель" организации и обмена потоками данных в сетевых распределённых системах (не только ОСях, но и системах управления, например). Я почему в одном из первых сообщений и написал, что первоначальное ("прикидочное") знакомство с Эрлангом, натолкнуло на мысль, что его создатели учли опыт работы в системах с микроядрами, строгой изоляцией процессов и передачей сообщений между процессами (с блокировками и без). Пока, что, у меня складывается отношение к Эрлангу, как к воплощению таких приёмов (описанных выше) в такого рода системах. Как к некоему "скрипт-языку", в котором закрепили соответствующие "паттерны" и "подходы". Проблема в том, что закрепление таких знаний в библиотеке (например, как в Си++ с поддержкой многопотоковости) имеет совсем другую "природу" и "уровень строгости", чем, если бы это было сделано в самом языке. Взять, опять, тот же самый Си++. Перед 11-м стандартом все ждали, что в язык будет добавлена поддержка мнопоточности... И, внезапно, оказалось, что всё это "слили" в одну из частей стандартной библиотеки! Причём, самым каличным образом! - по сути, сделали некие объектные оболочки над системной реализацией чего-то, по типу позиксных потоков. Для разработчиков НИЧЕГО не поменялось в подходах в разработке многопоточных систем. Все проблемы "решений" перетекли от использования "чистых" позикс-потоков - к использованию "классов"-обёрток. Да ещё и добавились новые "нюансы", которые - тоже надо учитывать. С одним уродством "модели памяти" и атомиками - сколько несуразностей возникает и ЛИШНИХ действий... В Эрланге (насколько я сейчас вижу), за счёт "настроенности" САМОГО языка на подобный класс задач (поддержка организации и параллельная работа ОГРОМНОГО количества "активных агентов") отпадает много проблем с "кто - в лес, кто - по дрова" при разработке таких систем "вручную". В своё время, было, конечно, интересно реализовывать свои версии "акторов" и "активных объектов". Оно работает, используется (например, в связных библиотеках нескольких фирм, разрабатывающих ПО для устройств "умного дома")... Но - всё равно. ЭТО - БИБЛИОТЕКА. Это - не строгое что-то, что согласны соблюдать пользователи- разработчики. А возможности тех же микроконтроллеров - значительно выросли. Я уже вижу, что я вполне могу теперь запускать Эрланг-систему и даже - не "париться" уже особо на счёт ресурсов. Причём, там, где даже лет 10 назад и подумать нельзя было использовать что-то, кроме Си или Форта! :) И, на этом всём, хотелось бы сформировать: "виденье", дисциплину разработки и набор подходов, которые обуславливаются не тем, что захочет МОЯ или ЧЬЯ-ТО ещё левая пятка, а - ограничениями и требованиями СТАНДАРТОВ языка. То есть, от чего мы просто не сможем "отмахнуться" или на что "забить" и иметь отговорку "я - творец, я - так вижу". Фух... Ну - вот. Примерно так.

Естественно, что мне, первым делом, хочется уяснить, как будут отличаться подходы к проектированию при использовании языков, типа Эрланга от того, к чему я привык в ОО(+многопоточность)-проектировании. Какие особенности в общем мира ФП и конкретно свойства Эрланга будут определять как способы проектирования, так и конкретные решения в проектируемых системах. И я пока не могу даже стартовые "затравки" сформулировать, потому, что наткнулся на какую-то стаю прыгающих и визжащих инфантильных бандерлогов. Отвратительное зрелище, если честно. Просто - какая-то банда инфантилов, зацикленная на каких-то своих комплексах и "чувству сопричастности". Пробиться через это (надеюсь) пока - просто невозможно. Есть несколько "центров кристаллизации" по организации галдежа и площадного улюлюкания. Пока, к сожалению, именно они и определяют основное впечатление от сообщества. Меня сейчас "частности" не интересуют. Если надо я могу и по сети пошариться-поискать ответы на вопросы по библиотекам и модулям. Меня интересуют подходы "в большом" (проектирование и приёмы работы).

Я не понял к чему это