У нас в джаве не нужно напрямую работать с памятью!

забудьте о ней, все за вас сделает gc! что? хочешь попрограммировать в несколько потоков? о, ну тогда тебе просто необходимо изучить java memory model, без этого никуда!🤦‍♂️

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

я про то, что поиски преимуществ языка должны исходить из его преимуществ, а не недостатков. поэтому ответ на вопрос "зачем нужен эрланг?" должен начинаться с "вот ЭТО на нем делать удобнее/дешевле/быстрее/нужное_вписать чем на моем языке". я ж не просто так привел джаву - по написанию многопоточного кода Э ее заруливает просто в сухую, в одну калитку. если представить себе ситуацию, когда у меня будет множество объектов, которые не контролируемо влияют друг на друга в относительно реальном времени, то я с ужасом думаю, как это реализовать на джаве, а вот эрланг по прикидкам подходит идеально. остается вопрос - много вокруг таких проектов? или в основном формошлепство, круды, и прочие веб-сервисы "запрос-ответ"? вот тебе и ответ и где Э хорош, и почему он в жопе

"множество объектов, которые не контролируемо влияют друг на друга в относительно реальном времени" это массово что вообще обычно? бэкенд игр?

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

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

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

С#? Swift? Rust? Почему все сравниваем с жабой? Есть и другие языки.

да я ж не мешаю, сравни с чем захочется🤷🏻‍♂️

Эрланг пытаются затащить в финтех хоть тушкой хоть чучелом, а там царит жаба. 😁

там царит scala

в техстеке одного синего банка его нет, есть только элик, но написано ли на нем что-то я хз

Это всё равно JVM. Так-то и котлина хфатает.

Скорее еликсир пытаются затянуть в финтех, и то через крипту

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

банк

банк в смысле "веселая игра в мобильном приложении", не АБС

нет, настоящий

Ну к сожалению (а вернее к счастью) все это пишется не так: ты собираешь все инпуты а потом считаешь положение мира через 1 фпс которое отправляешь во все аутпуты. Никакой пересылки сообщений между акторами, имитирующими бизнес сущности там не надо и оно вредно.

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

Ага. Вот все эти объекты лежат в массивчике и обсчитываются за раз физическим движком

что такое "физический движок" в данном случае?

движок просчитывающий физику

Бэкенд, роутинг сообщений (от WhatsApp до MQTT). В целом любая задача где есть много бизнеслогики и всё равно нужен какой-то realtime

Функция которая получает на вход массив таких объектов и мутирует их, генерируя новое состояние мира через 1 фпс

то что ты и пытаешься написать )))

ну так речь вроде о том и идет как такую штуку написать, и был бы тут полезен Э :)

Ну так ты предлагаешь вместо куска памяти передавать в такую штуку что - пачку пидов акторов? Которые не общитываются кем-то централизованно а начинают друг другу сообщения посылать?

По-моему тут антиполезен Erlang. Акторы в эрланг это даже близко не Entity в видеоиграх. Первые создавались для равномерной нагрузки, отказоустойчивости и распределённости. Вторые нужны для то что бы деревьями мутабельных объектов управлять как можно быстрее. В играх нужны качества второго решения, а не первого

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

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