←back to thread

Show HN: Visual flow-based programming for Erlang, inspired by Node-RED

(github.com)
204 points Towaway69 | 1 comments | 16 May 25 14:54 UTC | HN request time: 0.208s | 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 ◴[16 May 25 17:17 UTC] 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 #
notpushkin ◴[16 May 25 17:59 UTC] No.44008197[source]▶
Note that this uses (I hope!) Erlang processes, which are not to be confused with OS processes.
replies(2): >>44008237 #>>44008362 #
macintux ◴[16 May 25 18:17 UTC] No.44008362[source]▶
Yep. I researched JVM and .NET thread sizes once, to compare/contrast with Erlang processes, and the difference is ludicrous.

Erlang: ~1k

64-bit .NET thread: 4MB

replies(3): >>44008595 #>>44009037 #>>44009315 #
1. neonsunset ◴[16 May 25 20:04 UTC] No.44009315[source]▶
The unit of comparison with BEAM processes are .NET tasks. The results are much less favorable to Erlang or Elixir in that case

https://gist.github.com/neon-sunset/8fcc31d6853ebcde3b45dc7a...