←back to thread

202 points Towaway69 | 1 comments | | HN request time: 0.21s | source

Hi There,

Erlang-RED has been my project for the last couple of months and I would love to get some feedback from the HN community.

The idea is to take advantage of Erlangs message passing and low overhead processes to have true concurrency in Node-RED flows. Plus also to bring low-code visual flow-based programming to Erlang.

Show context
oersted ◴[] No.44007812[source]
> Node-RED is a amazing[*] tool for creating flows that describe concurrent processing, it is just a shame the NodeJS is single threaded. So why not use something that is multi-process from the ground up?

That's great! But now that we are doing this, it kind of makes me wish that it was not multi-processing and Erlang, but a more mainstream language with a better library ecosystem and focused on multi-threading instead, Rust comes to mind but there could be a better one.

Is there a visual flow programming language based on Rust that is relatively mature?

replies(6): >>44007924 #>>44007929 #>>44008197 #>>44008520 #>>44008981 #>>44011466 #
1. Towaway69 ◴[] No.44007929[source]
> wish that it was not multi-processing and Erlang

Hehe - honestly I chose Erlang because I love the syntax and secondly because it is so niche. Flow based programming is niche, visual FBP is nicher, Node-RED is even nicher and Erlang is niche - it's niche all the way down ;)

Have a look at Elixir which is Erlang with Ruby syntax and also has a large community.

Also the intention is to be using the flow editor and not the lanuage underneath, so the end user won't even know that it's Erlang or NodeJS - I aim t stay compatible with Node-RED so that flows are actually interchangeable.

So to an certain extent it doesn't matter which language is used.

I did chose Erlang also because it is well suited to flow based programming being message based and flow based programming is all about passing immutable objects amongst independent processes .... that's Erlang in a nutshell.