iTranslated by AI
Moonbit Advent Calendar Retrospective: Is it truly a practical language?
This is a reflection on the final day of the Moonbit Advent Calendar.
The purpose of creating this calendar was to push myself (which resulted in the completion of Luna UI) and to provide an opportunity for everyone to try Moonbit whenever they could.
As a result, I wrote nearly 10 articles myself, but we managed to gather more participants than initially expected, so I believe that goal was achieved.
To be honest, I originally intended to just post a series of light, reference-like articles to fill the space, but I couldn't stay complacent once @ramenha0141 started posting high-energy articles. So, I put quite a bit of effort into writing each of my articles.
(There are still 2-3 empty days, but I have some articles I'm working on, so I'll fill them in later.)
Reflection on the Advent Calendar
It might sound self-important, but I’ve had the successful experience of making React and Agentic Coding popular in Japan. Based on that experience, I planned to use this opportunity to make Moonbit popular as well.
For the first day, I decided to write an article that wouldn't necessarily "go viral" on its own but would clear up the anxieties of early adopters who might write articles. So, I started by explaining the boilerplate generated by moon new ....
After writing a few articles and seeing the reaction on SNS, I started to feel that articles titled "Moonbit's [Something]" might make people lose interest because they don't even know what it is in the first place.
So, to truly demonstrate the appeal of Moonbit, I shifted towards presenting cross-targets and practical performance benefits first.
As a result, the articles that performed well all followed this pattern:
- Actually building something and showing it
- Proving its superiority through benchmarks
- Presenting the practical benefits of Moonbit, which can achieve these across multiple languages/targets
(To be honest, I'm also relying somewhat on my own reach in Japan.)
In my work, I often create middleware for TypeScript/Node.js, so I have a strong desire to actually write those in Moonbit.
So, from here, I will summarize the articles posted by others and compile feedback on Moonbit.
Implementing Tetris in MoonBit by @ramenha0141
It was great to learn not just about Moonbit code, but also about SRS (Super Rotation System), the rotation rules for Tetris tetrominoes.
Overall, the writing experience was quite good, and I felt it was a language worthy of being called "Rust with GC."
In particular, operator overloading and pattern matching are very powerful and serve as strong motivations to use MoonBit.
To reiterate, I was able to cross the language barrier much more easily than I imagined, and I could write code with a volume not much different from TypeScript.
This is exactly what I wanted to convey. I'm so happy they felt that way...
Creating a sqlc plugin with MoonBit: Using moonbit protoc, touching Wasm, etc. (Parts 1–3) by @4245ryomt
This article describes an attempt to create a sqlc plugin for protobuf code generation using MoonBit.
Considering interoperability, implementing from this protocol layer seems like the standard approach.
How Mooncakes Works by comavius
This article explains the mechanism of Mooncakes, MoonBit's package registry, by reading through the Rust CLI implementation.
It's interesting that it's quite straightforward, downloading directly from S3.
"Maria," the New AI Agent Implementation in MoonBit, by laiso
The well-known laiso joined the fray and provided an explanation of Maria.
I hadn't been very interested in Maria since I mainly use ClaudeCode, but this part caught my eye:
What's interesting is that Maria is designed more as a platform for managing multiple tasks rather than just a CLI agent. The key point is that it treats LLM agents as asynchronous background tasks that can be managed and reconnected. The architecture feels similar to Cline CLI, and you can even check a management screen for debugging when it's running.
I actually encountered a problem where I needed to compile a large amount of Markdown in parallel. Recalling this article, I created a library called process_pool.
Implementing a Backend Using MoonBit by @hiroyannnn
I was trying with a JS base halfway through, but then I realized it would be more convenient if it were typed on the TS side...
(MoonBit officially generates .d.ts for the JS target, but my impression was that the experience on the TS side was still a bit rough, as someanytypes were mixed in.)
I created a small tool to generate a thin TypeScript bridge (type definitions + exports) based on MoonBit'spkg.generated.mbti(generated bymoon info) andlink.js.exportsinmoon.pkg.json.
Actually, I have made something very similar myself.
This serves as a good sample to show the core team that these use cases actually exist.
Once the official MoonBit outputs (like .d.ts) become richer or the ecosystem around MoonBit matures, this tool might become unnecessary or shrink to a very thin layer.
Introduction to the World of Wasm Using MoonBit by watanabe-tsubasa
An experience report on running Wasm built with MoonBit on Node.js.
I had an image that Wasm would be difficult, but as expected of a language designed with Wasm usage in mind, I was able to implement it smoothly.
While the benefits might be small for Fibonacci calculations, MoonBit has a wonderful feature to match JSON directly, so I think things like JSON validators could clearly leverage that advantage.
What I Learned About Infix Operators and Pipes While Building a URL Parser in MoonBit Based on Elm's URL Parser by @4245ryomt
This is an article that compares MoonBit's Pipeline Operator from the perspective of Elm's URL parser.
main =
let
-- Parser definition
parser = s "users" </> string </> s "posts" </> int
|> map ((\userId -> \name -> (userId, name)))
urlM = Url.fromString "https://localhost/users/alice/posts/123"
in
urlM
|> Maybe.andThen (parse parser)
|> Debug.toString
|> text
When implementing something similar on the MoonBit side:
@lib.top()
|> @lib.slash(@lib.s("users"))
|> @lib.slash(@lib.string())
I was surprised to find that even though both are functional languages with pipes, the behavior of pipelines differs between Elm and MoonBit. It made me curious if there are other languages that follow this policy of passing to the first argument, besides MoonBit.
Since it's often called "F# Style," my understanding is that it originates from F#.
MoonBit Online Meetup #9: Current Status, Roadmap Sharing & AI Live Coding by moonbitlang
To my surprise, the MoonBit core team officially wrote an article. I attended the meetup on the day and asked a few questions.
- Introduction of MoonBit AI, which is being integrated into the editor.
- Introduction of
moon ide, which allows using LSP symbol search from the CLI: https://github.com/moonbitlang/system-prompt/blob/main/ide.md - Question: What breaking changes are planned before the stable 1.0 release next year?
-
Iter[T], which is mainly used internally, will be deprecated and unified intoIterator[T]. -
moon.pkg.jsonwill become a DSL calledmoon.pkg: https://github.com/moonbitlang/moonbit-evolution/issues/18
-
- Question: Will private parts like
moonc,vscode, andlspbe made public?- Currently, there are many OCaml implementations (making it hard to get community support), so they plan to release them once they are self-hosted.
- Question: Any plans for multi-threading support?
- They want to work on it eventually, but it is out of scope for the stable 1.0 release.
Impressions of Creating a Super Basic To-Do App in MoonBit by @akiranishimura
An impression article by an author from the AI-native generation who tried out MoonBit.
I usually build apps with FullStack TS, but trying to write in a language for the first time without AI really made me use a part of my brain I don't normally use.
I wrote the basic To-Do App part myself, but I had Claude Code write all the persistence logic using local storage.
I repeated the process of checking the generated JS whenever an error occurred, and I was like "Whoa," seeing it through to a solid implementation.
It might be because I wasn't doing anything too complex, but I'm impressed that I could write this much in a language I haven't studied at all.
I can relate to the part about using a part of the brain you don't normally use, especially coming from a TS background. Specifically with traits, enums, and pattern matching.
Looking at SNS, I get the feeling that the MoonBit + React boilerplate I created is being used for learning purposes.
Implementing a Simple Lisp Interpreter in MoonBit by @nuskey
This article covers implementing a Lisp tokenizer, lexer, parser, and interpreter to verify MoonBit's unique writing feel.
It's a very straightforward implementation. The code looks similar to Rust, but maybe the error handling is a bit different. Unlike Rust, there's no ownership, so it's nice that it works even if you write it somewhat casually.
I believe the fact that it "works even if you write it somewhat casually" makes it suitable for the application layer as well, and I think it can be used to replace TS.
This is likely because MoonBit's
Charcan handle surrogate pairs, but since it's a bit inconvenient during analysis, I'm converting it toArray[Char]viato_array()for now. (It doesn't seem great for performance, so I'd like to do it properly withiter(), but since I don't fully understand MoonBit's iterator specs yet, I'll go with this for now...)
Yes, I also ran into this when implementing the Markdown parser and FFI... I had to convert it when passing it to C via FFI. Using StringView should be the right way for string analysis, but there's currently a mix of parts that return code points and others that don't.
Since the Wasm environment also often deals with UTF-8, encoding conversion can sometimes become a bottleneck in string analysis. While Int16 isn't bad, I feel there's some room for reconsideration here.
My impression from getting my hands dirty is that modern language features have been picked up without exception, providing high expressiveness and a solid writing feel. The maturity of the toolchain, including the LSP, is sufficient, making it very comfortable to write in. I'm looking forward to the v1.0 release.
This is exactly what I find pleasing as well. Young languages usually have incomplete or slow LSPs, but in MoonBit, that area seems to be built as a first-class citizen, and the editor experience is truly excellent.
[MoonBit] Converting Events to Async with oneshot by @nuskey
A story about porting something equivalent to Rust's oneshot to practice asynchronous programming.
Originally, I only planned for one article, but I got into the flow and made another one. A language that's fun to write is a good thing.
Everyone should casually create libraries and toss them into Mooncakes.
That covers the content of the articles posted for the MoonBit Advent Calendar.
To sum it up broadly, the general sentiment seems to be: "great writing feel," "can be written somewhat casually," and "often unsure about what to do in edge cases."
I will also summarize the things I built myself.
Libraries Created During This Period
I have created the following libraries, including those that have not been turned into articles:
- mooncakes
-
mizchi/luna
- Lightweight UI library
- https://zenn.dev/mizchi/articles/moonbit-luna-ui
- npm https://www.npmjs.com/package/@luna_ui/luna
- mizchi/jsonschema
- mizchi/js
-
mizchi/cloudflare
- A collection of bindings for Cloudflare Workers. Basic workers.
- mizchi/npm_typed
-
mizchi/cbor
- RFC 8949 CBOR encoder/decoder https://www.rfc-editor.org/rfc/rfc8949.html
-
mizchi/libgit2
- libgit2 bindings
- https://zenn.dev/mizchi/articles/moonbit-libgit2-native-ffi
-
mizchi/sqlite
- Bindings for libsqlite https://github.com/mizchi/sqlite.mbt
-
mizchi/process_pool
- Process pool supporting both native and JS
- mizchi/markdown
-
mizchi/luna
- npm
-
vite-plugin-moonbit
- A vite-plugin for easily setting up Moonbit in the frontend
-
@luna_ui/luna
- JS bindings for luna
-
@luna_ui/astra
- A static site generator implemented with Luna
-
vite-plugin-moonbit
- deno
- @mizchi/mbts
- CLI for TypeScript type conversion and boilerplate generation
- @mizchi/mbts
Final Reflections
I believe that in development predicated on AI from 2025 onwards, programming languages must become more sophisticated in terms of "how much complexity they can withstand" and "how concisely difficult concepts can be described." I felt this strongly during the implementation of lsmcp (a tool to operate LSP from MCP) which I created in the middle of this year.
Moonbit is a language that has almost everything I need, and I find its writing feel to be the best. Seeing that others seem to share the same impression (including the parts that are currently lacking), I feel confident in my intuition.
While the amount of AI training data is still insufficient, the messages from moon check are so polite that you can push through. This is true. It's truly wonderful that there are established means to provide information to AI, such as moon ide and moon doc.
I've gained the confidence that Moonbit can handle the range of problems I used to solve by replacing JS/TS implementations. In fact, I'm even writing things in Moonbit that I would have previously chosen Rust for simply because they weren't suitable for TS. My CBOR encoder implementation actually produced faster benchmarks than Rust.
Above all, this language is truly easy to write in. It boils down to that.
The current problem with Moonbit is the lack of libraries. I believe this will be solved as its merits become widely known and everyone starts writing in this language. It's just a chicken-and-egg problem.
Well, why not give it a try as a way to pass the time during the New Year holidays without overthinking it?
Finally, I would like to thank the Moonbitlang Core Team for adopting my numerous proposals, many of which I made without regard for the complexities of their internal implementation.
Discussion