As the creator of Erlang-Red, I've gone one step further and decided to implement the entire backend in Erlang instead of Javascript. That means the function node over at Erlang-Red is actually Erlang code, no Javascript allowed!
Why do this? Because Erlang is far better suited to the concepts of flow based programming but the Node-RED editor is unbeatable! Erlang also has additional concepts (such as Supervisors and State Machines) that aren't available in JS but that are well suited to a visual approach to programming, so I've created nodes to represent those concepts.
I think there is more to gain in porting the visual approach/experience of Node-RED to Python than to add a python node to Node-RED. As pointed out, I can use an exec node for that or even create a wrapper around it to make it simpler (I did also create a ExecWithPipe so that I could pipe msg.payload to a python process to execute the python code I create in Node-RED - for example).
Also since I want to share flow code across Erlang-Red and Node-RED, i.e. the same flows should ideally be executable in both, I've also created a simpler code sharing setup - FlowHub Local.
But these are all things that I like doing, AI got bored of my ideas and won't help me.
If it's useful for you, then publish it to npm. If not, then leave it. If you're not going to maintain it, then leave it.
If you ask, you'll get (NumberOfPeopleWhoRespond + 1) opinions - just publish it!
There is a Rust-RED i.e. a complete implementation of the Node-RED concepts in Rust.
P.S.
oooooo yes:
That's also why I ported the concept to Erlang - it's amazing multi-processing with thousands/millions of processes. This means that each node becomes it's own process and each message (msg) is a true message passed between independent processes. I.e. Instead of using "events", I'm using true messages being passed between processes .... yet the flows look the same!
