Pulsar: A New-Generation Smalltalk IDE Unveiled at ESUG 2026

The Smalltalk community is brewing a toolchain-level update. At ESUG 2026 (the annual European Smalltalk User Group conference), a new-generation Smalltalk integrated development environment called Pulsar made its first public appearance and sparked discussion in technical communities such as Hacker News.

Why Smalltalk Needs Another New IDE

For most developers, Smalltalk is a language that "lives in the past": it gave birth to MVC, the refactoring browser, just-in-time compilation, and other concepts now widely inherited, but the pace of updates to its mainstream toolchain has long been slow. Existing Smalltalk environments (such as Pharo, Squeak, VisualWorks, and GNU Smalltalk) each have loyal users and their own historical baggage.

This backdrop is precisely the opportunity for a new IDE. Smalltalk's core experience—object persistence in an image, a running system that can be modified at any time, and browser-centric code exploration—is in natural tension with the engineering assumptions of modern IDEs (file systems, Git, package managers, language servers). Pulsar's appearance at ESUG 2026 suggests that some in the community believe this tension is worth addressing anew with a new architecture, rather than continuing to patch existing environments.

On Smalltalk's "Image" and "Object Persistence"

To understand the tension Pulsar faces, one must first understand Smalltalk's image model. In traditional Smalltalk, a program is not a set of source files stored in a file system; rather, the entire running object graph is serialized and saved as a binary file—the image. When a developer opens the environment, what is restored is not "source code" but the living system from the last exit: all objects, methods, and open tool windows are in place. This means code modifications act directly on running objects, rather than writing files first and then compiling and loading them. This approach brings extremely strong continuity and immediate feedback, but it also makes modern engineering practices such as version control, multi-person collaboration, and build/release difficult to apply directly, because Git faces text files rather than an object graph. If Pulsar is to be compatible with the existing ecosystem, it must preserve image semantics while designing a bridge for the file system and external toolchains—one of the core challenges for any new-generation Smalltalk IDE.

On the Conflict Between the Language Server Protocol (LSP) and Dynamic Languages

The modern editor ecosystem is largely built around the Language Server Protocol (LSP): editors request completion, navigation, diagnostics, and other information from language servers through a standard protocol, thereby achieving "implement once, reuse across editors." But LSP assumes static text files and a codebase that can be analyzed offline, which directly conflicts with Smalltalk's model in which "code exists only in a live object graph." For Pulsar, whether to build a dedicated IDE deeply bound to the image or to try projecting image contents into a form LSP can understand in order to connect to external editors such as VS Code is a key architectural fork. The former preserves the Smalltalk experience but keeps the ecosystem closed; the latter expands the user base but may sacrifice dynamism—the Hacker News discussion about "whether it truly understands image semantics" is essentially asking about this trade-off.

Pulsar's Positioning as Seen from the Conference

ESUG is the most important annual gathering of the Smalltalk ecosystem and has historically been the occasion for new projects, libraries, and tools to be shown to the public for the first time. Pulsar's choice to launch here means its target audience is first and foremost existing Smalltalk developers, rather than attempting to attract outside users with the posture of a "new language."

The demonstrations and discussions at the conference focused on the IDE itself: how fundamental interactions such as editing, navigation, debugging, and code browsing have been redesigned. For developers accustomed to Pharo or Squeak workflows, the bar for evaluating a new environment is not how long its feature list is, but whether it preserves Smalltalk's continuity of "the system as an object graph" while filling in the gaps in the modern development experience.

What the Technical Community Is Paying Attention To

In the related Hacker News discussion, the points of interest can roughly be grouped into several categories. One is the expectations of longtime Smalltalk users for toolchain updates: they care whether the new IDE truly understands image semantics, rather than treating Smalltalk as an ordinary language wrapped in a generic editor shell. Another comes from outside developers interested in dynamic language toolchains, who care more about architectural choices—whether to reuse an existing VM or start a separate runtime.

These discussions themselves also reflect the long-standing difficulties of Smalltalk tool development: any new IDE must simultaneously answer "how to be compatible with the existing ecosystem" and "how to provide sufficiently different value," or it risks becoming just another editor with overlapping functionality.

On Virtual Machines (VM) and Runtime Architecture

The question that repeatedly appears in the discussion—"reuse an existing VM or start a new runtime"—points to a technical foundation of Smalltalk implementations. A Smalltalk system usually consists of two parts: a virtual machine (VM) written in a low-level language such as C, responsible for memory management and bytecode execution, and an image running on top of it that contains the compiler and all tools. Environments such as Pharo and Squeak each maintain their own VM and share part of their historical lineage (traceable to the original OpenSmalltalk VM). If a new IDE reuses an existing VM, it can immediately gain mature just-in-time compilation (JIT), garbage collection, and FFI capabilities, at the cost of being limited by that VM's capability boundaries and license; if it starts a new runtime, it may introduce a more modern concurrency model or a smaller footprint, but it must rebuild performance-critical paths from scratch and faces the risk of being unable to directly run code from the existing ecosystem. This choice directly determines which existing libraries Pulsar can be compatible with and how far it can go in performance and portability.

What It Means for the Smalltalk Ecosystem

The emergence of an IDE usually does not immediately change a language's situation, but it is an observable signal. Pulsar's appearance at ESUG 2026 shows that the Smalltalk community is still investing resources in maintaining and updating its core tools, rather than relying solely on a few long-standing environments.

For developers, what is worth watching is its subsequent open-source strategy, the images/runtimes it supports, and whether it can truly improve day-to-day coding and debugging while preserving Smalltalk's dynamic characteristics. The answers to these questions will determine Pulsar's fate more than a single conference demonstration.

One-line Summary

The new-generation Smalltalk IDE Pulsar made its debut at ESUG 2026, drawing community attention to image semantics and runtime architecture.

Paragraph Summary

The new-generation Smalltalk integrated development environment Pulsar made its first public appearance at ESUG 2026 and sparked discussion in technical communities such as Hacker News. The article notes that although Smalltalk gave rise to widely inherited concepts such as MVC, the refactoring browser, and just-in-time compilation, its mainstream toolchain has long updated slowly, and existing environments each carry historical baggage, which creates an opportunity for a new IDE. Pulsar chose to launch at the community's most important annual gathering, with its target audience first and foremost experienced Smalltalk developers, and its demonstrations focused on redesigning fundamental interactions such as editing, navigation, debugging, and code browsing. The technical community, meanwhile, is more concerned with whether it truly understands image semantics, whether it can be compatible with the existing ecosystem, and whether it reuses an existing VM or starts a new runtime. The article argues that Pulsar's significance lies in showing that the community is still investing in core tools, but its subsequent open-source strategy and runtime support will truly determine its success.