I understand why the Ruby community has warmed up to Elixir and the Phoenix web-framework, however, I'm curious what the advantage or use-case of having Ruby talk to Elixir in an application is?
The main use case would be if you had a very mature Ruby library without an Erlang/Elixir equivalent. I haven't run into much that I personally need that isn't already available, but there are definitely some gaps that this could help people jump in the short term.
Agreed. Currently working with a host of legacy ruby projects that we're slowly migrating to elixir. We've used hack-arounds to leverage the existing ruby projects up until now. If this library proves to be production-worthy, it'll be a great bridge for addressing some technical debt.
Erlectricity, from what I understand, was used extensively in at least one iteration of github's architecture. It has spent a lot of time in production deployments.
I work at an ISP with some gems that you just cannot find anywhere, in any language. We cannot just replace or rewrite them, some have been around for almost 10 years.
> I understand why the Ruby community has warmed up to Elixir and the Phoenix web-framework?
Could you explain why, at least as it pertains to web development?
As a (former) Common Lisp developer I find Ruby on Rails suffices for the vast majority of needs, and believe its popularity and maturity pays off in productivity gains.
The biggest gap in Rails is websockets. There's just nothing close to ease of use that Phoenix has in that regard. I have not, however, done much with action cable. I don't feel much desire to do so since Phoenix exists.
We have a couple legacy Rails <-> Elixir apps being slow-ported forward (low hanging fruit first). The real winner so far for us has been Exq [1], which is a Sidekiq-compatible job library.
What that means is you can selectively receive jobs in Elixir (e.g. high-perf Phoenix websocket/request handler) and process them in legacy Ruby Sidekiq workers when needed, or vice-versa use Elixir to process jobs whose functions you've ported forward.
If your Rails app is already setup use Sidekiq background jobs, I think this method is much-preferable to these direct communication libraries.
Wow. It's crazy to think erlectricity is still kicking. That was one of my first open source projects, although to be fair mojombo has basically replaced everything I wrote with far better code over the years.
12 comments
[ 2.9 ms ] story [ 38.4 ms ] threadI forked it a while back to add support for maps. I'd recommend you use the fork: https://github.com/hamiltop/erlectricity
https://github.com/poteto/terraform
Could you explain why, at least as it pertains to web development?
As a (former) Common Lisp developer I find Ruby on Rails suffices for the vast majority of needs, and believe its popularity and maturity pays off in productivity gains.
What that means is you can selectively receive jobs in Elixir (e.g. high-perf Phoenix websocket/request handler) and process them in legacy Ruby Sidekiq workers when needed, or vice-versa use Elixir to process jobs whose functions you've ported forward.
If your Rails app is already setup use Sidekiq background jobs, I think this method is much-preferable to these direct communication libraries.
[1] https://github.com/akira/exq