Wazero: The zero dependency WebAssembly runtime for Go developers

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SonarLint - Clean code begins in your IDE with SonarLint
  • Scout APM - Less time debugging, more time building
  • SaaSHub - Software Alternatives and Reviews
  • wazero

    wazero: the zero dependency WebAssembly runtime for Go developers

    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

  • wapc-go

    Golang-based WebAssembly Host Runtime for waPC-compliant modules

  • SonarLint

    Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.

  • perf-map-agent

    A java agent to generate method mappings to use with the linux `perf` tool

    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

  • linux

    Linux kernel source tree

  • karmem

    Karmem is a fast binary serialization format, faster than Google Flatbuffers and optimized for TinyGo and WASM.

    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

  • proposals

    Tracking WebAssembly proposals (by WebAssembly)

    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

  • meetings

    WebAssembly meetings (VC or in-person), agendas, and notes

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • gc

    Branch of the spec repo scoped to discussion of GC integration in WebAssembly

  • otto

    A JavaScript interpreter in Go (golang)

    > 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

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts