We made a tool to Hacker News Posts with ChatGPT. You can customize which topic you're concerned about, then ask ChatGPT to give you a TLDR of the posts. Welcome to give it a try!
Hmm, we allow the CLI to execute AOT code sections embedded in WASM files as a convenience feature -- you can do AOT compilation and then execute it on your CLI.
For server side deployment, you should always do the AOT compilation on the server. But I agree this could be more clear. We are adding a new CLI option to disable AOT code segment in the WASM file for people who do not wish to perform the separate AOT compilation step.
* Lightweight (no GC, under 2MB)
* Designed to be a secure sandbox (not just a language runtime)
* Modular (add host functions as needed — eg support for Tensorflow)
* Multiple languages (esp compiled languages like Rust)
* Works with container tools (Docker, k8s etc)
Personally, I believe v8 is and always will be primarily focused on the browser use case. It’s support for wasi, container tooling will always take a back seat compared with priorities in the browser.
Today, there are a large set of Rust apps that can run in WasmEdge, wasmtime, Fermyon spin, wasmCloud etc, but would not run on v8’s embedded Wasm engine …
One of the benefits of running JS in Wasm (specifically the QuickJS approach) is that you can create JS APIs in Rust. That allows you to move a lot of compute intensive operations into Rust while still giving your developers a clean and nice JS API. WasmEdge does this with its JS Tensorflow API:
One of the challenges is that Wasm supports multiple languages. So, we will have to decide to start from a Rust app or a JS app or something else. Would love your suggestions.
Disclaimer: I am a maintainer of WasmEdge. WASI-NN allows Wasm to be a wrapper of native tensor frameworks — very much the same way Python is a wrapper for Tensorflow and PyTorch.
The benefit of using Wasm as a wrapper is its high performance (Use Rust to prepare data) and multi language support (inference in JS!)
WasmEdge supports Tensorflow, PyTorch, and OpenVINO as wasi-NN backends.
I am a maintainer of the WasmEdge project. Yes, it is written in C++ for two reasons:
1 C++ apps can run a lot of edge hardware devices and OSes. We are running on RTOS like seL4 and CPUs like RISC-V.
2 There are already two leading Wasm runtimes written in Rust when we started. We thought runtime diversity is important from security and reliability point of view.
It is indeed more challenging to run C++ programs securely. We are participating Google’s OSS-fuzz program.
Of course, for application developers, WasmEdge provides “Rust first” SDKs and APIs. Almost all of our new features are available in the Rust SDK first. :)
I am a maintainer at WasmEdge. :) The name “edge” signifies that it is lightweight. We think it is a lightweight and secure alternative to Linux containers.
The application use cases include containerization on edge devices, serverless functions on edge cloud, embedded functions for databases or SaaS, stream functions for data pipelines, or even smart contracts for blockchains.
All of the above are “edge” use cases in the sense that they are typically outside of mega data centers. :)
> the unification of Docker and Wasm containers will happen at the orchestration layer.
In fact, it happens now. The integration with WasmEdge and K8s toolings has been done. Developers could use crun, CRI-O, containerd, KubeEdge, KIND, OpenYurt and K8s to start, manage, and orchestrate WasmEdge Apps. See more here: https://wasmedge.org/book/en/kubernetes.html
WebAssembly will run side by side with Docker using the same orchestration tools.
he WasmEdge Runtime (formerly SSVM) is a lightweight and high-performance WebAssembly (WASM) VM optimized for edge computing. It is widely used in scenarios ranging from cloud serverless functions, SaaS, blockchain smart contracts, IoT, to automotive real time applications.
Yes. Because WebAssembly provides a higher level of abstraction (safety, isolation, portability, manageability etc — you know, the “enterprise” stuff) over native code. See here: https://www.secondstate.io/articles/why-webassembly-server/
We took that experts at IBM and MIT would be honest about their performance findings. :) But, it appears that actual performance numbers are of great interest to the community. We will create repeatable benchmarks and open source them. Stay tuned!