
Elixir and Ruby can talk to each other using Erlix - thibaut_barrere
https://blog.fazibear.me/elixir-ruby-dont-fight-talk-with-erlix-24b0f5ed8d12
======
poorman
I don't see any practical use for this. You're just sending text around. This
breaks most OTP conventions, you lose insight from the Observer, etc..

If all you want is message passing you should just use something like zeromq
which would allow for a lot more than just Elixir to Ruby.

~~~
felixgallo
or [http://bert-rpc.org/](http://bert-rpc.org/) perhaps.

~~~
elcritch
Alas, most of the libraries are pretty old and not currently active. But still
seems to be a decently simple/useful spec. However, messagepack protocol seems
much more broadly supported and some new rock libs are popping up, but no
common rpc spec.

Based on those facts, I decided to build a Bert-rpc but using message pack and
geared for embedded devices. Just released (as in tonight!) the initial code
for an Arduino RPC library. It uses the msg pack for Arduino
([https://github.com/HEADS-project/arduino_msgpack](https://github.com/HEADS-
project/arduino_msgpack)), a great little library. Enjoying it much more than
most JSON libraries.

It's intended purpose is to make interacting with sub-1ghz radios and be easy
to interface with elixir. Only have basic Call and Cast semantics at the
moment, but it's only two days old. :-) If anyone's interested in helping, I
think C++11 lambda might be a feasible way to create rpc callbacks that non-
devs could use (maybe...).

~~~
felixgallo
You might also look into google protobufs ('gpb') and grpc, which are newer
solutions that make some interesting tradeoffs but focus on performance and
small size.

------
mmartinson
I'd be curious to see if this becomes viable as an interface wrapper for teams
that writing new services in Elixir while supporting important pieces of
legacy Ruby code. This seems to be the situation in a lot of Ruby shops, and
it would be fantastic to see someone getting this working at a big scale and
seeing some industry best practices emerge.

~~~
holydude
I am not sure why we need to replace Ruby with Elixir. Nor do I understand why
it is necessary to write every new code in Elixir. I mean when Crystal gets
production ready are you guys going to rewrite everything from Elixir to
Crystal ? :-| Elixir is not a substitute for Ruby. It's completely different
paradigm and language. Same for Crystal. They just happen to feel like Ruby
but are missing a lot from Ruby/Rails ecosystem.

I really like lispness of Ruby and the rails ecosystem. For a lot of things
it's still numero uno technology.

~~~
dakull
The first things that come to mind:

\- true parallelism (this is why we need guilds in Ruby 3)

\- the BEAM

\- functional yet OO at a higher level [0]

\- all the Erlang/OTP goodies for free

\- Phoenix/Ecto are quite nice frameworks and solid alternatives to the
server-side JS world

\- “looks” like Ruby though is an entirely different beast

Crystal on the other hand looks more like a Rust alternative to implement
almost-as-C-fast Ruby gems. I'm sure it can evolve into an ecosystem but since
it's quite far from being stable it will take some time, time in which the
Elixir ecosystem will grow because its Erlang foundation already fixed the big
issues.

[0] - [https://www.infoq.com/interviews/johnson-armstrong-
oop](https://www.infoq.com/interviews/johnson-armstrong-oop)

------
misterbowfinger
Interesting - makes me think of ErRuby:

[https://github.com/johnlinvc/erruby](https://github.com/johnlinvc/erruby)

Like JRuby, but s/Java/Erlang.

------
mackdaddysly
I wonder what the benefits of this approach is to say, a json driven
microservice between elixir and ruby?

~~~
sjtgraham
Running your applications in Erlang is its own microservices architecture.
Each process is essentially microservice that can interact with others on any
node in your cluster by sending messages. Everything is handled for your by
the runtime. Processes on a different node? No problem, they're easy to
discover and if a message does go to another node the serialization is handled
for you. Erlang is so powerful I'd actually invert your question.

~~~
dfischer
I hesitate using Erlang/elixir for this than aws lambda + event distribution.
Any thoughts?

~~~
abritinthebay
If you don't need low latency and are ok with the extra architectural
overhead... there's nothing wrong with that.

Different use cases

~~~
dfischer
Many are preaching erlang/elixir on the OTP/microservice alternative paradigm
– that doesn't seem as attractive as the low latency resiliency.

At least to me, as a story.

~~~
abritinthebay
Well... it's a win for both. It means it's easy to write performant and highly
concurrent microservices.

Latency is part of that.

------
15155
I would like to see a DRB <-> Erlang C Node (but in Ruby) system.

Start Ruby process, get Erlang node.

------
dakull
>the Erlang node, __witch __is connected to Erlang VM over the network.

Witches are connected to the BEAM? :) funny typo.

~~~
Cyph0n
Well, BEAM _is_ somewhat magical, so... Freudian slip?

------
pmontra
Interesting. Any real world application this has been used for?

------
amorphid
Is this more or less useful than C bindings in either language?

------
dfischer
With aws lambda elixir is less attractive to me. I wonder if anyone has
similar thoughts?

~~~
gamache
At Appcues, we use a combination of both approaches.

We have our Elixir backend where we need some combination of:

\- Low latency -- Lambda + API Gateway requests typically incur a ~200ms
invocation latency

\- Persistent connections, e.g. WebSockets

\- High performance

\- Continuous usage, let's say at least ten calls per second all day every day
forever

For everything else, Lambda and API Gateway have been fantastic, even without
a framework like Serverless. It's so cheap! It's so convenient! It's so
reliable-enough!

But we couldn't get along on a 100% Lambda backend, far from it.

~~~
dfischer
I agree with this a lot. Especially on the web socket front. I've been
thinking of an ideal structure for this. I haven't decided between elixir or
bet in with Google and Firebase.

~~~
gamache
For what it's worth: we use Firebase in our stack too, but at this point it's
confined to our customer-facing dashboard (as opposed to our end-user-facing
service). I don't like it when my critical systems depend on services out of
my control, especially when those services go down for hours or days at a time
-- as Firebase DB has done twice in the last year, for us.

~~~
dfischer
How are you delivering sockets to end-user facing service? Through phoenix?

~~~
gamache
Yes, we have a pool of Elixir + Phoenix servers behind a classic Amazon
Elastic Load Balancer (set to TCP/SSL mode, not HTTP/HTTPS, or else WebSockets
don't work).

~~~
dfischer
Hmmm cool. How are you deploying Phoenix?

~~~
gamache
Right now we're using Edeliver and Distillery. We're planning to containerize
things soon, so I'm not sure what the toolchain will look like then, but if
you have long-lived servers then Edeliver is great.

------
ZmyWTR
Cool, should be very useful...thanks for posting!

