Cargo-component Alternatives
Similar projects and alternatives to cargo-component
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
extism
The framework for building with WebAssembly (wasm). Easily load wasm modules, move data, call functions, and build extensible apps.
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
-
wasm-by-example
Wasm By Example is a website with a set of hands-on introduction examples and tutorials for WebAssembly (Wasm)
-
scale
A framework for building high-performance plugin systems into any application, powered by WebAssembly.
-
-
-
-
cxx-wasm-freestanding
example of a c++ -> wasm build that doesn't use emscripten or any standard library
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
cargo-component reviews and mentions
-
WASM by Example
well, for starters, wasm is sandboxed. So, if a wasm library needs an import (eg: read/write filesystem), it has to be explicitly provided. It cannot do anything except math by default. This allows host a high amount of control.
different wasm libraries can have separate memories. So, if a library X depends on a jpeg decoder library, the host has to provide that as import. The jpeg decoder library might export a fn called "decode" which takes an array of bytes of a jpeg, and returns an Image struct with rgba pixels. This allows the "memory" of the two libraries to be separate. the jpeg decoder cannot "write" to the X's memory, cleanly separating the two of them.
Wasm component model recognizes higher level objects called resources, which can be shared between libraries (components). This allows X to simply pass a file descriptor to jpeg decode fn, and the sandbox model makes sure that jpeg library can read from that file only and the rest of the filesystem is still offlimits. wasm is already getting support for garbage collector. So, a high level language can just rely on wasm's GC and avoid shipping its entire runtime. Or the host can guarantee that all the imports a language needs will be provided, so that the language libraries can shed as much runtime weight as possible.
Finally, Component model is designed from ground up to be modular, which allows imports/exports/namespaces and other such modern features. C.. well, only has headers and usually brings a lot of backwards compatibility baggage. The tooling (eg: wit-bindgen) will provide higher level support like generating code for different language bindings by taking a wit (header for wasm) declaration file. If you are familiar with rust, then https://github.com/bytecodealliance/cargo-component#getting-... shows how easy it is to safely create (or bind to) wasm bindings
-
Using WASM for a plugin system in Rust? (generate code at runtime and then hot reloading it as a library)
Yes, wasm_bindgen is js only. At least for now, in future I would also expect it to migrate to component model. There is also cargo-component which is a way to create modules compatible with component model. You define your module interface in WIT and your dependencies on other wasm modules in the similar way you would define crate dependencies. Alternately there is wit-bindgen that is a codegen tool for multiple languages that also accepts WIT as input.
Stats
bytecodealliance/cargo-component is an open source project licensed under Apache License 2.0 which is an OSI approved license.
The primary programming language of cargo-component is Rust.
Popular Comparisons
Sponsored