Elixir and Ruby can talk to each other using Erlix(blog.fazibear.me)
blog.fazibear.me
Elixir and Ruby can talk to each other using Erlix
https://blog.fazibear.me/elixir-ruby-dont-fight-talk-with-erlix-24b0f5ed8d12
56 comments
or http://bert-rpc.org/ perhaps.
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), 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...).
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), 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...).
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.
There's even a ruby lib for that: https://github.com/mojombo/bert
I've got something for this... wait for it... Inter-Bandwagon Communication. IBC for short.
Hm, not exactly. This is the same model as JInterface, which is built and maintained by Ericcson and has been around for quite a while and targets the JVM. This is nicer than using ports as datatypes "just work". The whole runtime (Ruby or JVM) just appears as an erlang process, which you can send/receive messages to/from.
We use JInterface at work to leverage a bunch of stuff on the JVM that we already built. Integrating it with our Elixir project took less than a day and to be frank there's significantly less fucking around than there would have been had we deployed the JVM functionality as a microservice, and locality is preserved, which is nice.
JInterace (and i'm assuming Erlix because it's the same model) has been a really nice, low friction way to re-use a bunch of code that already works.
We use JInterface at work to leverage a bunch of stuff on the JVM that we already built. Integrating it with our Elixir project took less than a day and to be frank there's significantly less fucking around than there would have been had we deployed the JVM functionality as a microservice, and locality is preserved, which is nice.
JInterace (and i'm assuming Erlix because it's the same model) has been a really nice, low friction way to re-use a bunch of code that already works.
> You're just sending text around.
Unless I'm mistaken, it's using Erlang's distribution protocol, which is not 'just text'.
http://erlang.org/doc/apps/erts/erl_dist_protocol.html
As to whether some other form of sharing data between Ruby and Erlang is more appropriate, I'm sure it depends entirely on the application. At $current_job - 1 we used the Java/Erlang libs to let Android and Erlang talk, and it worked pretty well. We did not need other systems to access the same data, or the additional overhead an extra piece of software would have required.
Unless I'm mistaken, it's using Erlang's distribution protocol, which is not 'just text'.
http://erlang.org/doc/apps/erts/erl_dist_protocol.html
As to whether some other form of sharing data between Ruby and Erlang is more appropriate, I'm sure it depends entirely on the application. At $current_job - 1 we used the Java/Erlang libs to let Android and Erlang talk, and it worked pretty well. We did not need other systems to access the same data, or the additional overhead an extra piece of software would have required.
Ah, I see this now: https://github.com/KDr2/erlix#about-the-class-erlixmessage. So I guess it is handling encoding.
P.S. zeromq doesn't require you to run another system, it's just a lib.
P.S. zeromq doesn't require you to run another system, it's just a lib.
Well, yeah, 'just' an extra lib with its own encoding and decoding. If your system as a whole revolves around Erlang, it's a fine choice for a protocol. Other times, something more 'standard' that lots of disparate pieces can talk to is better. Totally something to be decided by whoever is building it.
While it's just a lib, it does implement an alternative networking system to the one you're using everywhere else in Erlang, which requires different ways of interacting with it and different knowledge of all the fun edge cases.
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.
Yeah, in the most recent Who Is Hiring post, every mention of Elixir also mentioned Ruby somewhere, usually in the context you described.
Most of those postings seem like Ruby shops that have pipe dreams of doing Elixir stuff, some day. I'm skeptical many will get there, which is a shame because Elixir is the most fun I've had writing software.
Anecdata/shameless plug: Appcues is an Elixir shop with no Ruby at all. And we're hiring!
https://news.ycombinator.com/item?id=13080548
https://news.ycombinator.com/item?id=13080548
I liked you more when you were a role model for Ruby snobbery. :( (Said, like, 95% in jest. I think. I think I think?)
But, yeah, I don't often stump for people around here but Pete is good people to work with if you're looking. I would rather have fire ants poured in my pants than do web work, but I'd jump at the opportunity to work with him again and if you're looking, you could do a lot worse.
But, yeah, I don't often stump for people around here but Pete is good people to work with if you're looking. I would rather have fire ants poured in my pants than do web work, but I'd jump at the opportunity to work with him again and if you're looking, you could do a lot worse.
I can only speak to what we do at Bleacher Report, but we were mostly Ruby - now Ruby is mostly legacy apps.
Elixir for the services and Node for the client/frontend is how we're rolling now. I don't think any of the Ruby guys want to go back.
While we're not against Ruby - and as I said, we still use it - at our scale Elixir is much more performant & scales better.
Elixir for the services and Node for the client/frontend is how we're rolling now. I don't think any of the Ruby guys want to go back.
While we're not against Ruby - and as I said, we still use it - at our scale Elixir is much more performant & scales better.
We started in Ruby and have moved to Elixir (not a pipe dream!). If you have an SOA already, adding Elixir isn't a big hurdle. Experienced engineers can pick it up super quickly.
I agree it is incredibly fun! All of the hard work put into BEAM plus the easy-of-use of Ruby and the joys of functional programming make for a wonderful developer experience.
I agree it is incredibly fun! All of the hard work put into BEAM plus the easy-of-use of Ruby and the joys of functional programming make for a wonderful developer experience.
Ya I've actually seen a number a few shops making real moves in that direction, at least here in Vancouver. The OSS ecosystem is obviously pretty immature but I think it's getting good enough that it's starting to seem like a pretty viable option.
Indeed, it seems Elixir is one part complementary to Ruby and the other a great replacement whilst also keeping the main tenets of Ruby in-place.
The only issue so far is that the libraries ecosystem is indeed quite young but that is natural.
Still, Ruby (even without Rails) is at the moment a more productive environment.
I really hope Ruby "3x3" [0] will be released soon enough and projects like Hanami [1] become production ready so that it can coexist in a complementary way rather than becoming replaceable.
[0] - https://blog.heroku.com/ruby-3-by-3
[1] - http://hanamirb.org
The only issue so far is that the libraries ecosystem is indeed quite young but that is natural.
Still, Ruby (even without Rails) is at the moment a more productive environment.
I really hope Ruby "3x3" [0] will be released soon enough and projects like Hanami [1] become production ready so that it can coexist in a complementary way rather than becoming replaceable.
[0] - https://blog.heroku.com/ruby-3-by-3
[1] - http://hanamirb.org
Anecdotal, I know, but I work for one of these companies. Definitely not a pipe dream for us. Most new projects are still in Ruby, but Elixir is now supported company-wide, and there's a number of projects being built in Elixir.
I work at a healthcare company, where our primary language had been Ruby. All of our new development, except 1 off scripts, is in Elixir.
Same here all across the board: healthcare, previously Ruby, everything new is in Elixir.
Awesome to hear. If you're ever interested in chatting about elixir in healthcare, shoot me an email. Mine is in my profile.
How did the migration go if I may ask? Was it progressive or clean slate? i.e. develop in parallel the new Elixir implementation and just switch when everything is green and all the specs match the Ruby app.
It's going well! Most of the team is eager to learn something new. The developer ergonomics in Elixir/Phoenix are quite a bit better than Ruby/Rails, which is really saying something because Ruby/Rails has been really great to us!
We're starting new projects in Elixir. We haven't ported anything from Ruby to Elixir yet, but we have a 9 year old ~100k lines of code (not counting views/tests) Rails app that we could make an argument to extract some functionality from.
We're starting new projects in Elixir. We haven't ported anything from Ruby to Elixir yet, but we have a 9 year old ~100k lines of code (not counting views/tests) Rails app that we could make an argument to extract some functionality from.
For us, we just do new parts and projects in Elixir.
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.
I really like lispness of Ruby and the rails ecosystem. For a lot of things it's still numero uno technology.
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
- 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
Interesting - makes me think of ErRuby:
https://github.com/johnlinvc/erruby
Like JRuby, but s/Java/Erlang.
https://github.com/johnlinvc/erruby
Like JRuby, but s/Java/Erlang.
I wonder what the benefits of this approach is to say, a json driven microservice between elixir and ruby?
Probably faster and more direct and less fiddling around with encoding stuff in JSON. I'm pretty sure both Ruby and Erlang have richer types than JSON.
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.
I hesitate using Erlang/elixir for this than aws lambda + event distribution. Any thoughts?
If you don't need low latency and are ok with the extra architectural overhead... there's nothing wrong with that.
Different use cases
Different use cases
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.
At least to me, as a story.
Well... it's a win for both. It means it's easy to write performant and highly concurrent microservices.
Latency is part of that.
Latency is part of that.
Isn't aws lambda better suited for short running tasks?
What's a long running task?
I think heuristic is running time of about 5 or 10 minutes.
[deleted]
I would like to see a DRB <-> Erlang C Node (but in Ruby) system.
Start Ruby process, get Erlang node.
Start Ruby process, get Erlang node.
Interesting. Any real world application this has been used for?
Is this more or less useful than C bindings in either language?
With aws lambda elixir is less attractive to me. I wonder if anyone has similar thoughts?
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.
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.
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.
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.
How are you delivering sockets to end-user facing service? Through phoenix?
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).
Cool, should be very useful...thanks for posting!
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.