一分钟读论文：《我们走了多远WebAssembly 运行时的全面特征研究》

这文章有点意思，支持一下。wasm 最大的用途，并不是网页开发，根本就打不过传统的 JS/TS 框架。而是利用规范化的虚拟机，把繁杂的业务代码统一起来运行。

业务代码随时会变，随时会改，那么 wasm 的解释器很有用。
业务代码需要高性能，那么 wasm 的 jit 很有用。
业务代码会用不同的语言编写，那么 wasm 编译器很有用。

总是 wasm 用的好，就是新一代写业务代码的杀手锏。

已经用起来了。
用在 Rust 插件上，选的 wasmtime = { version = "4.0", optiOnal= true}

@fengjianxinghun 好处是 wasm 插件可以用任意语言写，比如直接继续用 rust 写

一楼二楼说的都挺好的，拓展一下，WebAssembly 会是未来吗？

建议建一个 WebAssembly 节点

厉害的点在这里：
https://docs.docker.com/desktop/wasm/

wasm 的应用场景是在浏览器端与 js/ts 配合完成业务需求。

单拎出来目前来说目前没有太大意义(不管是是独立还是依托浏览器)。

近几年有好几次想用，研究以后的结论都差不多，wasm 社区心不齐很多波不同的人各搞各的，看不到未来

客户端性能优势完全错过窗口期 99%的场景性价比不如让千锤百炼的 JS 硬跑 JIT ；服务端 wasi 空有几个 runtime ，没几种语言支持实际写 wasi 模块，还和 AssemblyScript 闹掰了

希望干脆点客户端服务端分家算了，各玩各的可能反而发展迭代更快，客户端研究研究 app 之类的场景能不能拓展，想办法和 js/ts 互操作性更强一些；服务端看看 wasi 到底行不行，早点达成一致，不行赶紧来个替代者，后面 gc 什么的早点弄出来，语言（真正意义上）多支持几种，Docker ，IOT 这些场景落地落好

@mcfog 之前看了个论文写了 IoT 的应用场景，效果很好，我有时间下次分享个，欢迎关注。

标准进度缓慢，社区分裂严重。wasi 还有很长的路要走。

@mcfog GC 是不可能的，读过 wasm 标准就知道，wasm 连数据类型尚且都只有 3 种（ number 、ref 、vector ），连没有原生 string 都没有，更别说什么 gc 了，wasm 的定位并不是 VM ，而是跨平台的汇编语言。

实际上 wasm 和 wasi 从显示角度上来说我认为分家还是比较彻底的，不然 as 也不会和 wasi 决裂，wasi 程序是很难跑在 wasm 环境下的，反之也是如此。

语言层面上面也说了，wasm/wasi 的定位并不是 VM ，所以我认为对于多语言的支持分为解释型语言（ Python 、php 等）和基于 VM 的编译型语言（ Java ）。

对于前者解释型语言很好处理，只要把解释器编译成 wasm 或 wasi 即可，例如 RustPython 做的就很好，CPython 也有了进展，但还是实验性的。

但对于 Java 这种语言来说，本身把 Java 编译成 wasi 是没有意义的，因为 Java 本身的定位就是 write once run everywhere ，Java 虽然也能支持 AOT 编译，但是 Java 框架大量使用反射，并且在 Java 生态这么做的人实在是太少了，所以我认为把 Java 编译成 wasi 现实是不行的，但如果把 JVM 编译到 wasi 又太过于愚蠢。

C#和 Java 类似，官方具有本身有.NET Native 特性，而且微软积极拥抱 WASM ，Blazor 使用了大量的 WASM ，我还没有太深入研究，我觉得未来肯定是可以编译到 WASI 的。

所以现在 wasi 生态可以用语言：C/C++、Python （ RustPython ）、Rust 、Go （ TinyGo ），我认为还是有一定选择的余地的。