5 ms·

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

by poorman 10y ago

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.

davidw 10y ago
> 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 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.
- poorman 10y ago
  Ah, I see this now: https://github.com/KDr2/erlix#about-the-class-erlixmessage 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.
  - davidw 10y ago
    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.
  - vertex-four 10y ago
    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.
felixgallo 10y ago
or http://bert-rpc.org/ http://bert-rpc.org/ perhaps.
- rad_gruchalski 10y ago
  There's even a ruby lib for that: https://github.com/mojombo/bert https://github.com/mojombo/bert
- elcritch 10y ago
  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 10y ago
    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.
justin66 10y ago
I've got something for this... wait for it... Inter-Bandwagon Communication. IBC for short.
- rozap 10y ago
  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.

by poorman 10y ago

davidw 10y ago

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

poorman 10y ago
Ah, I see this now: https://github.com/KDr2/erlix#about-the-class-erlixmessage 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.
- davidw 10y ago
  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.
- vertex-four 10y ago
  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.

felixgallo 10y ago

or http://bert-rpc.org/ http://bert-rpc.org/ perhaps.

rad_gruchalski 10y ago
There's even a ruby lib for that: https://github.com/mojombo/bert https://github.com/mojombo/bert
elcritch 10y ago
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 10y ago
  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.

justin66 10y ago

I've got something for this... wait for it... Inter-Bandwagon Communication. IBC for short.

rozap 10y ago
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.