wolfi-os
extism
wolfi-os | extism | |
---|---|---|
2 | 49 | |
182 | 3,922 | |
- | 4.2% | |
10.0 | 9.0 | |
over 1 year ago | 3 days ago | |
Makefile | Rust | |
GNU General Public License v3.0 or later | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wolfi-os
-
Newsletter #1 - 9st January 2023
https://github.com/chainguard-dev/wolfi-os https://www.chainguard.dev/unchained/introducing-wolfi-the-first-linux-un-distro
- Wolfi
extism
-
'WebAssembly Is Finally Usable, Almost'
No one is saying anyone should stop exploring new paths. I don't know what you personally are bringing to the table as far as adding to the ambition, so excuse my naivety.
The issue is that there is a misrepresentation by the Bytecode Alliance about WASI, from where it began, to where it is now. And a lot of this has been poorly communicated or not done at all. Which has only left many of us to think that they are trying to pull a fast one over the community to forcefully bring everyone along into Components when that is not desirable.
> Wasm has not allowed actual inter-language operation at any serious scale.
This is untrue, and you may just be unaware of efforts like Extism [0]. While it is intentionally not a binding generator, it does make it very easy to blend languages meaningfully. Disclaimer, I work on Extism and therefore have some bias :) We have different goals than the Component Model, so if you actually want what the component model offers, you should use it!
I believe the easy solution here is to:
1. stop referring to WASI 0.1 as "legacy", implying some obsolete status, or call 0.1 something entirely different. Let it continue to be an easily targetable interface to bridge to the rest of today's software.
2. move WASI and Component Model code repositories out of the WebAssembly github org.
This would clarify the distinction between WebAssembly (the standard) and WASI 0.2 / WIT / CM as a project by Bytecode Alliance. They are not the same, and while the Bytecode Alliance works on making things usable and ready, it doesn't cause harm or confusion for WebAssembly users.
[0]: https://github.com/extism/extism
-
Building a dynamic lib plugin system for Rust
I'm looking forward to use: https://github.com/extism/extism
- Extism: Cross-language framework for building with WebAssembly
- Extism – make all software programmable. Extend from within
-
Faces.js, a JavaScript library for generating vector-based cartoon faces
Extism can be really useful for packaging up and running cross-language libraries!
The most clear information about it is at: https://extism.org, but its a bit focused on the primary use case for Extism, being a universal plugin system.
There is a C PDK (https://github.com/extism/c-pdk) which you'd probably want to use in a new wrapper around your library in C++, and compile it to wasm32 freestanding or WASI, but without emscripten. Extism doesn't currently have an interop layer to emscripten.
-
Show HN: Now my pet programming language can run in the browser
It may just be my own unique obsession to peek at the internals of .wasm, but if anyone else is curious:
https://modsurfer.dylibso.com/module?hash=ab6f4b2de9db171347...
u/nbittich - curious if you've tried to use your language as as a scripting language inside other apps? I took a peak at your browser wasm environment, and think we could hook up the `compute` entrypoint you have here[0], but I'm not certain what the `ctx` does without going super deep, and if it could be passed into an Extism function[1] (which is how I'd try to run it from within 16+ other languages).
[0]: https://github.com/nbittich/adana/blob/master/adana-script-w...
[1]: https://github.com/extism/extism
-
WebAssembly Playground
Yep, this is one of the initial motivations for creating Extism: https://github.com/extism/extism -- and it works across 16 host languages & 8 guest languages.
-
WASI 0.2.0 and Why It Matters
On the devx, there's definitely some rough edges around building and using Wasm. My company has been working on a framework to ease integrating Wasm into existing applications. One area it focuses on is providing easy data passing between the host program and the Wasm and vice versa. https://github.com/extism/extism We do not have WASI preview 2 support yet, but are interested in integrating it.
- Extism, the universal WASM framework, reaches 1.0
What are some alternatives?
cnspec - An open source, cloud-native security to protect everything from build to runtime
wit-bindgen - A language binding generator for WebAssembly interface types
cnquery - open source, cloud-native, graph-based asset inventory
WASI - WebAssembly System Interface
wasmer - 🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten
wasmtime - A fast and secure runtime for WebAssembly
jssc - Java library for talking to serial ports (with added build support for maven, cmake, MSVC)
nodejs-snowflake - Generate time sortable 64 bits unique ids for distributed systems (inspired from twitter snowflake)
rusty-hermit - Hermit for Rust. [Moved to: https://github.com/hermit-os/hermit-rs]
mun - Source code for the Mun language and runtime.
wasmi - WebAssembly (Wasm) interpreter.
reference-types - Proposal for adding basic reference types (anyref)