在編程語言領(lǐng)域，六七十年代日本主要是把COBOL，PL/I等編程語言做深度本地化；后來搞第五代計算機，主推Prolog（邏輯編程）。

到了九十年代，日本嵌入式開發(fā)很發(fā)達，主要用C語言，但是也誕生了像Ruby 這樣的互聯(lián)網(wǎng)編程語言，被Ruby on Rails帶火后，流行一時，也是亞洲唯一一個進入到權(quán)威編程語言流行度排行前十的編程語言。

AI時代，日本程序員 Takato Honda 推出了一門叫做 “Sui”（粋）的編程語言，想解決大語言模型(LLM)編寫代碼的準(zhǔn)確性問題，宣稱能讓 LLM 以100% 的準(zhǔn)確率生成代碼，引起了不少人的關(guān)注。

讓人意外的是，在技術(shù)氛圍濃厚的日本，來自中國的一門叫MoonBit（月兔）的編程語言，走進了日本開發(fā)者社區(qū)的大門，引發(fā)了一場熱烈討論。

0 1

MoonBit 月兔闖入日本技術(shù)圈

其實早在去年4月，MoonBit 就在日本技術(shù)圈“火”過一把。

當(dāng)時大V @mizchi 在 日本開發(fā)者社區(qū) Zenn 上發(fā)了一篇文章《MoonBit 是 WebAssembly 時代的最佳編程語言》，力挺 MoonBit，當(dāng)天就成了平臺的大熱門。

大家討論最深的是它對 Wasm-GC 的深度定制，以及像“省略結(jié)構(gòu)體逗號”這種極簡但好用的語法細(xì)節(jié)。那段時間，Twitter上的日本開發(fā)者幾乎都在聊它。

更難得的是，一年多過去了，MoonBit 在日本社區(qū)不只是“出道即巔峰”，其熱度至今依然非常穩(wěn)健且活躍。

看看幾位日本開發(fā)者的具體評價吧：

• @matte?：“在使用MoonBit時感受到了類似Rust的體驗，同時還有GC支持?！?/p>

• @maguro?：“如果Go語言的語法能像MoonBit那樣，我會覺得編寫起來更加容易，因為MoonBit具有求和類型、模式匹配和默認(rèn)不可變等特性?！?/p>

• @ mattn：我很久沒用過MoonBit了，但它似乎還不支持 Wasi。如果支持的話，我覺得它可能會占據(jù)主導(dǎo)地位。

• @ jnst：MoonBit看起來不錯。它的工具鏈和生態(tài)系統(tǒng)幾乎不需要任何隱式領(lǐng)域知識，并且擁有大量的參考實現(xiàn)。如果它是一種原生人工智能編程語言，那么在未來的某個階段，自主人工智能的開發(fā)總量很可能會超過人類的開發(fā)總量。那些押注 MoonBit 的人或許正在展望一個它在 3-5 年內(nèi)占據(jù)主導(dǎo)地位的世界。

• @ t3tra # type: ignore：MoonBit 與我想要創(chuàng)建的語言非常接近，它是強力的競爭對手

在日本的技術(shù)社區(qū)，也已經(jīng)有人通過撰寫 MoonBit的付費文章賺錢：

0 2

實現(xiàn)最強 Markdown 編輯器

MoonBit 在日本的爆火，不僅僅限于口頭討論熱烈，還有不少人在用它進行實戰(zhàn)，開發(fā)各種項目，比如前面提到的mizchi，他用MoonBit打造了一個Markdown編輯器，不但可以處理大量內(nèi)容，運行速度還快得驚人。

傳統(tǒng)Markdown編輯器（以及一般的文本編輯器）的一個問題是：每次用戶輸入內(nèi)容后，都需要重新解析整個文本。

為了保持 60fps 的幀率，需要在 16 毫秒內(nèi)解析并顯示整個文本；而要達到 120fps，則需要在 8 毫秒內(nèi)完成。這是一件不容易的事情，尤其是隨著文本的逐漸增大，性能會線性下降。

而mizchi則采用了一種“增量式”的方法，讓解析的復(fù)雜度接近O(1)，即使文檔內(nèi)容達到20,000 個字符，也沒有出現(xiàn)顯示延遲，幀率始終保持在60fps。

這是一個純粹的 MoonBit 實現(xiàn)，不使用 FFI，因此可以在任何環(huán)境中作為庫使用，包括 js/wasm/native。

為了測試性能，作者拿它和其他知名的Markdown編輯器做了對比。

1、與不同庫的比較

