Some people here might still remember me from the early days of ReScript. Although I no longer maintain ReScript, the years I spent building its compiler, type system, and toolchain had an enormous impact on how I think about language and tooling design. Over the past three years I’ve been working on a new language called MoonBit, and I thought it might be interesting to share what it is and what I learned from the ReScript experience.
What is MoonBit?
MoonBit is a high level general purpose language like Swift, Golang and Java. It supports multiple backend including native (C,LLVM), Wasm(with/out GC) and JS, the Moonbit toolchain comes with a builtin coding agent(now rewritten in MoonBit itself.
MoonBit is a new statically typed, compiled language designed from the ground up to be AI-native. It aims to sit in a fairly pragmatic space: familiar syntax, predictable semantics, extremely fast compilation, and a standard library shaped around real-world software engineering rather than academic idealism. A large part of the vision is that AI will generate, refactor, and evolve a significant amount of MoonBit code, and the language, tooling, and packaging ecosystem are all designed with that in mind. In other words, instead of assuming a human-first workflow and then bolting AI on top, we try to co-design the whole experience so humans and LLMs can collaborate effectively.
The long-term goal is to build an end-to-end “software factory” where the language, compiler, IDE, package system, testing tools, and AI agents work together. This means making choices that sometimes look conservative but produce a more predictable environment for large-scale AI-assisted development.
Lessons I took from building the ReScript toolchain
Working on ReScript was both rewarding and instructive. A lot of decisions in MoonBit were shaped by that experience.
The first lesson was that the language and the IDE cannot be designed separately. ReScript didn’t have strong IDE support for a long time, partly because certain language features and compilation pipelines made tooling unnecessarily difficult(We inherited a lot from OCaml and don’t have fault tolerant lexer, parser, type checker in the beginning). For MoonBit, the IDE is treated as a first-class consumer from day one. Language services, incremental compilation, symbol queries, and navigation APIs are designed alongside the syntax and type system, not as an afterthought. The latest MoonBit IDE performance is superb that can respond under 100ms generally, we also shipped a web browser based IDE in the beginning(tour.moonbitlang.com)
The second lesson is the importance of controlling your own package ecosystem. With ReScript, depending on npm created both cultural and technical mismatches. MoonBit has its own package registry(mooncakes.io) and package manager from the start, which makes it possible to grow a community slowly, encourage idiomatic libraries, and avoid the dependency sprawl that often appears when a language simply inherits an existing ecosystem wholesale.
A third lesson is to be disciplined with inference. ReScript’s type inference was powerful but sometimes fragile. In MoonBit, top-level annotations are required and the type system avoids local generalization. Having slightly less inference leads to far more predictable code, easier tooling, easier refactoring, and more reliable AI generation.
Another takeaway is the value of giving developers strong support for data processing. ReScript had pattern matching, but in hindsight it could have gone further. MoonBit leans hard into this area with more ergonomic match constructs, better destructuring, and small pieces of syntactic sugar that make everyday code easier to read and generate. For example, we have native support for JSON, String and Bytes processing using pattern match, and pattern match over array is just as easy as List in ReScript.
Finally, there is the question of being “AI friendly”. It’s not obvious how to define this in theory. Instead of guessing, we take a more empirical approach: every new feature, syntax form, or sugar is evaluated by actually running LLM-based generation and seeing what produces more correct, idiomatic, consistent output. The language is co-designed with the tooling and with LLMs themselves. This matters in practice more than one might expect; tiny syntactic details can dramatically change the quality of generated code.
These are just a few reflections from someone who spent years building one toolchain and is now building another with the benefit of hindsight. MoonBit is not meant to replace ReScript or compete with it. They grew out of different goals and different eras. But many of the ideas in MoonBit trace directly back to the lessons I learned while building ReScript, and for that I remain genuinely grateful to the community that formed around it.
Happy to answer any questions or go deeper on any part if people find it interesting.
