Хочу простой кроссплатформенный message passing, посоветуй

наверное кроликMQ

Rabbitmq или можно тупо через redis)

Ищо есть nanomsg.

Ок, спасибо за совет

Rabbitmq же

Да понял, понял. А позвольте спросить, почему именно rabit, а не какая другая mq?

Потому что erlang = надежность, а 0mq — C, которые «течь, ошибки и уязвимости»

erlang
надёжность

Жертва маркетологов

Да нет же!

- маркетологи бегут от erlang как черти от ладана.

по идее текучести, все что можно, имеет смысл заменить на эрланг- реализации

У них в спам-фильтре забито вместе с enlarge

web services

мыло?

Можно не по теме вопрос? Для чего вообще принято использовать ZeroMQ и аналоги?

это из серии что такое javascript?

- это скрипты на java с добавлением виагры

web services

Первая мысль была. Но вот что-то мне подсказывает что оверхед это. Задача такая: есть десяток утилиток, которые делают что-то одно, написаны они все на чем попало и разными людьми, исходные коды есть. Надо их быстро и безболезненно подружить

http

Выбери Эрланг. Выбери стратегию супервайзора. Выбери максимальную частоту крешей. Выбери динамическую типизацию и нечистые функции. Выбери process dictionary. Выбери тормозной BEAM. Выбери глобальное пространство имён процессов. Выбери убогие guard-expressions. Выбери костыльные records. Выбери =ERROR REPORT==== 4-Feb-2015::13:10:11 === Error in process <0.1283.5604> on node 'Erlang__poo1_1_2_3_5@crap8s13s21' with exit value: {{badmatch,undefined},[{weird_shit,is_shit,0,[{file,«shit/weird_shit.erl»},{line,391}]},{weird_shit,handle_call_exit,3,[{file,«shit/weird_shit.erl»},{line,372}]},{weird_shit,flush,1,[{file,«shit/weird_shit.erl»},{line,533}]},{lists,foreach... Выбери потерю ценных данных и мегабайтные трейсы из-за пропущенной буквы. Выбери падение VM из-за не поматченных в одном процессе сообщений, которые вообще непонятно откуда пришли. Выбери crashdump viewer. Выбери кастомера, который залез в REPL и нечаянно всю VM. Выбери закоррапченный стейт процесса, приводящий к каскадному падению всей ноды. Выбери Erlang.

Ай-яй-яй какой эрланг нехороший и противный ...

... еще забыл наверное про выбор имакса

https://github.com/grpc/grpc мб допилили уже до вменяемого состояния.

Потому что erlang = надежность, а 0mq — C, которые «течь, ошибки и уязвимости»

Ни разу не видел кролика, падающего с ошибкой из-за mnesia?)

fault-tolerant

fault-tolerant

А если только одна нода запущена?)

Еще тогда проще переподнять и вообще емнип предпочтительнее использовать т.н. RAM-ноды.

Выбери process dictionary

ССЗБ

Выбери костыльные records.

Из тех, кто любит поля к записям добавлять/удалять постоянно?

Выбери =ERROR REPORT====

Нормальный репорт

Выбери потерю ценных данных и мегабайтные трейсы из-за пропущенной буквы

А ты не пропускай буквы

Выбери падение VM из-за не поматченных в одном процессе сообщений

Не хотите ли поговорить о catch-all кострукциях?

Выбери кастомера, который залез в REPL и нечаянно всю VM

erl ... -noshell -noinput -detached

ZeroMQ. Nanomsg, к сожалению, не готов для продакшена.

ССЗБ

Не надо валить на меня фичу, которая есть в языке. Если фича есть, её будут использовать. «Ну уж я-то точно знаю, когда %dangerous feature% нужна» — думают все твои коллеги.

Из тех, кто любит поля к записям добавлять/удалять постоянно?

Для этого в серьёзном софте используют совершенно особые костыли с кодогенерацией и прочим. До этого мы ещё не дошли. Я пока про удобство чтения логов и работы в REPL.

Нормальный репорт

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

«Let it crash» — полная брехня. Это всё равно, что не пользоваться ремнями безопасности и нарушать ПДД только потому, что есть медицинская страховка.

Не хотите ли поговорить о catch-all кострукциях?

В такой ситуации вся VM ложится, что там catch-ить? Да, можно сделать receive _, но это очередной костыль от динамической типизации, который может ненароком привести к потере данных, если receive блоков в одном процессе несколько.

erl ... -noshell -noinput -detached

Да, это выход.

А ты не пропускай буквы

А ты не допускай утечек памяти. А ты не разыменовывай нулевые указатели. А ты не попадай в катастрофы.

Не надо валить на меня фичу, которая есть в языке. Если фича есть, её будут использовать. «Ну уж я-то точно знаю, когда %dangerous feature% нужна» — думают все твои коллеги.

Из оф.доки (http://www.erlang.org/course/advanced.html):

Note that using the Process Dictionary:

    Destroys referencial transparency
    Makes debugging difficult
    Survives Catch/Throw 

So:
    Use with care
    Do not over use - try the clean version first 

Так что все-таки ССЗБ.

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

Словоблудие.

В такой ситуации вся VM ложится, что там catch-ить? Да, можно сделать receive _, но это очередной костыль от динамической типизации, который может ненароком привести к потере данных, если receive блоков в одном процессе несколько.

Если уж ручками receive/! делаете, то будьте добры catch-all делать. Либо юзайте gen_server который не даст распухнуть мэйлбоксу. Если gen_server слижком тяжеловесен или не подходит, то сделайте свой behaviour который будет создавать процесс и следить чтобы он гарантированно обработал каждое сообщение. Но нет, мы будем сидет по форумам и ныть что плохой Эрланг не угадывает того что yам нужно.

А ты не допускай утечек памяти. А ты не разыменовывай нулевые указатели. А ты не попадай в катастрофы.

А я не пропускаю буквы - автокомплит и подсветка в IDE не дает.

Из оф.доки

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

Словоблудие.

Страус, голова, песок.

Если уж ручками receive/! делаете, то будьте добры catch-all делать.

Опять _я_ должен что-то делать. В нормальном языке процессу просто нельзя послать сообщение, которое он не может/хочет обработать.

А я не пропускаю буквы - автокомплит и подсветка в IDE не дает.

...

Опять _я_ должен что-то делать. В нормальном языке процессу просто нельзя послать сообщение, которое он не может/хочет обработать.

Не говори мне о каких-то языках в вакууме. Говори за Эрланг. Что тут должно происходить?

foo() ->
   self() ! foo,
   self() ! bar,
   receive
      bar -> ok
   end.

Erlang должен засрать консоль гневными сообщениями о том что в foo() non-exhaustive receive? И не дать скомпилить модуль?

Erlang должен засрать консоль гневными сообщениями о том что в foo() non-exhaustive receive?

Ужас какой. Нет конечно. Каждый процесс параметризуется типом сообщений, который он обрабатывает. Не то шлёшь — ошибка типов в компайлтайме.

Говори за Эрланг

Краткое изложение: Эрланг - динамически типизированное говно с понтами.

Каждый процесс параметризуется типом сообщений, который он обрабатывает. Не то шлёшь — ошибка типов в компайлтайме.

А динамическую загрузку/обновление кода как сюда присунуть? Вот умел наш gen_server только foo и bar ловить, мы код поправили так что теперь он еще и {'DOWN' ...} ловить может. И вместо того чтобы новый beam-файл подсунуть в каталог, придется в твоем случае останавливать gen_server, прибивать все его зависимости и по-новой запускать.

Ваше мнение очень важно для нас, оставайтесь на линии.

AMQP?

Когда нужны сокеты, но не хочется самому писать кучу кода обёртывающего соединения.

А динамическую загрузку/обновление кода как сюда присунуть?

Если интерфейс (т.е. типы gen_server коллбеков) не меняется, то ровно с тем же успехом.

Если же меняется интерфейс, то и все зависимые процессы (по логике !) придётся перезапустить, поскольку это заафектит и их логику.

Если интерфейс (т.е. типы gen_server коллбеков) не меняется, то ровно с тем же успехом.

Внешний интерфейс gen_server'a не изменился, поменялись callback'и, т.е появился еще один handle_info({'DOWN' ... }, ...). Т.е. для внешнего потребителя все по-старому осталось. Но так как

Каждый процесс параметризуется типом сообщений, который он обрабатывает. Не то шлёшь — ошибка типов в компайлтайме.

то для обновления кода нужно: остановить все процессы зависящие от этого gen_server'a, остановить gen_server, загрузить новый код, запустить gen_server, запустить его зависимости. И это при том, что для потребителей ничего не поменялось, а изменилась только внутренняя логика работы gen_server'a.

Ваше мнение очень важно для нас

Знаю.

оставайтесь на линии.

Не, если еще что хотите узнать - сами звоните.