commit/2b36157ed81d2286a15c2d040b2fee736fe5df0d

哪些现成的Crate可以与WebAssembly工作?

最简单的是列出目前不能与WebAssembly工作的东西; 避免这些东西的crates往往是可以移植到WebAssembly并且通常恰好能运行。 一个好的经验法则是,如果一个库支持嵌入式的或者是#![no_std]用法,它可能也支持WebAssembly。

一个Crate可能无法与WebAssembly一起使用的内容

C和系统库依赖

wasm中没有系统库,所以任何试图绑定到一个系统库的crate都不能工作。

使用C库也可能会无法工作,因为wasm没有一个稳定的跨语言通讯ABI,并且跨语言连接对于wasm非常挑剔。 每个人都希望这最终能狗生效,特别是因为clang现在默认发布他们的wasm32目标,但是故事还不是很完整。

文件I/O

WebAssembly不能访问文件系统,所以假设文件系统存在—并且没有针对wasm的解决方案—的crate将不能工作。

产生线程

有计划为WebAssembly添加线程,但是他还没有完成。 试图在wasm32-unknown-unknown目标上启动一个线程会导致错误,这将触发一个wasm陷阱。

那么哪些通用Crates倾向于使用WebAssembly现成的工作?

算法和数据结构

提供特定算法实现或者是 数据结构的crate, 例如A*图搜索或者伸展树就能于WebAssembly很好的工作。

#![no_std]

不依赖于标准库的crate能与WebAssembly很好工作。

解析器

机械其 — 只要他们只是获取输入而不自己执行他们的I/O—就能与WebAssembly很好的工作。 well with WebAssembly.

文本处理

处理以文字方式表达的复杂人类语言的crate 能够很好的与WebAssembly工作。

Rust Patterns

针对Rust中编程特定情况的共享解决方案能够与WebAssembly很好工作。

results matching ""

    No results matching ""