pith. sign in

arxiv: 2605.16664 · v1 · pith:TFLXNEI5new · submitted 2026-05-15 · 💻 cs.SE

Optimizing an IDE for an Evolving Language Ecosystem

Adam Welc , Todd Nowacki , Dario Russi , Cameron Swords , Timothy A. K. Zakian This is my paper

Pith reviewed 2026-05-20 15:55 UTC · model grok-4.3

classification 💻 cs.SE
keywords IDE developmentLanguage Server ProtocolMove languagesmart contractscompiler integrationlanguage ecosystemSui platform
0
0 comments X

The pith

Integrating the Language Server Protocol with the core Move compiler produces a high-performance and feature-rich IDE that scales with the evolving language ecosystem.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper outlines a strategy for creating an IDE for the Move smart contract language by integrating the Language Server Protocol directly with the existing core language compiler. This method reuses the compiler's machinery to provide IDE capabilities such as code completion and error checking while adapting to the language's ongoing development. A sympathetic reader would care because it demonstrates a way to support IDE features in rapidly changing language ecosystems without building a separate tool from scratch, potentially saving development effort and ensuring consistency with the language definition.

Core claim

The authors establish that an LSP server implemented on top of the core Move compiler, with incremental optimizations for performance, successfully supports a high-performance and feature-rich IDE for the Move ecosystem on the Sui platform, and that this infrastructure has evolved to accommodate growth in the language without fundamental changes.

What carries the argument

The Language Server Protocol (LSP) integration with the core language compiler, which serves as the foundation for IDE features by reusing existing parsing, type checking, and analysis logic.

If this is right

  • The IDE maintains responsiveness and accuracy as the Move language evolves through targeted infrastructure changes.
  • Optimizations added incrementally handle larger codebases and additional features without performance loss.
  • Similar LSP-based reuse of core machinery supports IDE development for other smart contract languages facing ecosystem growth.
  • Lessons from the process guide future adaptations when language features expand further.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • This reuse strategy could lower the chance that IDE features diverge from the official language behavior over time.
  • The same integration pattern might be evaluated on languages with comparable compiler structures to test its broader applicability.

Load-bearing premise

The integration with the core compiler via LSP can be maintained and optimized to keep up with the growth of the Move language ecosystem without needing a different architecture.

What would settle it

A major update to the Move language that forces the IDE team to abandon the core compiler integration in favor of a separate implementation would falsify the claim that this strategy scales indefinitely.

read the original abstract

This paper describes a strategy for developing a high performance and feature-rich IDE for an evolving smart contract language ecosystem. Our target is Move, a programming language for the Sui smart contracts platform. The strategy we chose to support the Move language ecosystem utilizes Language Server Protocol (LSP) and it is based on the already existing "core" language machinery, in particular the core language compiler. We discuss alternatives we considered, as well as the evolution of our infrastructure that was necessary to keep up with the growth of the language ecosystem, particularly with respect to optimizations (and their impact) that needed to be implemented to accommodate this growth. We conclude with lessons learned during the IDE support development process that we hope will be beneficial for others attempting to follow a similar path.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The manuscript describes a strategy for developing a high-performance and feature-rich IDE for the evolving Move smart contract language ecosystem on the Sui platform. The chosen approach integrates the Language Server Protocol (LSP) with the existing core language compiler, covering alternatives considered, infrastructure evolution to accommodate ecosystem growth, specific optimizations and their impacts, and lessons learned from the development process.

Significance. This practical engineering case study offers potentially useful insights for maintaining IDE support in rapidly evolving domain-specific languages, particularly smart contract platforms. Detailing real-world optimizations and infrastructure adaptations could inform similar efforts elsewhere, provided the performance claims are backed by evidence.

major comments (2)
  1. [Abstract and §4] Abstract and §4 (Optimizations and their impact): The central claim that the LSP-based strategy 'delivers a high performance' IDE is not supported by any quantitative measurements, benchmarks, response-time data, or comparisons to alternatives. This evidence is load-bearing for the contribution and its absence prevents assessment of whether the optimizations actually achieved the stated benefits.
  2. [§3] §3 (Infrastructure evolution): The discussion of adaptations to handle ecosystem growth lacks concrete details on scalability limits encountered (e.g., specific language feature additions that triggered performance issues) or how the core compiler integration was preserved without architectural changes.
minor comments (1)
  1. [Throughout] Ensure all acronyms (LSP, IDE) are defined on first use and that section headings clearly map to the topics listed in the abstract for easier navigation.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments on our manuscript. We address each major comment below and indicate the revisions we will make to strengthen the paper.

