Introducing Enso | Build your data workflows in minutes, not weeks.

Hi, I'm Wojciech, one of the founders of Enso (link) :) SEE THE DEMO HERE: ▶ this video What is Enso? Enso is an award-winning interactive programming language with dual visual and textual representations. It is a tool that spans the entire stack, going from high-level visualization and communication to the nitty-gritty of backend services, all in a single language. Enso is also a polyglot language - it lets you import any library from Enso, Java, JavaScript, R, or Python, and use functions, callbacks, and data types without any wrappers. The Enso compiler and the underlying GraalVM JIT compiler, compile them to the same instruction set with a unified memory model. What is this post about? Enso has visual and textual syntax. We have released Enso 2.0 alpha to the public as a free, open-source project over a week ago and we got a lot of questions regarding what is the best way to learn its textual syntax. To address these questions, we have created a dedicated page for it! Check it out here: link If you want to learn more about Enso, check the following links! - our website: link - our GitHub (Enso is Open Source and free to use): link If you have any questions, I'd love to answer them! <3

Luna was our early prototype and it indeed had significant performance problems. Our new JIT compiler is able to execute the graphs really fast (in fact, in many cases we are up to 80x faster than Python nowadays: link). However, sometimes we see that the WebGL is super-slow on some machines. May I ask you for more details, please? The important bits would be whether you experience the slowdown when using the IDE (like dragging, zooming) or when waiting for data to be computed? In both cases, we would be more than thankful for an issue containing machine spec: link . Enso should work for you with the same visual performance as in this video (this was recorded on a few years old MacBook Pro): ▶ this video . If its not this smooth, we need to investigate it, because this is something system / machine specific. There is unfortunately no other way for us to improve and progress from alpha to beta, so we will be very thankful for help here! <3

Hi HN, We are Wojciech and Sylwia, the co-founders of Enso (link). On the tech side, Enso is a visual and textual programming language (you can switch from graph to code and back). On the business side, it's a workflow builder that makes it easy for analysts without a programming background to automate data-driven processes simply by connecting visual components together. Our GUI is like an IDE, but with a graph editor alongside the code. Currently, we’re focused on data analysis—data preparation, blending, and analytics (both in-memory and SQL). You can see a video of how it works here: ▶ this video We used to be called Luna and were lucky to have a few big threads on HN over the years [1][2][3][4][5]. Eventually we went into heads-down mode to make a production version based on customer and user feedback. Since then, we've drastically improved the product. It is still rough around the edges, but works much better now. We have also made a few tutorials (link), and docs (link). We've added many new libraries, so you can do many more things with it now. Oh, and we changed the name to Enso and got accepted to YC! :) The problem we address is that data analysts still waste up to half of their time on repetitive manual work that can be automated [6]. To give one example, a company we're working with hires business users who use Excel to define data quality rules. These get manually translated to SQL, then manually translated to Python. This is not only error prone, it’s so slow that it takes them 90 days to introduce a single new rule. There’s 60 days’ worth of overhead in this process—it’s insane! Years ago I (Wojciech) led the in-house development of visual effects (VFX) tools at a motion picture studio. We made tools like cloud renderers and smoke simulation engines. The artists using these tools did not have any programming background, yet they were designing complex algorithms for forces between particles, light subsurface scattering, things like that. Earlier generations of these tools had hundreds of config options, buttons, etc., for masses of different use cases, but this approach got way too complex and people eventually realized that it falls short when you need to do anything that the vendor did not think of. Nowadays they use node-based software (like the Houdini FX) which lets users draw algorithms as a sequence of data processing steps (these steps are often referred to as “nodes”). Later, when I was working in other industries and encountered the same rats’ nests of complex GUIs for solving data processing problems, I realized that the data analytics/science space was in need of the same breakthrough that we had already gone through in the VFX space. Most visual programming languages / workflow-builders do not scale well because they don't let users express abstractions. Try to build a complex pipeline and you'll end with an unreadable spaghetti of connections—it's like coding a web app in assembler. Enso is different because we allow you to build abstractions to manage the complexity. As a result, you never have more than 10-20 nodes on the stage in Enso (nodes are hierarchical). You can create custom data types, custom components (functions), catch errors, etc. All this works because under the hood, Enso is a real programming language. However, naive implementations of such systems are super slow. Each component may be built of hundreds, sometimes thousands of lower-level ones. The real trick is making these hierarchical components run fast. For that you need a dedicated compiler and a runtime system, and this is a hard technical space. Our system involves a dedicated JIT compiler based on GraalVM. For details, see link In case this is interesting for you, here is our podcast about how the compiler works under the hood: link Enso is in