I know Statebox pretty well :)

Luna not super well, but I did beta test their first release (and some later versions), cool stuff.

Anyway, the two are (feature wise) very similar, as you noted:

- both have textual/visual representations, - are typed FP languages, - access to FFI/effects, - diagram nesting

But Statebox is _not_ data-flow, it's more about "control flow" or "multi-party protocol execution". (You could do data-flow with Statebox, but at the moment that's prohibitively inefficient.)

Where Statebox takes a different direction (I think) is in basing the language on established concepts from category theory and focussing on 'generality/compositionality' ; specifically, our diagrams are not "graphs", but (morphisms in) categories.

This difference is very very subtle, in fact, seems totally irrelevant if you want to visual programming (see the nice codex, clearly it works using graphs!)

but it becomes more important when you want to diagram's to be "universal". at least in principle, the Statebox language should naturally and compositionally translate to any kind of hardware ; we want you to be able to program smart contracts, p2p-systems, JS frontends, digital circuits, heck, maybe even slime molds, all from the same diagram.

Luna certainly has more features at this stage.

(also, our editor is under heavy development and not yet published, we are aiming to release some things around the statebox summit in september)

Maybe it's fair to say: Luna is like a better NodeRED, Statebox is conceptually closer to something like homotopy.io / globular.science ?

Hope this clears things up a bit