Launch HN: Enso (YC S21) – Visual programming and workflow automation tool
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 (https://www.youtube.com/channel/UC4oMK7cL1ElfNR_OhS-YQAw), and docs (https://enso.org/docs/syntax). 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 ne...
54 comments
[ 4.1 ms ] story [ 104 ms ] threadI followed the previous launches as well. I'm curious, what triggered the rebrand? Is there a story to it?
On the other hand, the name "Enso" is not similar to any of the popular languages names, we have a beautiful https://enso.org domain, and also, in Zen, ensō (円相, "circular form") is a circle that is hand-drawn in one or two uninhibited brushstrokes to express a moment when the mind is free to let the body create (source: Wikipedia). This is exactly what we want Enso to be – a creative canvas with two perfectly connected parts – the textual and visual one :)
You can create closures in multiple ways:
1. The simplest and most visual is by using currying! If you create a node (a visual component) and you do not connect all its required inputs, the output of the node is the curried function (function with partially applied arguments). You can then connect it to other expressions, like `map`.
2. Another way is to use expressions on nodes. You can use the lambda syntax, like `x -> x.noise` to define a lambda. You can also make it shorter by using curried operator sections `(. noise)`, and even shorter by using the Enso's operator precedence as `.noise` and use it for example as `map .noise`.
If you want to learn more about Enso syntax, we have a page describing it here: https://enso.org/docs/syntax . Also, if you go to our language-focused subpage, please check out the video named "Higher order functions". It does not show currying, but it shows the usage of the expressions on the nodes: https://enso.org/language
Did I answer your question? :)
The same is applied to our data-flow errors. Think of them like about Haskell's `Either` or Rust's `Result` types, but with automatic lifting (automatic applicative functor lifting). So in Enso, you can have a "broken value", like a string read from a file that could be broken because the file did not exist, but you can still concatenate it with other string WITHOUT using any special syntax, and the result may also be broken. In Rust and Haskell you can do the same, but with a special syntax like `(+) <$> str1 <+> str2`.
I hope it clarifies some things under the hood! :)
I was a huge fan of the Enso program launcher made by Humanized back in the day. Aza Raskin I think it was. I got so excited when I saw this said Enso, but alas..
For someone that has done a couple of Show HNs [1][2] I would assume you know better.
People plan for their submissions and look forward to reading the comments. You can and should do better.
[1] https://news.ycombinator.com/item?id=10799830 [2] https://news.ycombinator.com/item?id=9840990
Enso is cloud ready! It has two parts – web-based UI + server-side compiler / data crunching engine. The version you are able to download from our website just contains both parts glued in a single application. We will be releasing Enso Cloud (hosted version) soon! However, it is very important for us to have the desktop version as well, so everyone can just use it for free :)
I hope it makes sense to you? :)
I did run into some issues with running it in Windows. If I have time this week, I’ll will try to post the issue on GitHub
I'm really sorry to hear that you had issues with running it! In case you do not have enough time to report the issue, just make a screenshot and post it on our chat (https://discord.gg/enso). We will then create the issue for you and we will let you know as soon as it will be resolved. We might also ask you for some additional info, but we'll try not to take too much time of yours! It is very important to us to fix all the issues for the upcoming stable release :)
* Scrolling the preview would often pan the entire window
* Panning the window was really sluggish
* It was really hard to drag lines, it felt like I had to be pixel perfect--I've been such a big fan of the idea of visual editor, but I really started to see what this user was talking about with wrist issues [0]
* It was really hard to modify a block of code, I tried mouse click + every different modifier I could think of, it felt random what allowed me to edit text, and then it kept "exiting" the text edit mode.
* Modifying a block of code felt like it was lacking a lot of text editing that a modern editor like IntelliJ or VS Code has.
* The auto complete had something weird going on, I don't exactly remember, but I think one problem was I couldn't use my mouse to scroll the list
* Small things surprised me, like how much white space mattered, like if I had an "<operator> .map", it wouldn't work, and I had to edit it to be "<operator>.map", which makes sense--but it was sooooooo hard to remove that space, because the editor kept exiting text editor mode by small user input mistakes
I kept thinking it was just a learning curve, so I really tried to not let little things get to me, and read the docs, but in the end I just gave up. It was just too hard.
[0] https://news.ycombinator.com/item?id=27706356
1. Some of your points surprised me a lot, including "Scrolling the preview would often pan the entire window", "Panning the window was really sluggish", and "It was really hard to drag lines" – these should not happen. We are heavily testing Enso on macOS and these issues are not known. I know I'm asking for a lot, but would you be so nice and have a 15 mins call with me so I could see how Enso behaves on your end?
2. Some of these points did not surprise me – our text editor is really broken right now and this is one of the things we are improving for the next release. That's why we normally do not even tell people how to open it! However, if you had any issues with editing expressions on nodes (cmd + left mouse button), I'd love to know more about that as well.
Tried out Luna, back when it was first announced and had horrible performance problems with it back then. Decided to give it a second try now, as I still think there is place for a tool like it, but it's sad to see that it's still plagued with the same performance problems (even though I upgraded machines in the meantime).
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: https://github.com/enso-org/enso/issues .
Enso should work for you with the same visual performance as in this video (this was recorded on a few years old MacBook Pro): https://youtu.be/fQvWMoOjmQk . 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
It's good to see the idea taking more and more shape. I think the combination of a text-based and visual language is the only viable path to general-purpose visual programming.
This is a vision worth pursuing.
Certainly. I was struck by it a few years back, around the same time as Luna was in early alpha stage. In fact I found it while doing research for my thesis, based on this vision. I was naive enough to think I had an original idea when I started.
> Visual languages are amazing for some applications, however, text-based development is superior in many cases, like low-level algorithm development, API connections, compatibility with version control systems (GIT),
And the only sensible way around these problems is to integrate both. Just this idea addresses most of the relevant criticisms of visual programming languages. A list of these I compiled at the time was:
• There is a barrier of entry for programmers used to text-based languages. • Essential programming tools are unavailable or cannot be applied: version control, side-by-side (or diff) comparison, change tracking, testing frameworks, build systems. • Visual primitives take up significantly more space than text. • Existing tools are of low quality. • Performance is overall slow. • There are no extensibility mechanisms. • The target group seems to be novice users. • There is no universal visual representation. • VPLs create closed ecosystems.
You might be about to tackle these pretty well. ;)
> I am really happy that we were able to overcome all design problems and make these two representations 100% compatible. TBH, when we were starting Enso, we were not aware how many corner cases and tricky technical details we would need to solve in order to bring it to the world!
I bet. Especially at the level of integration that you're aiming for. My own humble prototype was as simple as I could come up with and already revealed some major issues that a real-world implementation would have to grapple with.
Would you say performance was one of the tricky bits? What was the most tricky?
That's quite a story! I don't know what you do now in your life, but sharing the same vision is absolutely crucial for our team and if you are up to talk about collaboration, I'd love to chat with you! If so, ping me at wojciech.danilo@enso.org! <3
> And the only sensible way around these problems is to integrate both. Just this idea addresses most of the relevant criticisms of visual programming languages. A list of these I compiled at the time was [...] You might be about to tackle these pretty well. ;)
100% this! This is what I was trying to express in one of the parts of our blurb text of this post. Most visual languages are ... not really languages. They lack abstraction mechanisms and love. A love that is needed to make a production-ready tool. Textual languages are working really well because we put a great amount of love in developing them. We have seen a lot of visual languages solving domain specific problems much better than textual ones – Sidefx Houdini for example. And we believe that with much more dose of love, we are able to apply visual programming everywhere where people are processing data that can be visualized and where interactivity of the creation process matters :)
> I bet. Especially at the level of integration that you're aiming for. My own humble prototype was as simple as I could come up with and already revealed some major issues that a real-world implementation would have to grapple with.
I believe that anyone who tried implementing something similar would totally understand it! This is also one of the reasons the criticism appears. It is hard to develop a robust programming language. I believe that developing visual one is even harder than textual one, as you have this additional graphical UX element, that is not as heavily researched as the textual layer we all know.
> Would you say performance was one of the tricky bits? What was the most tricky?
A lot, lot of things! Including:
- Performance (obviously).
- The way errors and exceptions should propagate (you want to have exceptions in low-level text API, but they do not make sense in the graphical layer). We have special conversion mechanism that allow you to convert exceptions to dataflow errors now.
- The language mechanisms. Algebraic data types, type-theory. For example, Enso has a notion of Atoms – similar to ADTs constructors, but each one being a separate type. Also, Atoms can be shared between types. What's interesting, Enso type system does not have subtyping. Instead, we think about our types like about set of values. So for example, it is correct to write in Enso `1 : 1 : 1 | 2 : Natural : Number : Any` (read `:` as "left side is contained in the set defined by the right side). We designed a lot of stuff around this custom type system in order to make the language extensible, easy to use, and play nicely with foreign typed and untyped languages.
- Memory management. If you want to have a robust visual environment, non-connected nodes cannot influence each other. So Enso structures are immutable. How to make that efficient was very tricky.
- Currying, good support for recursion was tricky as hell. We always wanted Enso to be both powerful and easy to use. Nodes that do not have all connections plugged in are curried functions – which gives you so much power in a very natural fashion. However, in order to make that JIT well in a dynamicaly typed land, is tricky as hell.
- Proper recursion handling. This requires segmented stacks and a lot of low-level utilities you'd not normally get on JVM / GraalVM.
- Visual layer – in order to create really high performance GUI we settled down on implementing our custom WebGL vector shapes rendering system based on Signed Distance Functions rasterization (<...
I remember Luna previously having rendering perf issues using a canvas element. How is the perf with Enso?
Small thing, I noticed this typo:
> the ease with which you can ready and write code
On: https://enso.org/docs/syntax
You are absolutely right! Luna was our prototype with several issues – slow GUI, low compiler performance, and lack of extensibility. That's why we went into heads-down mode for almost 2 years to make a production version based on customer and user feedback. As a result:
1. Rendering Performance. We have created a custom WebGL-based vector shapes renderer which is really fast (we have tests of rendering over a million of points at 60 FPS on my MacBook): https://github.com/enso-org/ide/tree/develop/src/rust/ensogl
2. Computing Performance. We have rewritten the compiler from scratch. We used the GraalVM / Truffle framework under the hood as our core JIT framework, and we have added tons of custom optimizations on top of it (e.g. to efficiently support immutable memory, currying, etc). As the result, Enso is right now up to 80x faster than Python (benchmarks: https://github.com/enso-org/benchmarks).
3. Extensiblity. The new Enso is a fully polyglot language – it allows you to literally copy-and-paste code in Java, JavaScript, R, and Python (soon also Ruby, Scala, Kotlin, Rust, and C) directly into Enso nodes without the need to write any wrappers and with a close-to-zero performance overhead. You can even create closures in the visual environment and pass them as arguments to functions in e.g. JavaScript, which will call them with objects created in JS, which will be understood by the Enso nodes! See our videos and compiler section here to learn more: https://enso.org/language
Did I answer your questions? :)
--- EDIT ---
Thanks for catching the typo! Fixed :)
- On the signup screen I accidentally clicked 'sign in with google' then reailzed I didn't want to, and I don't think there's a way to go back to the first screen (without restarting the app)
- When I go to Help -> Documentation in the mac native menu bar I get a link to electronjs documentation, not Enso docs
- The button in the top right that looks like a power button was a bit confusing. I didn't understand what it did immediately and there's no tooltip to explain it.
- I noticed a bug where if I hit the spacebar multiple times quickly to toggle the result view the entire canvas goes blank, then comes back if I hit the spacebar again
- I found it a little confusing that the args of a node are displayed as a var name even when the exact input is known. For example I had the constant `6` as an input to a function `n.up_to` which rendered as `number1.up_to` when I expected to see `6.up_to`.
- I didn't find it intuitive that you cant (I think) edit existing nodes. Do you have to create new ones from scratch, or copy/paste somehow?
> On the signup screen I accidentally clicked 'sign in with google' then reailzed I didn't want to, and I don't think there's a way to go back to the first screen (without restarting the app)
Noted! Will be fixed :)
> When I go to Help -> Documentation in the mac native menu bar I get a link to electronjs documentation, not Enso docs
Oh, I was not aware that it is there! We will remove it. Thanks for catching it! :)
> The button in the top right that looks like a power button was a bit confusing. I didn't understand what it did immediately and there's no tooltip to explain it.
One of the things that we are improving now is adding hover-labels for buttons with explanation of what they do. We also want to make the UX much more approachable by new users. It will take us some time (a few weeks, as it's planned after fixing stability issues), but it's already on our short-term plan to be added!
> I noticed a bug where if I hit the spacebar multiple times quickly to toggle the result view the entire canvas goes blank, then comes back if I hit the spacebar again
I cannot reproduce it. Would you be so nice and create an issue report with a short screen recording and your machine spec here, please? https://github.com/enso-org/enso/issues
> I found it a little confusing that the args of a node are displayed as a var name even when the exact input is known. For example I had the constant `6` as an input to a function `n.up_to` which rendered as `number1.up_to` when I expected to see `6.up_to`.
This is one of the things we are currently working on! This will be much improved in one of the following minor releases (we will do a release every week now).
> I didn't find it intuitive that you cant (I think) edit existing nodes. Do you have to create new ones from scratch, or copy/paste somehow?
You can do it. We use double-clicking to ENTER the collapsed nodes. To edit the node use `CMD + Left Mouse Button` on the expression (or `ctrl` if you are not Windows or Linux). The full list of shortcuts is here: https://github.com/enso-org/ide/blob/develop/docs/product/sh...
We want to add an icon for that as well, so it will be easily discoverable in the future.
I'm really happy that most of these points cover with our dev plans! It means that in a few weeks you'll have a much better experience <3
https://github.com/enso-lang/enso
Anyway, I would really love to chat more with you about these cases if you'd like too! We are looking forward to work with companies in this space and we are providing them with a very special deals now, including lifetime discounts, dedicated team members building highly tailored libraries, and helping solving data-related problems! If that sounds interesting to you, please write to me a short message at wojciech.danilo@enso.org ! :)
1. Dedicated Enso Expert. We will assign you with a dedicated Enso Expert from our side who will be responsible to help you build your use case and guide you step by step in case you have any problems.
2. Priority Bug Fixing. Enso is currently in alpha stage, so it contains bugs and is rough around the edges. We are working really hard on improving it, but bugs will occur. In case any bug will prevent you from progressing, we will focus on resolving it ASAP. It would normally mean, that you should expect fixing it in hours / days after reporting it!
3. Project Delivery Guidance. We want to guide you how to get your project on track and how to progress trough all of its stages, from the initial planning, trough prototyping, till releasing the working version. Based on our experience, it is best if you will have design / progress calls with the assigned Enso Expert once a week. Normally, 30 minutes call should be more than enough to be sure that everything goes according to the plan.
4. Extended Support. We know how important it is to get help when you are building things. We will try to reply to your questions in max 1 hour after you ask them. Of course, we are not able to cover all timezones right now, but we will do our best, especially in the range of 8 am - midnight CET.
5. Enso stuff. We would love to share with you how we appreciate that you are building things on Enso. We would love to send you some cool Enso stuff (like t-shirts, stickers, hoodies).
1. Enso compiler bases on GraalVM which is 400Mb (packed)[1].
2. The package contains GraalVM implementations of Python[2], R[3], and JavaScript[4] compilers, which weight 150Mb, 70Mb, and 50Mb respectivelly.
3. The package contains OpenCV library, as Enso has built-in bindings for it, which is 200Mb.
4. The rest (approx 200Mb) are core Enso libraries and tooling.
We will be able to cut it down in the future as soon as we release Enso Marketplace which would allow you to install these things on-demand.
[1] https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm...
[2] https://github.com/oracle/graalpython
[3] https://github.com/oracle/fastr/releases/tag/vm-21.1.0
[4] https://github.com/oracle/graaljs
PS: I was in awe of Bret Victor's ideas when I got to know about Luna in 2016. I research such unique projects and create my own https://animationcpu.herokuapp.com/ since 2012 But it turned out to be difficult to find the right people, maybe we can cooperate to make the world a better place for developers and arrive the next Unicorn to the planet :)
Regarding collaboration, absolutely! Unicorns are born only from group effort :) Join our Discord at https://discord.gg/enso and let's have a chat!
Congrats on the launch. Very happy to see an European startup that is mission-driven. Quite refreshing. Best of luck in making it. I am in data science so my views come from that perspective. Could be that I am a bit jaded that I am automated away ;)
Here is my feedback from harshest to less harsh. You buy people in the first 30 seconds. I was bought on the idea but the implementation is not good at all.
1. The IDE is completely useless on Linux with Ryzen 4700U, 16 Gigs of RAM and no GPU. Super laggy. Text input does not work and Ctrl+V does nothing when I tried to paste a link to the iris CSV file. Very bad first impression, and that one is the most important. This was latest appimage downloaded from GitHub. Maybe it is the issue with AppImages. Not sure. If you provide an AUR package sometime in the future I might revisit and test again.
2. Speaking of first impressions, the initial empty pane is a bit scary and having links to help/docs, some template projects etc would also make for a better first impression as emptiness is not pleasant. Some keyboard shortcuts cheat sheet like GNOME Apps have would be very useful as well.
3. Why no support for Julia language given that Data Science is your main focus? Does anyone in Data Science use Kotlin or you are targeting because it is low hanging fruit for the JVM along with Scala? Are you also targeting android development as a goal? Unclear from the website.
4. Why would anyone non-technical use this tool over RapidMiner which feels much more user friendly with Drag-Drop widgets (does Enso have a "widget" library pane or only the autocompletions?). RapidMiner also has nicer notion of data sources than the pop-up menu. Actually why would anyone happy with Excel (and shudders VBA) move away to Enso? The tool sounds cool but business people doing Excel are not cool but super conservative and sloooooow. I hope you shake things up there at least a bit. VBA needs to die.
5. Conversely why would anyone technical use Enso over jupyter notebooks and ipywidgets or bokeh? It feels like an overkill for simple tasks where notebooks shine.
I know a few folks have been doing that, and arguing quite convincingly for its benefits for DS, e.g. Thomas Nield in this talk:
https://www.youtube.com/watch?v=J8GYPG6pt5w
(There are more similar talks on the tube)
> The IDE is completely useless on Linux with Ryzen 4700U, 16 Gigs of RAM and no GPU. Super laggy. Text input does not work and Ctrl+V does nothing when I tried to paste a link to the iris CSV file.
Would you be so nice and create an issue report with a short description and your machine spec here, please? https://github.com/enso-org/enso/issues
> Speaking of first impressions, the initial empty pane is a bit scary
We are currently working on making Enso much more user friendly - adding icons and better guidance.
> Why no support for Julia language given that Data Science is your main focus?
First languages we target are Python and R - those are most natural for Data Science. We can definitely think about Julia in the future. We are not targeting android development as a goal. Thank you for pointing out that it is unclear.
> Why would anyone non-technical use this tool over RapidMiner which feels much more user friendly with Drag-Drop widgets (does Enso have a "widget" library pane or only the autocompletions?).
As I wrote above, making Enso more user friendly, with icons for every action etc. is our main effort right now. The goal to improve user experience with every weekly release. Enso however, is much more extensible than ie. RapidMiner. If there is a need to add a custom blocks and share them with others in your company - we are working on making it instant and possible without any engagement from technical team.
> Conversely why would anyone technical use Enso over jupyter notebooks and ipywidgets or bokeh?
If it is a single person or a technical team, who doesn't have to explain the process to the business users or non-technical domain experts they might be happy with notebooks. Having visual representation is helpful for bigger workflows, that have to be easy to understand by non-technical user. However, interactivity while working with Enso is adding a value here as well. You can observe changes in your visualisations when data have changed, without refreshing, in real time. This is making testing ideas faster and more effective.
Have you tried running it under the host Windows itself rather than via the Linux app in WSL?