Although I don’t have nearly as many robotic devices as @rolly, I’m in violent agreement with this point. So, here’s a modest proposal…
Centralize and extend CMP I/O
Basically, make sure that all CMP I/O in the current (Python) Monty implementation goes through centralized, distributable APIs. This should allow selectable channels (with a default of :local). If desired, this could also provide traffic monitoring, filtering, etc.
For :remote channels (e.g., cross-node, cross-platform), use clean, open, and well understood messaging approaches such as Elixir’s send and pattern-matching facilities.
Implement and test a proof of concept version that can operate within normal Python constraints. Work with other language communities to provide and track multi-node test suites.
Resources
The most relevant options that ChatGPT suggests are:
There are a few ways to interface Python with the BEAM (Erlang Virtual Machine), depending on the level of integration and performance needs:
1. Pyrlang
- Description: A pure Python Erlang node implementation that allows Python programs to communicate with Erlang/Elixir nodes via the Erlang distribution protocol.
- Use Case: If you need to run Python as a node in an Erlang/Elixir distributed system.
- GitHub: GitHub - Pyrlang/Pyrlang: Erlang node implemented in Python 3.5+ (Asyncio-based)
2. Term (erlang-term)
- Description: A Python library for encoding and decoding Erlang External Term Format.
- Use Case: If you need to serialize/deserialize Erlang terms for communication.
- GitHub: https://github.com/hdima/python-erlang-term
3. erlport
- Description: A simple Erlang port protocol implementation that allows communication between Erlang/Elixir and Python via standard I/O.
- Use Case: If you want to call Python functions from Erlang/Elixir or vice versa with minimal setup.
- GitHub: GitHub - hdima/erlport: ErlPort - connect Erlang to other languages
It also mentions GRiSP, Luerl, NIFs & Ports, gRPC, ZeroMQ, and Message Bus. It suggests this approach:
For your POC multi-node message fabric, you’ll want a solution that allows seamless communication between Python (on Mac) and BEAM-based nodes (Elixir, Phoenix, Nerves, Linux). Here are some possible approaches:
1. Erlang Distribution with Pyrlang
- Pros: Allows Python to act as a full Erlang node, speaking the native BEAM distribution protocol.
- Cons: Requires Pyrlang setup, which may have performance limitations compared to native BEAM nodes.
- Best Use Case: If deep integration with Erlang/Elixir’s native messaging is needed.
2. Erlport for Lightweight Communication
- Pros: Simple way to call Python from Elixir (or vice versa) using Erlang ports.
- Cons: Communication is via standard I/O, so it’s slower than direct message passing.
- Best Use Case: If the Python nodes mainly need to process occasional requests from BEAM nodes.
3. Distributed Messaging with MQTT or ZeroMQ
- Pros: Protocol-agnostic, widely supported across Python, Elixir, and Linux.
- Cons: Lacks the tight integration of BEAM’s native messaging.
- Best Use Case: If a generic, scalable message bus is preferred.
4. gRPC for Cross-Language Communication
- Pros: Well-supported in Python and Elixir, fast binary serialization (Protocol Buffers).
- Cons: Requires defining a schema, not as seamless as BEAM-native messaging.
- Best Use Case: If structured API-style communication is preferred.
5. Message Bus (RabbitMQ, NATS, Kafka, etc.)
- Pros: Scales well, robust messaging, already widely used in robotics applications.
- Cons: More infrastructure overhead than direct BEAM messaging.
- Best Use Case: If event-driven or pub/sub architecture is needed.
Recommendation for the Hackathon
For quick multi-language interoperability, I’d suggest using MQTT or ZeroMQ as a lightweight message fabric. If you need BEAM-native messaging, Pyrlang is a good choice for Python nodes. …
And a pony…