WASMan: 基于纯 Go 的 WebAssembly 引擎

[c0mm4nd]

WASMan （ WebAssembly Manager ）简单来说就是个基于纯 golang 的 wasm(v1) binary 解释器。

制作原因

迫于先技术选型了 go，又迫于 wasmtime-go 内存（ bytes ）操作不友好，wasmer-go 不支持 win，wagon 停止维护且使用手感不咋样，gasm 往 gojs 方向跑远了，且个人需要类似 eth 的 gas cost 等非主流设计。

制作过程

作为菜鸡，先是试图加入 wasmtime 结果被 memory 绕的一脸懵逼，又把时间都浪费在 docstring 和 bazel support 上了，结果发现加非主流设计改动太大。

然后自己开始制作，边翻译 wasm 的 spec 边参考 wagon，gasm，wasmtime-go，wasmer-go 慢慢写了一个月。

因为初始是从 gasm 改的所以 license 也保留了原作者。

现状

当前 WASMan 基本上算是w3c的最简化可实行产品，此外添加了类似 gas cost 的 toll-station 和与 host 之间的 string 交互方案（这也是基本上每个同类产品 issue 里的常客，然而基本上没人清楚告知 issue author 该怎么做，只说参数只能 i32/64 f32/64 ）。

当前的运行速度正常来说应该是不如 wasmtime 、wasmer 的，基本上 go 的都没法和 rust 打，况且人家还 JIT 优化。

TODO

当前还在增加新的 features，例如 validator 和标准 wasi 。

因为这些我暂时用处不大所以动力不是很足……

最后链接 https://github.com/c0mm4nd/wasman

[missdeer]

其实现在比较想要一个 framework

[c0mm4nd]

@missdeer

面向 web 的 wasm framework 其实挺多的，尤其是 rust 上的。

其实 wasm 本身就是你把编译目标调整到 wasm32 之后只要语言支持就能直接编译，框架什么的就一些常用操作的 wrapper 。

https://www.reddit.com/r/golang/comments/ddyja9/canonical_go_wasm_framework_blazor_for_go/

原生 go 上因为现在是靠个写死的 wasm_exec.js 所以基本上可以认为是顶多就能用……基本上只要引入第三方包就肯定需要像 tidb 那样排雷

https://pingcap.com/blog-cn/tidb-wasm-introduction/

不过个人更喜欢面向 server 的……老实交代就是拿来当智能合约引擎，所以也就和这些 framework 反着跑了……

[charten]

方向错了吧？ webassembly 要的不是解释器，而是编译器呀，把它那串 wasm 字节码编译成目标机器码，然后直接跑机器码速度才上去的呀。相当于 js 在 v8 内 jit 的水平，v8 的 jit 也是对于固定类型频繁执行的函数，从解释执行变为编译后跑机器码执行，速度才上去的。

[DoctorCat]

@charten 兄弟说得有道理。不过我想人家只是造轮子玩玩技术而已，没啥现实业务企图

[c0mm4nd]

@charten 的确是这样的。

但是如果追求速度那还是应该去怀抱 rust （ wagon 就做编译做到弃疗了），用 wasmtime-go 和 wasmer-go 也是很香的。

wasmer-go 和 wagon 速度和是一个天一个地。

https://github.com/wasmerio/wasmer-go#benchmarks

纯 go 这边需要做到的只是最基础的可运行和 go 环境中易适配易魔改（就那一大堆 proposal，还有像 ewasm，cosmwasm 这种第三方针对智能合约引擎方向的魔改）。

当然也因为我菜写不动……

@DoctorCat 是有需求才撸的……不然也不会做那么多~市场~issue 研究……