Luna is now called Enso and they are starting from scratch: https://medium.com/@enso_org/enso-dev-blog-19th-june-2020-335e528d50b

Not to be confused with another Enso, which seems dead now: http://enso-lang.org/ They seem to share the etymology, though.

For example, the GUI was slow, based on SVGs, and integrated with the Atom editor. It would be difficult, if not impossible, to get the performance we wanted building on that foundation.

This feels like a dodge. You can do wickedly complex stuff with SVG and maintain buttery 60. So I'm thinking this has more to do with their architecture (building on Atom instead of just Electron?) than the underlying tech.

Right, but that's a GPU SVG implementation. If you're making something that looks like Luna/Enso, you can go super fast just by being slightly clever about how you touch the DOM. No need for GPU, vdom, etc. Anyways, this is OT. For Enso, I like the look of their UI for ports around the nodes. Hard to tell from the GIFs on my phone, but it looks like you can't see variable declarations in the graph, just in the text view. That feels like a weakness, but I'm sure they have a plan in mind. Glad to hear they'll be posting regular updates!

In the immortal words of Fred Brooks, "plan to throw one away". However, they must have burned some capital working for the last 2 years on this project. Doing it in Poland instead of SV means probably only 1/3rd the cost, but 5 people at 40k/year for 2 years is an estimated $400K USD. Red/Rebol is to my knowledge the best funded project on the FoC project list, they are concentrating on Crypto smart contract programming as their "home" domain. Enso is now going down a tunnel where their system requires them to build the entire stack including editor, debugger, etc. That means more work and an even bigger project. I have some concerns about projects which don't build programs and projects and then work backwards from a project to figure out the best tool to make that project. Trying to design in a single direction is fraught with peril IMHO. All ladders connect two points in space, and one is typically looking for least complex connection between A and B, so one must go back and forth between A and B to optimize the path. This shuttling approach is very expensive in time and effort, but I think product design always works this way. I just saw the Ford F150 announcement, and they had a team of people going camping with their customers, and visiting jobsites, so that they could add in the features that were wanted and needed. The new F150 announcement underwhelmed people, because it was incremental, but in terms of ergonomics they really moved forward solidly towards a product that was more useful to their customers. They even considered the issue of the controls surfaces being usable by people with gloves on. So the knobs and controls are huge. I am helping a friend who is designing a hearing assistive device that is both hardware and software, and you have to make the controls extra big for seniors. I have always made my controls extra big and occasionally gotten hate mail from young punks who ridiculed the jumbo size. That's one thing i am a bit concerned about in the node and wire visual programming world is that they often expect high acuity in order to distinguish the tiny spatial differences between output #1 and output #2.