4 ms·
Seems like there is less and less reason for not using Erlang for distributed coordinated compute broker tasks. I have a stateless java backend servicing REST
by semilattice 5y ago
Seems like there is less and less reason for not using Erlang for distributed coordinated compute broker tasks.
I have a stateless java backend servicing REST APIs.
These backends are load-balanced by nginx.
Now the time is approaching where I need to introduce some form of global state (that involves global caching, message passing, registering/discovery of known workers, periodic (cron-like tasks), etc).
I would much prefer a single tool to add to my backend stack (currently Java + postgres) to cover most of the above needs.
With the performance improvement + persistent_term [1] -- in current Erlang, I basically get:
- a light weight distributed K/V cache
- a ZeroMQ like on-wire messaging system (built into erlang)
- discovery/coordination
- a distributed compute grid
- a way to write my own routines within that compute grid, and have them exposed via Java interface to my existing backend.
I do not need 'fastest' possible performance or least memory consumption. I just need them to be 'reasonable', 'known' and 'controllable' (not to exceed some baseline).
Erlang is just looking better and better (and I prefer its syntax to Elixir, for some reason.).
[1] https://erlang.org/doc/man/persistent_term.html https://erlang.org/doc/man/persistent_term.html
- pdimitar 5y agoDo consider Elixir for its metaprogramming (macros) and the goodies that come with them, namely fantastic libraries and frameworks like Ecto and Phoenix.