作者準(zhǔn)備了小、中、大三種尺寸的文檔，并將它們與MoonBit 官方實現(xiàn)的 cmark 和 Rust 實現(xiàn)的 markdown-rs 進行比較。

它比markdown-rs快不少，但可惜的是，沒能超越 cmark（不得不說，官方的實現(xiàn)還是挺厲害?。?。

2、增量解析基準(zhǔn)測試

這是最主要的測試。當(dāng)你在編輯器中編輯一個字符時，測量每個解析器需要多少微秒。

mizchi/markdown 的增量解析大約只需 10μs 即可完成，與文檔大小無關(guān)。

比較一份包含100段的文檔：

• mizchi/markdown（增量）：10 微秒

• rami3l/cmark（完整版）：433 微秒 → 慢了 43 倍

• markdown-rs（完整版）：3674 微秒 → 慢 367 倍

對于完整解析，cmark 速度最快；但對于編輯器中的實時預(yù)覽，增量解析則完勝。

隨著文檔長度的增加，這種優(yōu)勢會更加明顯，而增量解析的計算復(fù)雜度接近 O(1)。

mizchi說這是他人生第5次實現(xiàn)Markdown編輯器，也是速度最快的一次，他認(rèn)為對于有TypeScript和Rust使用經(jīng)驗的人來說，MoonBit是最佳的語言。

MoonBit允許你選擇運行的平臺（js,native,wasm），使用TypeScript很難做到，而MoonBit恰到好處的抽象，可以讓你進行高級描述，不但適合系統(tǒng)編程，也適用應(yīng)用層編程，這比Rust好很多，Rust經(jīng)常出現(xiàn)生命周期和底層二進制操作被隱藏起來的情況。

試用一下：

https://markdown.mizchi.workers.dev/

GitHub:

https://github.com/mizchi/markdown.mbt

npm:

https://www.npmjs.com/package/@mizchi/markdown

0 3

Luna UI 框架

MoonBit 的優(yōu)勢，并不只是體現(xiàn)在“解析器”這種偏底層的算法問題上，在實時交互型UI上，也表現(xiàn)得異常穩(wěn)定。

Luna UI 是另外一個用MoonBit寫的項目，這是一個高速的響應(yīng)式UI框架，體積小巧，無需編譯時優(yōu)化。

作者mizchi用過各種UI庫，總是覺得無法完全滿足自己的需求，決定創(chuàng)造屬于自己的東西。

Luna UI有這樣的特點：

• 輕量級運行時，方便移植

• 使用Signal進行精細(xì)化響應(yīng)

• 體積小到無需編譯時優(yōu)化

• 支持 WebComponents SSR + Hydration

這是一個用于Luna性能測試的射擊游戲：

注意：這不是 HTML Canvas，而是一個 100x100 的 DOM，它會在每一幀實時重寫。

用開發(fā)者工具測試時，幾乎沒有 JS 加載，幀率保持在 60 FPS，在智能手機上測試時也很流暢。

當(dāng)作者嘗試使用 React 實現(xiàn)類似功能時，幀率只達到了12 FPS 左右，和Luna相差甚遠(yuǎn)。

射擊游戲的Luna源碼也僅僅有6.4K左右，充分體現(xiàn)了Luna和MoonBit的優(yōu)勢：體積小巧，性能強悍

傳送門：

https://github.com/mizchi/luna.mbt/tree/main/src/examples/game

0 4

總結(jié)

MoonBit 在日本技術(shù)圈持續(xù)受到關(guān)注，其實也在映射一個更大的變化：底層技術(shù)，已經(jīng)不再只是美國或歐洲的“專利”了，中國同樣開始在這一層面上拿出有競爭力的創(chuàng)新。

憑借高性能運行時、簡潔的語法設(shè)計，以及對 AI 場景的天然友好，MoonBit 讓開發(fā)者可以在 WebAssembly、原生或跨平臺環(huán)境中，兼顧性能與開發(fā)體驗。這種“把復(fù)雜度留給工具，把簡單留給人”的思路，正好踩在當(dāng)下工具鏈演進的節(jié)奏點上。

可以預(yù)期，在未來三到五年里，MoonBit 以及一批類似的底層語言和工具，會持續(xù)影響開發(fā)者對“代碼應(yīng)該怎么寫”的理解。而 MoonBit 能夠被日本開發(fā)者社區(qū)反復(fù)討論、認(rèn)真驗證，本身就說明中國的底層技術(shù)正在變得越來越成熟。

至于 MoonBit 會不會成為“最好的語言”，時間自會給出答案。