WebAssembly：权威指南

第 17 章 WebAssembly 和语言 WebAssembly 和其他语言

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

如果你用一个人听得懂的语言与他交谈，那会深入他的内心。如果你用他自己的语言与他交谈，那会深入他的内心。

纳尔逊-曼德拉

我们的故事即将结束，至少现在是这样。我们已经看到了 WebAssembly 在使用案例、语言和平台集成、托管环境等方面的广泛应用。要想在这个令人兴奋的新平台上提高工作效率，开发人员需要做出很多选择。一些语言及其相关运行时与 WebAssembly 配合得很好，而另一些则不然，这其中也有具体的原因。缺乏垃圾回收和良好的线程支持是自 MVP 诞生之初就存在的障碍之一，但这两个问题正在逐步得到解决。

正如我们在第 12 章中所看到的，这些限制和其他限制已经得到了很好的理解，并且越来越多地出现在各种主机和运行环境中。未来的前景是光明的，开发人员可能会使用的任何语言都会得到更广泛的支持。所以，如果你喜欢的语言还没有得到支持，请打起精神来，我相信用不了多久就会得到支持。

尽管如此，我们将在本章中讨论许多其他流行语言，甚至是新兴但仍略显小众的语言，它们也有一些渐进的努力、部分的解决方案和正在进行中的工作。我并不是说这些都可以取代那些支持较好的语言，但也许它们的出现会让我们看到一个更加光明的多语言 WebAssembly 的未来。正如曼德拉在开篇语录中所说，我们可以理解多种语言，但我们喜欢使用自己的语言。

TinyGo

正如我在第 10 章中提到的，，我最初是被 Go 作为系统语言来取代 C 和 C++ 所吸引的，因为它的语法简洁、与 Unix 和 Plan 9 的联系，以及 Rob Pike 和 Ken Thompson 的参与。当它在支持 WebAssembly 方面落后于 Rust 时，我的注意力就减弱了，但我一直期待着缩小差距的那一天。虽然我们还没有做到这一点，但由于一个名为TinyGo 的新变种，我们离目标越来越近了。这个项目并不是专门针对 WebAssembly 的，但它基于基于 LLVM 基础架构构建的新 Go 编译器，开放了 WebAssembly 作为后端。

从TinyGo 常见问题解答中，我们可以看到它是一个基于标准库（因此具有可移植性，并得到 Emscripten 和 wasi-sdk 等各种 WebAssembly 工具的良好支持）和 LLVM 的可重用优化支持的解析器。除此以外，常见问题还指出它还包括编译器本征（协助优化的规则）、内存分配器、调度程序、重新实现的常用包以及对字符串操作的支持。

TinyGo 的 "Tiny "部分是希望针对传统 Go 编译器不支持的微控制器。如果没有 LLVM 的分层架构，在后端添加这种支持对许多开发者来说都是得不偿失的麻烦事。LLVM 改变了工作量，因此带来了各种新的可能性。普通 Go 工具链的另一个问题是，它产生的二进制文件较大，也不适合嵌入式系统和微控制器。解决这些问题的组合恰好能很好地支持 Go 到 WebAssembly 的路径，这条路径很可能会继续结出硕果，并让 Go 可以以这种方式使用。

鉴于 Rust 和 Go 在很多人的脑海中属于同一个空间，而且 Rust 也有意利用其基于 LLVM 的工具链瞄准嵌入式系统，因此常见问题继续将 Go 作为一种选择，因为它的学习曲线确实较浅。此外，它还通过 goroutines 和通道支持独立于线程实现的并发性，并拥有丰富的标准库。在 Rust ...