PEpeterhunt·Dec 21, 2022
I believe this is what WASI is https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
In WebAssembly: Docker Without Containersbytecodealliance
wasmtime
Rust2018–2026
bytecodealliance / wasmtime
wasmtime
A lightweight WebAssembly runtime that is fast, secure, and standards-compliant
92Distinct people
102Mentions
0Explicit recommenders
18.9KGitHub stars
What to know before exploring
What it is
A lightweight WebAssembly runtime that is fast, secure, and standards-compliant
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- wasmerio/wasmer · linked in 4 of the same discussions
- wasm-micro-runtime/wasm-micro-runtime · linked in 2 of the same discussions
- wasm3/wasm3 · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:56:55 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year102 dated mentions
Observed mentions: 2018-12-12 22:07:07 UTC to 2026-07-25 11:19:39 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 23 | 5 | 18 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 19 | 1 | 18 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 1 | 3 |
What Hacker News says
23 sourcesSupport on the server side is planned, still waiting for standardization https://github.com/bytecodealliance/wasmtime/issues/888
In WebAssembly: Docker Without ContainersThread on spectre and capability security (which I gather from a glance here that wasmtime is using on some level https://github.com/bytecodealliance/wasmtime/blob/main/docs/...):
https://groups.google.com/g/cap-talk/c/NSDM-05fEuU/
In Extism: Make all software programmable with WebAssemblyThis response is a mess, I apologize.
One can do lots of things. Yes all of those things are still issues, but in enumerating all the things as you have, you make a compelling argument not to use C++. If one picks something else like SML, Go or even Rust, it allows them to focus on those common areas of correctness and not also, all that other stuff.
I don't think you are apologizing for C++, but I hear this a lot, whatabout all the other parts that are fixed by a more sound system? My response is that we only have so many decisions we can make in the day, using a system that removes whole classes of problems allows me to focus on the non-accidental (forced) complexity.
> Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe
I never made that argument. But let's say I did. Given two systems, one ma
Read the rest
de in Rust and one made in C++. How do I audit the C++ code to ensure that it has the same level of safety as basically _anything_ else?
WasmEdge is using code coverage, good! https://app.codecov.io/gh/WasmEdge/WasmEdge
Only 80% coverage, not great.
I see mention of fuzzing being used, but I only get 69 hits in the codebase for "fuzz" and no documentation about how it actually works.
Wasmtime includes documentation on how to use their fuzzer, https://github.com/bytecodealliance/wasmtime/tree/main/fuzz
In my cursory look at the WasmEdge codebase I see
No application UBSan [1]
No application of control flow guard [2], either in the build or in the generated LLVM output.
Infact the only sanitization flags they are passing are -fsanitize=fuzzer,address
0 mentions of 'control flow' in the WasmEdge codebase, 65 mentions in Wasmtime. Although it doesn't appear that Wasmtime is itself being compiled with cfguard.
309 mention of spectre mitigations in Wasmtime, 1 link to a cloudflare blogpost in WasmEdge.
In my cursor look at Wasmtime, I see
Much better fuzzing support, 85 uses of unsafe in cranelift itself, 1400+ uses of unsafe in crates/*
The changelog and git messages for WasmEdge talk about type errors (those type errors look impossible in Rust), bus errors, out of bounds, etc.
It does not inspire confidence. C++ is already starting from behind. This software is targeted to be run on bare metal, embedded and widely distributed. It just doesn't have the level of detail around testing and correctness that I would expect for such a critical piece of infrastructure.
I am not saying that Wasmtime does not also have issues, that would be preposterous. But on the face of it, WasmEdge has a lot of work to do to catch up to where Wasmtime already is.
Wasmtime appears to care about the security properties of their dependencies with https://mozilla.github.io/cargo-vet/
It does not look like the WasmEdge project applies this basic list of practices as outlined by Jason Turner [n]
[1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
[2] https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html
[n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175
Yes, I guess?: Cranelift, which is a LLVM-like library written in Rust. This could be used for faster debug builds in the future.
There's a Rust backend using Cranelift [2].
If you mean addressing the poor quality of LLVM IR directly, then I don't know.
[1]: https://github.com/bytecodealliance/wasmtime/blob/main/crane...
[2]: https://github.com/bjorn3/rustc_codegen_cranelift
In How to speed up the Rust compiler in October 2022Isle: Instruction Selection/Lowering Expressions DSL
1 points · Open discussionIt is a runtime for wasm. Wasm is not executable in the same way an x86 binary is. It needs to run in a vm. Wasmtime is one such vm. In a browser context that vm is v8.
https://github.com/bytecodealliance/wasmtime
In mod_wasm: Run WebAssembly with ApacheWasmtime: A fast and secure runtime for WebAssembly
4 points · Open discussionNice job on the release…
But still no multithreading?
https://github.com/bytecodealliance/wasmtime/issues/888
It is strange to me to call it 1.0 without seamless threading support and while wasm & wasi still have standards to work out.
Multithreading is a basic operation in everything I build right now. It allows me to make a highly responsive UI while doing massive computations without any user experience impact. It lets me make services which can handle thousands of requests a second. And with Rust, this all comes ergonomically. At this point, I can’t think of a single solution I would implement without doing some form of this.
While I could treat a wasm application as a client server model (have one module for interfacing / managing, have X for processing where X is the number of available cores) then share memory between them, thi
Read the rest
s creates a lot of boilerplate and makes the code less ergonomic, and can drastically increase friction. I don’t want to have to hack threading into an application with so much manual setup, and I don’t like when a runtime forces architecturally decisions because it lacks a basic capability.
Anyway, congrats on the release. I will look forward to 2.0 of these runtimes.
I assumed that like most low-level runtimes it wouldn't be easy to just go and play with for fun, but the example is impressively simple: https://github.com/bytecodealliance/wasmtime#example
Maybe I'll take it for a spin
In Wasmtime 1.0Wasmtime: Standalone JIT-style runtime for WebAssembly, using Cranelift
1 points · Open discussionfor 1) WASI [0][1] makes it nicer and acts sort of like a FFI
for 2) there are reference types, which allow wasm to receive opaque objects similarly to how userland processes receive handles from the kernel. In this way you could pass an object to wasm and let it call host functions to modify it.
If you want to have the same datatype both in wasm and in the host you simply a compiler that supports it.
[0] https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
[1] https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
In Wasmer – Universal WebAssembly RuntimeCranelift is a general-purpose compiler like LLVM is, but its goals are different: it is targeted toward applications like JITs where faster compilation is important. It is intended to be a peer of browser JITs' optimizing tiers. In our README [0] we link some results where we're ~14% slower than LLVM but with ~10x faster compilation.
We also have an explicit focus on correctness, simplicity, and verification. One could argue that in practice LLVM is used everywhere and has dozens of active core contributors, that bugs and missed optimizations are shallow at that scale, and it's hard to compete with that; and there is some merit in that... but our codebase is two orders of magnitude smaller, and we're actively engaging with academics and designing things -- our lowering DSL, our regalloc's symbolic verifier, our fuzzing-first approach --
Read the rest
to get the most mileage we can out of our efforts. It seems to be working OK so far!
[0] https://github.com/bytecodealliance/wasmtime/blob/main/crane...
I haven't used it, but cranelift is also my first thought for this.
If you want a stable interface though, I might use wasm on top of it via wasmtime. I'm not sure how stable the API for wasmtime is, but at least the IR (wasm) is, and there's an ecosystem of tools around it.
https://github.com/bytecodealliance/wasmtime
In Ask HN: Recommendation for general purpose JIT compiler> Included in the repository is a PoC for running a plain wasi host (ie. no extra host functions except to support wasi system calls).
Looks like that’s not decided yet.
In theory you could use pod.spec.volumes to hand it over to the shim for the wasi preopens.[1]
Whether that’s a good idea is the other side of the story…
[1] https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
In Show HN: Run WASM in ContainerdShowing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.