read point-by-point responses

  1. Referee: [Abstract and §4] Abstract and §4 (Optimizations and their impact): The central claim that the LSP-based strategy 'delivers a high performance' IDE is not supported by any quantitative measurements, benchmarks, response-time data, or comparisons to alternatives. This evidence is load-bearing for the contribution and its absence prevents assessment of whether the optimizations actually achieved the stated benefits.

    Authors: We agree that quantitative evidence is important to substantiate the performance claims. Although the manuscript focuses on the overall strategy, infrastructure evolution, and lessons learned, we collected internal performance data during development. In the revised version we will add concrete benchmark results to §4, including response-time measurements for core features such as diagnostics and code completion on representative Move codebases, before-and-after comparisons for the implemented optimizations, and a brief quantitative contrast with the alternative approaches discussed earlier in the paper. revision: yes

  2. Referee: [§3] §3 (Infrastructure evolution): The discussion of adaptations to handle ecosystem growth lacks concrete details on scalability limits encountered (e.g., specific language feature additions that triggered performance issues) or how the core compiler integration was preserved without architectural changes.

    Authors: We accept that additional concrete details would improve clarity. We will expand §3 with specific examples of language features (such as new Move type-system extensions and Sui-specific module constructs) that increased analysis load and necessitated the optimizations. We will also describe how core-compiler integration was maintained through the use of the compiler's existing incremental APIs and extension hooks, allowing us to add LSP-layer caching and incremental processing without altering the compiler's fundamental architecture. revision: yes

Circularity Check

0 steps flagged

No significant circularity in engineering case study

full rationale

The paper is a practical software engineering report on implementing an LSP-based IDE for the Move language by leveraging the existing core compiler. It describes alternatives considered, infrastructure changes, specific optimizations for ecosystem growth, and lessons learned, with no equations, formal derivations, predictions, or fitted parameters present. Claims rest on implementation experience rather than any reduction to self-citations or inputs by construction, rendering the work self-contained as a case study without load-bearing circular steps.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The paper is a descriptive engineering report. No free parameters, mathematical axioms, or invented entities are introduced or required by the abstract.

pith-pipeline@v0.9.0 · 5660 in / 1093 out tokens · 43160 ms · 2026-05-20T15:55:22.079155+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages

  1. [1]

    Dill, Victor Gao, Ben Maurer, Todd Nowacki, Alistair Pott, Shaz Qadeer, Dario Rain, Stephane Russi, Tim Sezer, Runtian Zakian, and Zhou

    Sam Blackshear, Evan Cheng, David L. Dill, Victor Gao, Ben Maurer, Todd Nowacki, Alistair Pott, Shaz Qadeer, Dario Rain, Stephane Russi, Tim Sezer, Runtian Zakian, and Zhou. 2019. Move: A Language With Programmable Re- sources. https://api.semanticscholar.org/CorpusID:201681125

    work page 2019

  2. [2]

    Vim Community. 2025. Vim – the ubiquitous text editor. https://www.vim.org

    work page 2025

  3. [3]

    Eclipse Foundation. 2025. Eclipse IDE. https://eclipseide.org

    work page 2025

  4. [4]

    Free Software Foundation. 2025. GNU Emacs. https://www.gnu.org/software/ emacs/emacs.html

    work page 2025

  5. [5]

    Sublime HQ. 2025. Text Editing, Done Right. https://www.sublimetext.com

    work page 2025

  6. [6]

    Zed Industries. 2025. The editor for what’s next. https://zed.dev

    work page 2025

  7. [7]

    JetBrains. 2025. Make it happen. With code. https://www.jetbrains.com/ides

    work page 2025

  8. [8]

    Alex Kladov. 2021. IDEs and Macros. https://rust-analyzer.github.io/blog/2021/ 11/21/ides-and-macros.html

    work page 2021

  9. [9]

    Alex Kladov. 2023. Resilient LL Parsing Tutorial. https://matklad.github.io/2023/ 05/21/resilient-ll-parsing-tutorial.html

    work page 2023

  10. [10]

    Ann Kuss. 2024. The Most Popular IDEs for Developers in 2025. https:// outstaffyourteam.com/articles/most-popular-ides-for-developers

    work page 2024

  11. [11]

    Microsoft. 2025. Language Server Protocol. https://microsoft.github.io/language- server-protocol

    work page 2025

  12. [12]

    Microsoft. 2025. Visual Studio. https://visualstudio.microsoft.com

    work page 2025

  13. [13]

    Microsoft. 2025. Visual Studio Code. https://code.visualstudio.com

    work page 2025

  14. [14]

    Luis Nerey. 2025. Top IDEs of 2025: Revolutionizing the Developer Ex- perience. https://www.webcreek.com/en/blog/technology/top-ides-of-2025- revolutionizing-the-developer-experience

    work page 2025

  15. [15]

    Stack Overflow. 2025. Most popular technologies. Dev IDEs. https://survey. stackoverflow.co/2025/technology#1-dev-id-es

    work page 2025

  16. [16]

    Ferrous Systems and contributors. 2025. rust.analyzer. https://rust-analyzer. github.io

    work page 2025

  17. [17]

    The MystenLabs Team. 2022. The Sui Smart Contracts Platform. https://docs. sui.io/paper/sui.pdf

    work page 2022

  18. [18]

    The Rust Dev Tools Team. 2022. RLS Deprecation. https://blog.rust-lang.org/ 2022/07/01/RLS-deprecation/

    work page 2022