Here is a status of the [[Enso]] engine in 1st Quarter of 2026.


=== The Directive ===

The engine team, just like other teams, has been asked to focus on winning [[Enso]] user hearts, improve adoption of Enso among our users and contribute to increased sales as much as possible. That’s a slightly hard task, given the textual representation of [[Enso]] not being the primary representation typical [[Enso]] target audience interacts with. In spite of that we managed to achieve critical improvements in user visible areas. Selection of the most important follows.

=== The Achievements ===

==== It is Stable! ====

There used to be times when crashes, data loss and various other instabilities of the engine were quite common. Those times are long gone. With stability being the number one item on the engine team radar, we managed to become a rock solid base for the Enso GUI. We’ll continue to address stability issues as soon as they get reported and also pro-actively tackle places where stability might be compromised in the future.

==== It Starts Fast! ====

'''TL;DR''': It is fast enough!

The engine can do one thing: not stay in the way of GUI. The best way to do it is to start fast and wait for GUI to request some actions. After applying intricate ahead of time compilation techniques to the engine code base, the enso.exe process starts fast. It is so fast that nobody even mentions it as being a problem.

'''Cons''': Still there are challenges to address, see Dual JVM section.
Visualizations Now!
When the GUI is connected to the engine/language server process and can submit its requests, it is also important to provide responses as fast as possible. A particularly visible problem was the rendering of visualizations. The whole project had to be computed first before any visualizations got delivered to the GUI.

The engine team tried various approaches to speed it up, but in the end we decided to reorder and inline the visualization requests and process them as soon as appropriate data are ready. It wasn’t easy to get all the pieces right, but Dmitry made it. The user experience has been greatly improved by these changes.

==== Less Recomputations! ====

User reports indicated dissatisfaction with “too broad cache invalidation” when making edits. We got access to a quite complex user project. Running it allowed us to study such misbehavior. After analyzing it Dmitry created an extensive test suite. By adding more and more tests he fixed many of the recomputation problems. We can’t claim all the problems are fixed, but the current nightly version is in far better shape than last year’s release.


==== Infrastructure for Downloading Enso Libraries ====

[[Enso]] vision has always been envisioning a rich ecosystem of sharable libraries that Enso users can exchange among their teams or publicly. Such a vision has however been suppressed when we were trying to get any working version of Enso GUI to customers. However with the growing number of customers, the vision becomes essential again. We decided that the engine team can help with that!

Pavel Marek worked hard on getting the existing, but not used infrastructure for automatic, behind the scene downloading of imported libraries, working again. As a demonstration of the infrastructure working the Standard.Image library is downloaded only when needed in the most recent version.

Pros: We can create a release and expose an unlimited number of non-standard libraries to Enso users at any time - satisfying each customer's unique needs quickly without the need to invest in creating robust and stable APIs that would work for everybody.

Cons: UI for turning projects into sharable libraries and uploading them to the cloud was left out of scope of this task. The downloading infrastructure is however ready when such an UI is created.

==== Reduction of Complexity ====

The other area related to stability is reduction of unnecessary complexity. There are two themes that Dmitry paid a lot of attention to.

Project manager used to be a separate executable. However it turned out that most of its functionality can be performed by the Electron application itself. Dmitry was instrumental in turning that effort to reality. No project manager process is needed anymore.

The other node.js process was running a so-called Ydoc server. By moving the Ydoc server into the enso.exe process itself (e.g. co-locating it with the rest of the engine and language server) we eliminated one unnecessary process and unlocked the door to further achievements. As a continuation of this effort Dmitry managed to eliminate two socket connections by using CRDT data structures for communication between the GUI and the engine instead. Only one web socket is now necessary for (almost) all of the communication.

==== Logging & Progress & Telemetry ====

It is essential to the success of Enso to understand its user needs. The engine team has contributed to such an effort by improving logging! As surprising as it may sound, logging is at the core of improved progress reporting in the GUI as well as telemetry information being delivered to our elastic search database. Thanks to that Dmitry is currently assembling a “top ten” of slowest Enso components - once done we’ll be able to analyze the behavior of engine and standard libraries “in the field”, identify the problematic operations and focus on making them faster. User experience will be constantly monitored and improved in the critical areas!

==== Dual JVM Mode ====

A heroic effort was needed to marry the fast start of the engine (to be attributed to AOT compilation) with the need to dynamically load JVM classes. The effort is being called a dual JVM because there are two Java virtual machines running in the single Enso process communicating effectively with each other.

The essential use-case was driven by the need to exchange columnar data between those two JVMs. We decided to support zero copy exchange of data (mostly) in the Apache Arrow format between those two JVMs. Performance seems to be sufficiently good and the format allows us to integrate with other Arrow-ready systems like Pandas when the time comes.

Pros: similar system was an enterprise only feature called GraalVM Isolates
Cons: the Isolates are being open sourced and further work may be needed to align with them