We discuss what I am actually trying to achieve with Erlang-Red, how does it compare with Node-RED and where can both benefit from each other.
We also touch on Flow Based Programming and its influences and applicability to Node-RED, NodeJS, Erlang and Erlang-Red. Visual test suite for ensuring compatibility between Node-RED and Erlang-Red but also for creating other backends for the Node-RED flow editor.
@gregorius you look very different from how I imagined you. You look cool. Good presentation. Im really rooting for you and that Earlang-RED becomes successfull soon. I wish I were as creative as you and had energy to put my ideas in practice. This year hasnt been good to my mind.
Thank you on both counts - the part about looking cool was only because we had some sunny days here and I was accidentally away from my keyboard getting some of that sun
We all have our own strengths and weakness, take joy in what I do but don't use it as a measure for yourself. I don't do what I do to make others feel bad about themselves.
Build on my ideas if you find them good, be happy: you discovered those ideas now - it took me a much long time to get there than you - after all you're considerable younger than me.
But I won't be doing what I'm doing without others also sharing their ideas, upon which I build. Erlang-Red, as I say in the video, builds on the ten years of experience that Node-RED has - so in fact, its Nick and Dave that gave me the ideas. But they got their inspiration from J. Paul Morrison with his ideas of flow based programming. And he probably got his ideas from someone else again.
Be open for new ideas, consider them and also be able to discard them. Sometimes ideas are discarded but come back to help us - be open to reconsidering previous ideas and decisions. Stay flexible in mind and body. But don't let your ideas dominate you, it's ok to write them down and forget them. If they were important, you'll come back to them.
I think, considering what you have gone through, you're doing good. It will take a while longer but stick through it, it does get better and more rewarding.
I too find it hard sometimes to face up to a new day and I've been throwing in the towel for the last couple of months with Erlang-Red. But something always happens to bring me back to it and I get a new drive to do something. Doing something new carries with it the doubt of being completely wrong but its comments like yours that give me hope to carry on experimenting - and in that way your are helping me very much.
Thank you
I think, having done the video, I've reached a point where I can say it is a success. So I'm happy with what I've achieved and anything more goes above and beyond my expectations.
Just some curiosity about Erlang, just because I am Swedish;)
Is a language written & developed by the Swedish telecom company Ericsson (Ericsson Computer Science Lab) in the 1980's. This is maybe already well-known I suppose
What might not be so well-known is that also the core of the, also Swedish, e-commerce payment system Klarna is written in Erlang by a team of people that had left Ericsson. Major parts still in operation but hard to maintain due to difficulties finding necessary know-how === developers knowing & skilled in Erlang
Erlang is definitely under utilised - it's a great programming language and makes a lot of things very simple. Especially flow based programming (FBP) - message passing and immutable data structures are builtin, so FBP makes total sense in Erlang. Plus lightweight processes for representing nodes.
On the other hand, function signature overloading with parameter matching combined with guards is a skill to be learnt If you get it right, you will never have an if or case in your code base!
Still Erlang-Red is coming along, just in the last couple of days, I created some screencasts on generating and testing state machines in Erlang-Red. That could be a real win for those working with state machines and their definition.
Today I studied a bit about how erlang parallelism works with its vm threads, schedulers, queues, process, and immutability. @gregorius are you making each node run on a separate process????
I just don't like to write code using erlang syntax. Is there a way I can use a function node that let me write js?
If not, what if there was a long running node process, loaded with the code of each "js function node", ready to process the "msg" an erlang process sends? This node process would be started before erlang-red when a flow.json has at least 1 "js function node". There could even exist n node process and a load balancer to distribute requests comming from erlang process when a single process can't handle all the load. This way we could still use js
Yes - Every node, even the junction node, is a separate process. Making flows truly concurrent and fail-safe.
If you're reading up on Erlang, also read up on supervisors - they are responsible for restarting processes. Erlang has the motto "die and die fast" - processes are super lightweight and designed to be restarted quickly, so let it die and a supervisor is responsible for restarting those processes that should be restarted.
I've designed Erlang-Red so that supervisors are represented as nodes, those the user can define which nodes - if they fail - should be restarted.
No
But you're not alone, Elixir is the ruby-like syntax for Erlang (i.e. they both use the same virtual machine). Then there is also Gleam which is also based on the BEAM - the virtual machine behind Erlang. By the looks of it, Gleam would be more JS-like but I'ven't used either Elixir nor Gleam.
Erlang-Red doesn't support Elixir code but there is an argument to be made for an Elixir function node - why not. Just that I don't have any idea how to convert Elixir code to something useful. Although I don't think its that hard ... The same can be said for Gleam.
Start a Node-RED instance and have the Erlang-Red and Node-RED instance communicate via MQTT or some other message bus - would be the same but more structured.
I believe that there are already link nodes that act between instances of Node-RED. These nodes are placed in flows and seemlessly communicate between Node-RED instances using MQTT.
If you think about it, it's super simple to have these nodes act across types of X-REDs installations. Much as I created the assert nodes to work in Erlang-Red and Node-RED, these "linked-over-mqtt" nodes would work on any X-RED instance (X being Node, Erlang, Python and Rust - atm).
Good idea too. But doing your way I can't just execute a flow.json containing js code using Erlang-RED. My proposal ensures that these flows could run in Erlang-RED. If Erlang-RED doesn't natively support using js function nodes, then we will not be able to just copy and paste our flow.json into Erlang-RED.
"Experimental Erlang backend to replace Node-REDs existing NodeJS backend, aiming for 100% compatibility with existing Node-RED flow code."
I was thinking about helping it get closer to 100% compatibility
Sure, this would - at first glance - not allow execution of JS code inside the Erlang-Red and it would require a second flows.json .... however - I've got another idea!
Howabout a "external-js-code" node that takes JS code and - magically - transports that code to a running Node-RED instance to have it executed over there, wrapping the message into a MQTT/Rabbit/Kafka packet? This reminds me of CORBA!
The "external-js-code" node would be completely transparent for the Erlang-Red user, being able to not only do the cooking but also make coffee! Well you know what I mean...
This is not 100% in the sense of scientific, this is 100% in the sense of marketing. I don't really believe I would ever reach 100% scientifically, but for marketing purposes, it's already at 110%!
I think that using a Node-RED process to process the message sent my Erlang-RED using the js code in a flow.json would bring too much overhead (express, rest api, cli, nodes we dont need and a lot more), which would consume more memory and space than just a simpler node process loaded with the functions we need. What do you think? On the other hand, if Erlang-RED could just spawn a new node/bun process, containing only the js functions and nothing more, and use stdin/stdout/stderr to process the message using a given function this issue wouldn't exist, I think. What are your thoughts?
It's marketing. The magic node that can do anything. It's the placeholder node that is like a swiss army knife in the sales brochures but then fails to deliver anything because it never actually gets built. I suggest a job the corporate IT world ... or hang on ... any startup! <<----- to experience the "swiss army knife"-node
Sure but is also more to implement and has more potential for errors than sending a flow.json to a Node-RED instance. Since this is all academic anyway, I would go with a solution that is quick to implement and test rather than a complicate, do-all and best-of-its-class solution that no one will use.
Hence my suggests as an extremely lazy person!
It can, I've fully implemented the exec node in Erlang-Red. So use that to spawn a NodeJS process QED.
I don't think you are lazy. Stop wiking, please. I interpret it as if you were trying to imply I'm lazy. I'm not I just don't have motivation anymore to program due to mental health issues and I'm trying to fix it because I still have love for it. That is why i keep annoying people with my questions
Yes you will, I've also got the template node that has Javascript mode So you can put your code there, save it to a file (the write node also works) and then call nodejs on the file
No don't do this! But it could be done
I was absolutely not referring to you - please don't read that into that statement. The reference is that programmers generally are lazy and that's why they come up with solutions and shortcuts to their problems - because they don't want to repeat themselves. I.e. DRY!
That's the lazy I meant, not the in-front-of-tv-with-bowl-of-chips lazy. And I was definitely not applying anything about you - 100% <--- this is scientific 100%.
Yes, sometimes is better, what I do since years with all my nice dedicated Python services outside of other sw's running, communicating 2-way via MQTT (each Python "thing" obviously runa as a separat process and is supervised "by myself" via software of course)
Kafka, Kubernetes, is that the "modern way" nowadays when building distributed systems? I know for instance Spotify, oh yes another Swedish thing, is using that and is programmed in java
What would the advantages be if NR and ER would use such? Would that be much safer if you for instance wanted to reach your system also from any place outside your "safe zone"?
I think there isn't a answer to what is the advantage of X versus Y. Nowadays it depends a lot on talent and what employees you have.
Java developers might be “cheaper” than others, hence Spotify went with java. Or the first developer was a java developer. Or indeed they analysed 15 different programming languages and decided on java after analysing all possible edge cases of that which they planned to build!
I created Erlang Red because I wanted to better communicate the not only the concepts of Erlang, but more importantly, the concepts of visual flow based programming, in particular to a new audience.
I don't really know why anyone would “want” to use either ER or NR, there are tools for most problems that both tools solve. In fact, there are probably SaaS solutions for said problems.
I see the challenge of a) creating something that folks find inspiring b) that make folks think about programming differently c) have fun with programming again the most fulfilling challenge and not whether Erlang Red can bake coffee while burning the toast.
Btw what I also did was use Node-REDs package management to define them, which means they can be installed in Node-RED --> erlang-red-supervisor-node (node) - Node-RED --> I've only implemented them in Erlang-Red but that demonstrates the potential of cross-pollinating the ecosystems with ideas from both worlds.
The concept of supervisors and behaviours generally are unknown in NodeJS but they are now known in Node-RED. They don't do anything but that's not stopping someone (probably me) from implementing their behaviours in Node-RED and hence NodeJS.
Uniquely only Node-RED is able to do that because it has a layer above the programming language and the respective tooling.
If you get it right, you will never have an if or case in your code base!
