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.
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.
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...).
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.