我欲封天耳根小说零,完结小说排行榜,玄幻小说完本

近日，JetBrains 發布了 Kotlin 1.8.20 beta 版本，其中包括一項名為“Kotlin/Wasm”的實驗性功能，明確將 WebAssembly 設為編譯目標。據介紹，新版本依賴于原生 Wasm 垃圾收集功能 WasmGC，后者同樣處于早期開發階段。

JetBrains 總結了 Kotlin/Wasm 的優勢：

與 wasm32 Kotlin/Native 目標相比，Kotlin/Wasm 的編譯速度更快，因為后者不必使用 LLVM。
由于 Wasm 垃圾收集支持，與 wasm32 目標相比，Kotlin/Wasm 與 JS 的互操作性、與瀏覽器的集成更容易。
與 Kotlin/JS 和 JavaScript 相比，Kotlin/Wasm 應用程序啟動時間可能更快，因為 Wasm 具有緊湊且易于解析的字節代碼。
與 Kotlin/JS 和 JavaScript 相比，Kotlin/Wasm 應用程序運行時性能更快，因為 Wasm 是一種靜態類型語言。

不過，目前還沒有 IDE 為 Kotlin/Wasm 提供支持。JetBrains 在版本發行說明中提到，“我們以開箱即用的形式，為 Kotlin/Wasm 提供 Kotlin 標準庫（stdlib）和測試庫（kotlin/test）。”

瀏覽器中運行的 Kotlin/Wasm 演示

此前，通過基于 LLVM 的 Kotlin-Native 編譯指向和 LLVM Wasm 支持，Kotlin 已經能夠在某種程度上實現向 Wasm 的編譯，這種舊方法被稱為 wasm32。隨著新版本的發布，該方法將成為被棄用的多種 Kotlin/Native 編譯目標之一。

作為一種 JVM 語言，Kotlin 具備垃圾收集機制，但此前 Wasm 一直無法原生支持垃圾收集，這就要求各垃圾收集語言自行提供解決方案。Wasm-gc 就是其中一項提案，承諾“對高級語言做出有效支持”。此次，這一設計有望超越自定義解決方案，并減少應用程序的二進制文件大小。Wasm-gc 可通過瀏覽器 Flag 在最新版本的 Chrome、Firefox 和 Edge 上啟用。

Kotlin 的“通用型語言”理想

早在 2017 年，主流瀏覽器都已經支持 WebAssembly。隨著 WebAssembly 的蓬勃發展，各種編程語言也在增加對其的支持。比如，C/C++、Rust、Golang 等已支持將語言編譯到 WebAssembly 目標平臺，Lua、JavaScript、Ruby 和 Python 等支持將語言的虛擬機或解釋器編譯到 WebAssembly 平臺。

2021 年，WebAssembly 開源項目開始支持 GC（垃圾回收器），為實現 WebAssembly 支持像 Java、Kotlin 這樣的前端語言做準備。同年，Kotlin 程序語言開發團隊更新了發展路線，其中的一個重點就是增加 WebAssembly 支持。

Kotlin 總項目經理 Egor Tolstoy 表示，他們認為 WebAssembly 會成為未來創建豐富網頁應用程序的新標準，而 Kotlin 必需要能夠完美的提供支持。因此官方火力全開，組建了一個專門團隊來開發 Kotlin/Wasm 工作，并且與 WebAssembly 垃圾回收提案作者緊密合作，要實現 Kotlin 語言的基本功能、函數庫和基本 Gradle 的支持，還要添加實驗性 JavaScript 互通操作功能。

Kotlin 在 2017 Google 發表聲明后總被當成是安卓專用開發語言，但實際上，Kotlin 正在積極地向多平臺語言演進，即“通用型語言”。

如今，JetBrains 提供了多個支持多平臺的庫，如 kotlinx.coroutines、kotlinx.serialization、kotlinx-datetime。而 Kotlin 社區也緊跟著這樣的趨勢發展，出現了愈來愈多的庫、框架來支持多平臺，如 Arrow、Okio、Apollo 等在新版本中都支持了多平臺開發。

Kotlin/Wasm 究竟有什么潛力

在最初的設計中，WebAssembly 只是 C、C++ 或 Rust 這些低級語言的編譯目標。至于 Python、Ruby 甚至是 JavaScript 等動態語言，能充當解釋性的虛擬機即可。

但 WebAssembly 垃圾收集（GC）的貢獻者們正努力把它打造成垃圾收集語言（例如 Java、Kotlin 或 Dart）的編譯目標，并停止使用 JavaScript 作為 Web 字節碼。此外，他們還考慮把其他語言也都轉化成前端開發中的理想選項，而不必像 TypeScript 那樣把一切先編譯成 JavaScript。

請注意，這些語言已經能夠在各個應用程序內提供自己的自定義垃圾收集，借此實現對 WebAssembly 的編譯。這樣做的缺點就是這樣生成的工件會更大，所以也不知道 WasmGC 真正推出時，原來的這種處理方式還有沒有競爭力。

WasmGC 的實現源自 Chrome、Firefox、Edge 和 Safari 四大瀏覽器的一個持續性項目，目前需要使用 Flag 加以啟用（例如，在 Chrome 或 Edge 上，需要使用 --js-flags=--experimental-wasm-gc 命令行參數）。正是因為達不到開箱即用的程度，所以該技術目前還沒能得到廣泛采用。

