Я добавляю эвристические данные вашим утверждением. MQ и mnesia стоят на одном уровне вариантов у вас, хотя реальный вес у них разный.

один я только в хайлоад чемпионат заявился с эликсиром ))) а все умные на си

Я не сравниваю MQ и Mnesia, это разные вещи. Откуда вы сделали вывод, что я говорю про MQ=Mnesia?

ну сейчас модно миркосервисы/сервисы, а там этот ваш эрлонг будет только мешать.

Намажете кластер/ets/mnesia а потом парням из node.js хавать это все, не по-христиански это!

вот, коллеги, совсем другое дело!
а то сообщество мертво и всё такое

У меня просто личная боль от микросервисов такая же как у коллеги от Mnesia 🙂

”Надо применять тот инструмент, который решает проблему, а не тащить везде Redis/RMQ/Kafka если можно решить вопрос DETS/Mnesia + ERL Cluster.” - это звучит как “Надо применять то транспортное средство, с которым лучше/быстрее можно добраться до цели, а не ездить везде на машинах/самолётах/кораблях, иногда лучшее может быть осёл.” - Вес у решений проблемы разный. Я не отрицаю, что и осёл может быть хорошим средством передвижения, но другие варианты имеют другую весовую категорию в частоте применения, удобства и достижения цели.

Я не говорю про сравнение в целом, я говорю о весе инструментов. Понятно, что маршруты(проблемы) бывают разные, где вода, на машине не проедешь.

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

Не думал, что технические специалисты будут скатываться в полемику. Но с точки зрения бизнеса иногда осел - правильно решение. Ведь он не добавляет проблем в Business Continuity и Disaster Recovery. Те же самые протоколы ISO8583 тонко на это намекают (а ведь вагон и маленькая тележка процессингов карточных до сих пор на них работают). Просто вы пытаетесь сказать, что я использую осла вместо вашего красивого ферари, а я говорю, что я использую надежный Volvo вместо вашего ломучего говна (раз уж пошла полемика).

У систем есть очень разные требования по SLA и отказоустойчивости, это комбинируется часто с регламентами на время ответа/количество ошибок и связи с другими (внешними) системами. И иногда не то, что Mnesia даже Elixir/Erlang будет херовым решением для покрытия этих требований. Все-таки не стоит забывать, что разработчик - это тот, кто решает бизнес задачу, а не строит космолет, на котором он с понями и радугой полетит покорять марс.

Mnesia добавляет проблем в Disaster Recovery по сравнению с 99% любых других инструментов, о чём я писал выше.

Это смотря какой уровень консистентности вам необходим и как вы ее используете

Вы пытаетесь мне доказать, что Mnesia не надо использовать. Я это не понимаю, ведь она достаточно эффективно используется в RMQ.

Mnesia - нельзя испоьзовать => RMQ нельзя использвать => “Mnesia добавляет проблем в Disaster Recovery по сравнению с 99% любых других инструментов, о чём я писал выше.” - не правда. Что вы от нас скрываете? 🙂

Не правильно, я пытаюсь доказать, что Mnesia нужно очень досконально изучать, прежде чем использовать.

“The default behaviour of mnesia is not to attempt automatic merge after a 'partitioned network' event. It detects and reports the condition, but leaves it up to the user to resolve the problem.” => Вот у тебя нетсплит и делай теперь что хочешь, ищи и решай проблему, пока у тебя даунтайм.

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

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