Из Erlang/Elixir в Java и обратно. Приключение на 20 минут

Во-первых, у либы из статьи тоже есть spring-интеграция (вот, например, эхо сервер с клиентом), причем с готовым databinding'ом а-ля Jackson, ток для Erlang'овских термов.

Ну а во-вторых, каким бы кролик замечательным (сам им пользуюсь в одном из проектов, вот прям щаз) ни был, это всё равно дополнительный инфраструктурный элемент, от которого хотелось бы избавиться, если есть возможность, так как он тоже имеет свои накладные расходы и, повторюсь, затраты на поддержку, ибо докерный образ кто-то тоже должен поднять, а где хранить креды к кролику? «А настройте мне вот тут эксчейндж», «У меня была очередь и теперь её нет», «А кто нибудь это уже синькал со стейджем?» — и многие многие другие радости. Иными словами — это не бесплатно.
Тут же — нативное общение для Эрланга + доп обвязочки (databinding, spring интеграция) для того что бы и со стороны Java это выглядело более-менее нативно и твой мейлбокс походил на какой нибудь спринговый контроллер.

Лично для себя, я вижу область применения такой либы, когда для тебя Erlang/Elixir — это шина, клей твоей системы с парой-тройкой инфраструктурных сервисов внутри. BEAM VM держит кучу соединений, на нём приятно писать какую нибудь маршрутизацию, балансировку, сервис дескавери, распределенный ин-мемори кэш.

В общем замена: nginx, redis, RabbitMQ, etcd сервисов и Zuul, Eureka (это из Spring Cloud)… ну Apigee для бедных, кароч)

Из Erlang/Elixir в Java и обратно. Приключение на 20 минут

Там на сайте есть новая статья, в которой есть раздел с маппингом Java2Erlang. Но не написано что есть ещё класс со статическими хелп-функциями — Erlang

Конкретно твои примеры выглядят так:

import static io.appulse.encon.terms.Erlang.atom;
import static io.appulse.encon.terms.Erlang.bstring;
import static io.appulse.encon.terms.Erlang.map;
import static io.appulse.encon.terms.Erlang.string;
import static io.appulse.encon.terms.Erlang.tuple;

import io.appulse.encon.terms.ErlangTerm;

// {ok, <<"Result">>}
ErlangTerm message1 = tuple(atom("ok"), bstring("Result"));

// {ok, "Result"}
ErlangTerm message2 = tuple(atom("ok"), string("Result"));

// #{key => value}
ErlangTerm message3 = map(atom("key"), atom("value"));

// #{"key" => <<"value">>}
ErlangTerm message4 = map(string("key"), bstring("value"));

С мапами, как в Guava хелпер был — они идут vararg массивом, нечётный элемент — ключ, чётный — значение (что и видно в примере выше).

Никто не мешает через конструктор всё создать, но на мой вкус тут статические функции лаконичнее выглядят.

Из Erlang/Elixir в Java и обратно. Приключение на 20 минут

Так получится ещё одна дополнительная сущность в виде гномика кролика. Её нужно так же саппортить, деплоить, реплецировать, чёт туда править… это ж усложнение системы.

Наверн, если кролик уже в системе, то это имеет смысл, а если нужно просто скрестить Erlang/Elixir с Java (например, ты мигрируешь из одного в другое) — то encon тут супер подходит

На софт наложат десятину: Путин поддержал предложение обложить продажи ПО 10%-ным налогом

— Но я не об этом мечтал!
— А сбылось это…
(ц. реклама Билайн)

Изучаем Java EE 7

По ссылке на книгу нет возможности купить электронную версию