I’m hoping you guys can give me some general advice and perhaps code examples if you’re feeling up to it.
I’m very interested in Elixir, but we use Python at my place of work. I want to make an architecture of microservices, and I’d like to use the actor model more since I see it as a generalizable pattern that can compute across clusters of machines (a trend I see continuing). For both of these reasons Elixir has my attention, but I don’t think it would be right to try to convert everyone over to it at my work.
So I really have 2 questions. Firstly, is it worth trying to get Elixir to communicate with Python? And secondly, if so, how is it best done? What is the best pattern for achieving two-way communication across languages?
For instance, my thought is to use Elixir to make the microservices infrastructure and use it to initiate processes and projects written in Python.
Would it be better to simply use rx or some other semi-concurrent actor-model-like libraries in Python to approximate the kinds of computational structures across nodes that Elixir is made for?
Using a BEAM/Erlang/Elixir Port is how you’d communicate, and you can use whatever API style you want, but if you want it as ‘native’ as possible then something like the erlport library for python makes it as ‘native’ as possible to the BEAM (it treats a python system like just another module). In some cases other format can be faster though, it all depends on the data you are transferring.
Thanks! I won’t need to squeeze every ounce of speed out of the connection (I’m just building this for internal system, not external production), so I think erlport should be fast enough. I’ll play around with it.
Do note that although erlport is nice to work in (and quite fast), it does require make to build, so it’s not very windows friendly, nor ‘friendly’ in the traditional mix.exs dependency way either, but it’s still not hard to set up. If you need help just ask.
Calling python/other_language code from Elixir could be more hassle than its worth, as it could complicate development and deployment (environment setup, packaging etc.)
So if you’re already using a service oriented architecture, I’d think about simply exposing functionality of your python services through eg HTTP or RabbitMq and consuming that from all-Elixir apps.
That could give you a nice separation and the confidence to introduce an unfamiliar language to your workplace (in an non threatening way to other devs too) and get a feel for it on something small/contained before deciding about full-on investment.
The main differences between erlport and Pyrlang are (as far as I can tell):
Pyrlang is being actively developed while erlport is on “life-support”, the original developer hasn’t interacted with the project in more than 2 years
erlport (as the name says) implements the port interface, so you launch a Python process from Erlang and interact with it roughly like you would with an Erlang process, internally by talking with it over stdin/out
Pyrlang implements a full node in Python (you have to start the Python process separately and interact with it using Erlang’s distribution mechanism
erlport uses a pure-python ETF serialisation while Pyrlang uses a Rust implementation that is very likely to be a lot faster
erlport is not async, to interact with Python you will always call a function
We have been using erlport for quite a while now in production. It works in general but the installation is a bit more hassle than it should be as it requires the (manual) installation of the erlport Python part.
I like the fact that you can start up erlport as a simple sub-process, though it shouldn’t be too hard to either add this functionality to Pyrlang (the port protocol is really simple and very close to how nodes talk to each other) or to start a Pyrlang node on demand from Erlang and just supervise the process as such.