Кто имеет опыт перехода в Эрланг/Эликсир-вселенную после Си++ и многопоточки

в нём (из стандартной либы последних версий Стандарта или POSIX threads) ?
Что изменилось в мировосприятии, в каких местах были затыки и спотыкачи мировосприятия и проектирования ПО? Что было необычным? В чём проявились явные плюсы?
Кто-то работал в QNX до Erlang-а? Никаких "параллелей" не просматривалось?

в С++ обмазываешься мутексами и всё равно не спасает, а тут ищешь способ, как всё таки пошарить память

Очень оригинальная и загадочная формулировка-описание! :) Не расширите и углУбите?

У меня возникли сразу два вопроса: 1) зачем в Си++ "обмазываться мьютексами" И 2) зачем в Эрланге искать способ "заварить память" ? Просто у вас взаимоисключающие стремления в одном предложении. Должно было одно из них остаться, в зависимости от задачи и выбранного средства её решения... :) Ну, насколько я уже сравнительно осведомлён... :)

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

В Эрланге - ВСЕ переменные иммутабельны? 😳

да

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

Может повлиять косвенно (в efficiency guide написано "как") + можно посмотреть в какие инструкции код скомпилировася. В целом, не всё так плохо, а если плохо, то всегда можно переписать на плюсах/расте/смешной третьей опции

А как же с носителями состояний сущностей модели предметной области? Чем и как фиксируется переход из состояния в состояние? Или мне надо заново копию объекта порождать, копируя туда все данные, за исключением тех, что изменились??? Хотя - ладно! Пока обожду "со своим уставом в чужой огород"! :))) Почитаю пока... А то ведь - "в каждой избушке - свои погремушки". :)

да, каждый раз все копируется

У меня - прединфарктное состояние практически...

А что за третий «смешной» вариант 🧐

Всё, что придёт каждому читателю на ум в первую очередь

Новичку проще думать что копируется. Будет желание можно будет погрузиться в потроха компилятора/BEAM, посмотреть как оно на самом деле работает.

Я понимаю, что там - реализация механизмов "несколько иначе". Но мне, на высоком уровне проектировщика ПО - как-то жутковато... с непривычки...

Это пройдет. :) Но потом, кстати, станет сложнее переключаться между Эрлангом и «мейнстримом». Потому что появляется привычка не думать о том что кто-то может структуры в других потоках менять.

Можно на всё это смотреть как на растовский .clone(). Или rwlock + clone. Или arc. Смотря где, в общем. Но самое главное, что всё под капотом "само" работает, и можно заниматься проектированием приложения, а не приседать с сегфолтами или борроу чекером. Ну и аллокатор умный ещё

да, абстракции, которые не протекают, сродни наркотику

Вот тут можно в некоторые детали погрузиться.

Не-не-не! Погодите! Я - "ещё маленький" в Эрланге! Новорождённый, можно сказать... Я пока - ходить научусь!

как раз на высоком-то уровне должно быть по барабану, не так ли?

Ну... в идеале...

ну вот сначала дубасим, смотрим, что получилось, при необходимости оптимизируем/переписываем, GOTO 10

Если у тебя все «переменные» - неизменяемые, то копировать указатель на них - безопасно. 💁‍♂️ Поэтому, например, стоимость «копирования» списка без головы равна одному слову. Или например стоимость копирования рекорда {x: 1, y: {deep nested shit}} при изменении x равна двум словам.

Есть иммутабельные структуры данных, которые копируются не полностью при изменении, а лишь частично. Скорость доступа и изменения у них либо аммортизированная (как у персистентной очереди vs обычной мутабельной очереди), либо на логарифм медленнее (как у персистентного массива и мутабельного массива) Полностью копируются только массивы байтов (aka binary) размера до 64 байт, и tuple (и то там много оптимизаций) Помимо этих специализированных структур, рантайм и компилятор проводят много нехитрых оптимизаций, поэтому можно писать код так, чтобы компилятор мог доказать что больше одного экземпляра данных не нужно, и можно делать всё in-place (для тех же tuple так). В целом получается конечно медленнее чем с классическими мутабельными структурами, зато всё thread safe Советую почитать книгу Криса Окасаки "Чисто функциональные структуры данных", если захочется углубиться в эту тему.

Зачем thread-safe в языке обменивающимся сообщениями?

Ну вот в Го можно послать в канал указатель на кусок памяти и менять эту память одновременно из двух горутин 💁‍♂️

Я просто подумал речь про erlang в последнем сообщении

Ну правильно, про эрланг. Ты спросил почему нужно thread safe в языке обменивающемся сообщениями, я привел пример языка, в котором обмен сообщениями не thread safe и чем это грозит

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

Они threadsafe потому что копируются, об этом и речь

Какие иммутабельные структуры? Или тут речь вообще на не про erlang ?

Threadsafe это как раз про разделяемые данные