但是，當 WasmGC 步入第四階段并在大多數瀏覽器中實現開箱即用后，能夠利用 WasmGC 的語言將迎來顯著的競爭優勢。

在 VMware 從事 Spring Framework 工作的 Sébastien Deleuze 稱，Kotlin/Wasm 很早就在關注 WasmGC，谷歌也在使用 J2CL 和 Dart 在 Google Sheets 中將 Java 編譯為 WasmGC。

前端（及全棧）開發

“因為要求開發者同時了解 Kotlin 和 JavaScript 兩套生態系統，所以我個人一直對 Kotlin/JS 不太感冒，但 Kotlin/Wasm 確實是個重塑前端開發面貌的好機會?！盌eleuze 表示，“當然，Kotlin/Wasm 必須要提供良好的 JavaScript 互操作性（它也確實做到了），并作為可選項。”

目前，Kotlin/Wasm 提供 DOM API，所以某些 Kotlin/Wasm 前端框架可能已經足夠成為前端開發的理想選擇。Deleuze 表示自己可能也會試試將 Kotlin/Wasm 用于前端開發，再配合 Spring Boot Kotlin/JVM 后端實現 Kotlin 中的全棧開發。

但從另一個角度來看，WebAssembly 還有更多值得發掘的亮點。如果 Compose for Web（Android 上使用的多平臺版 Jetpack Compose）能夠用 Kotlin/Wasm 代替 Kotlin/JS 來完美執行基于 Canvas 的像素渲染，結果又會如何？（稍做劇透，其實已經實現了。）

如果 Kotlin/Wasm 能夠用 WebAssembly 來取代 JavaScript，支持一種新的 Jamstack 架構，結果又會如何？

WebAssembly 組件模型

要想充分理解 Kotlin/Wasm 的巨大潛力，就不能不提 WebAssembly 組件模型。正是它的存在，讓我們能使用任意支持 WebAssembly 的語言，為 WebAssembly 開發組件。這項工作的基石正是 WIT 格式，可用于描述導入和展出并生成特定于語言的 binding。

Deleuze 親自實踐了一下，看看 WIT 是如何被轉譯成 Kotlin 的，結果看起來還不錯。例如，其嘗試將 WIT variant 定義為：

variant filter {
    all,
    none,
    some(list<string>),
 }

轉譯出的 Kotlin 代碼如下：

sealed interface Filter {
   object All : Filter
   object None : Filter
   class Some(val value: List): Filter
}

利用 String 提供的 null 安全特性，WIT option能夠被準確轉譯為 Kotlin 慣用的選項值處理方式。在 Deleuze 看來，Kotlin 協程也將成為組件模型異步支持綁定中一個強大的競爭優勢。

用 warg 實現 WebAssembly 包管理

大家可能會好奇 WebAssembly 要如何發布和使用。別擔心，面向 WebAssembly 包的標準化管理項目 Warg，有望帶來各種包 repo 實例，其中的關鍵就是 WebAssembly 包 repo 將支持多語言。

沒錯，Maven Central 或者 NPM 在 Java 和 JavaScript 之外的語言中也有使用，但無論是生產還是消費都擺脫不了“二等公民”的陰影。Warg 和 WebAssembly 將真正把多語言組件推向全新的高度。

Deleuze 預測，像 Rust/C/C++ 這樣的語言將主要用于生產 Wasm 組件（強調效率，只為非共享方法提供極小、甚至干脆不提供運行時）；而 Kotlin/Wasm 這類能利用 WasmGC 的語言，則主要負責構建使用這些組件的應用程序。當然，Rust 也可以用來開發 Wasm 應用程序，但 Deleuze 猜測 WasmGC 語言才是這類用例中的主導者。

WASI

所謂 WASI，簡言之就是在定義標準化系統接口（包括文件系統、時鐘、環境變量、命令行參數或者標準輸入 / 輸出）應該如何被公開給 Wasm 應用程序。機器學習、人工智能或者云存儲等其他用例也可以通過 WASI 進行標準化。

Kotlin/Wasm 目前還不支持 WASI，但開發團隊已經提供低級 API 實現。有趣的是，只需要提供 WASI 平臺中的特定部分，就能使用 Kotlin 的多平臺庫（例如 kotlinx-datetime 或 Okio）。

“ Kotlin/Wasm + WASI ”將并發出驚人的潛能：它可以提供 Kotlin/JVM 的替代方案，將應用程序部署到云端、邊緣甚至是 Serverless 函數的形式；也被大量用作容器鏡像的替代方案，能在幾微秒內完成實例化、提供更高的安全性且不依賴于任何特定硬件或操作系統。這樣的特性可能讓人想起 Java 在 1995 年提出的“一次編寫，隨處運行”（WORA）口號。

目前實現這一愿景的主要障礙在于，Wasmtime 等純 WASI 運行時還不支持 WasmGC。目前，運行 Kotlin/Wasm WASI 應用程序的主要途徑是利用 Node WASI 支持。

附：如何啟用 Kotlin/Wasm

要啟用 Kotlin/Wasm 并對其進行測試，請更新您的 build.gradle.kts 文件：

plugins {
    kotlin("multiplatform") version "1.8.20-Beta"
}


kotlin {
    wasm {
        binaries.executable()
        browser {
        }
    }
    sourceSets {
        val commonMain by getting
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test"))
            }
        }
        val wasmMain by getting
        val wasmTest by getting
    }
}