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

Original Article ↗ Hacker News Discussion ↗

Project reception & documentation

  • Many commenters find the idea of an Erlang backend for a Node-RED–style visual environment compelling, especially for IoT, concurrent systems, and as an educational tool.
  • Repeated requests to:
    • Move screenshots and examples to the top of the README.
    • Link to a live demo early.
    • Clearly define “flow”, “flow-based programming”, and other terms, possibly via a small glossary and links to existing Node-RED/FBP docs.
    • Add real-world examples, videos, and a non-technical explanation of what the tool does and who it’s for (Erlang/Elixir devs vs non-programmers).

Flow-based and visual programming: benefits and pain points

  • Visual flow-based programming is seen as productive and conceptually attractive, especially for wiring event/data pipelines and concurrent processing.
  • Major drawback: tooling for collaboration and version control.
    • JSON representations mix visual state (coordinates, labels) with logical behavior, making diffs noisy and hard to interpret.
    • Some argue you must compare flows visually; others suggest separating visual vs logical data in the format.
  • Scaling issues: large flows are hard to navigate on limited screen real estate; modularity via subflows and reusable components is essential.
  • Visual environments expose poor modularity more clearly than text-based code, which is viewed as both a feature and a criticism.

Erlang vs Node.js and alternative backends

  • Author chose Erlang because:
    • It maps naturally to FBP via message passing, lightweight processes, and concurrency.
    • It’s intentionally “niche”, and the language is mostly hidden from end users if flows remain compatible with Node-RED.
  • Some wish for a Rust/Go/JVM-based or Python-based equivalent with a larger library ecosystem and more familiar tooling.
  • Debate on concurrency models:
    • Pro-Erlang side emphasizes millions of lightweight processes, strong isolation, and suitability for many concurrent, small messages.
    • Critics note overhead for heavy compute or large-data workloads where shared-heap multithreading can be more performant.

Node-RED ecosystem and long-term stability

  • Core Node-RED is praised as stable and backward compatible; flows.json is simple and robust.
  • Serious concerns about plugin/module ecosystems:
    • Many community nodes are broken or unmaintained due to npm churn.
    • This “bitrot” is seen as a structural problem for JS-based, plugin-heavy orchestrators.

Licensing and “Don’t Do Evil” clause

  • The custom “DON’T DO EVIL” license is intended as moral messaging and a barrier to effortless big-tech productization.
  • Several commenters warn:
    • Nonstandard licenses are legally risky, require costly review, and sharply reduce adoption and contributions.
    • “Philosophical” clauses likely have no real-world ethical impact but do have practical downsides.
  • Others are sympathetic to using a license as a symbolic pushback against large corporate exploitation, even if formally unenforceable.