-
-
-
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.
-
-
karmem
Karmem is a fast binary serialization format, faster than Google Flatbuffers and optimized for TinyGo and WASM.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I'm a maintainer on wazero. We have two things in progress on debugability, though both are stalled as we complete the recently announced WebAssembly 2.0 draft spec (nearly done) [1].
1. DWARF support - this requires those compiling to Wasm to configure to emit that. It is also murky because there's no canonical mapping in Wasm (most rely on LLVM underneath, but wazero is zero dependencies so we can't do that). Anyway, this is still on the table. [2]
2. Observability hooks - wazero is uniquely go-native which means we can do things like context propagation, allowing telemetry hooks including distributed tracing. While it may not seem intuitive to use that in Wasm, it can allow you to re-use tools that can show a trace graph. We have an experimental listener now, which has an example of how to make some strace looking logs. [3] Later, we'll convert this to an interceptor approach so that you can do metrics and stuff nicer. [4]
Regardless of this, debugging is easier because everything is in go. Apart from the DWARF thing which is totally important, the runtime being in Go completely means you debug everything going on, down to what is allocating memory, just by putting break-points in Go code. This is a very neat thing, and has helped some folks develop better code. Ex. https://github.com/inkeliz/karmem
Hope these help. Indeed the road to wasm is littered with a lot of runtimes, mostly abandoned or archived. We're hoping to buck the trend debugability, so watch the issues below if interested, and feel free to tell us anything we aren't doing right, too.
[1]: https://github.com/tetratelabs/wazero/issues/484
I don't know enough about wasm runtimes, but for example JIT runtimes like nodejs (or JVM via perf-map-agent [0]) allow writing out debug infos via the Linux Kernel JIT-Interface [1], which debuggers and profilers can then pick up to symbolize stack traces.
[0] https://github.com/jvm-profiling-tools/perf-map-agent
I'm a maintainer on wazero. We have two things in progress on debugability, though both are stalled as we complete the recently announced WebAssembly 2.0 draft spec (nearly done) [1].
1. DWARF support - this requires those compiling to Wasm to configure to emit that. It is also murky because there's no canonical mapping in Wasm (most rely on LLVM underneath, but wazero is zero dependencies so we can't do that). Anyway, this is still on the table. [2]
2. Observability hooks - wazero is uniquely go-native which means we can do things like context propagation, allowing telemetry hooks including distributed tracing. While it may not seem intuitive to use that in Wasm, it can allow you to re-use tools that can show a trace graph. We have an experimental listener now, which has an example of how to make some strace looking logs. [3] Later, we'll convert this to an interceptor approach so that you can do metrics and stuff nicer. [4]
Regardless of this, debugging is easier because everything is in go. Apart from the DWARF thing which is totally important, the runtime being in Go completely means you debug everything going on, down to what is allocating memory, just by putting break-points in Go code. This is a very neat thing, and has helped some folks develop better code. Ex. https://github.com/inkeliz/karmem
Hope these help. Indeed the road to wasm is littered with a lot of runtimes, mostly abandoned or archived. We're hoping to buck the trend debugability, so watch the issues below if interested, and feel free to tell us anything we aren't doing right, too.
[1]: https://github.com/tetratelabs/wazero/issues/484
There's a proposals repo [1] that tracks the status of features like GC. According to that, GC is phase 2, which is prototyping [2]. To get to the finish line, implementations including at least 2 browsers need to happen (this is a Web standard, so there's some browser bias in the process). It is not straight forward to see who and what are implementing a proposal, especially if not tracked in the roadmap [3]. Best advice I could give for now is to watch the proposal repo [4], or just wait. It may be a while on this one.
[1]: https://github.com/WebAssembly/proposals
[2]: https://github.com/WebAssembly/meetings/blob/main/process/ph...
> why host other languages
Here's an example:
I recently finished building https://subzo.com.au which allows customizing and ordering 3D models. The way the model's cost, volume and other attributes are calculated needs to be done both on the frontend (for speed) and on the backend (to validate). Backend is in Go and we can't practically run Go in the browser. So instead, I wrote the calculation snippets in JavaScript (which runs natively in the browser) and ran them on the backend on a JavaScript VM library written in Go [1].
[1]: https://github.com/robertkrimen/otto