wazero: the zero dependency WebAssembly runtime for Go developers

Overview

wazero: the zero dependency WebAssembly runtime for Go developers

WebAssembly Core Specification Test Go Reference License

WebAssembly is a way to safely run code compiled in other languages. Runtimes execute WebAssembly Modules (Wasm), which are most often binaries with a .wasm extension.

wazero is a WebAssembly 1.0 spec compliant runtime written in Go. It has zero dependencies, and doesn't rely on CGO. This means you can run applications in other languages and still keep cross compilation.

Import wazero and extend your Go application with code written in any language!

Example

The best way to learn wazero is by trying one of our examples.

For the impatient, here's how invoking a factorial function looks in wazero:

func main() {
	// Choose the context to use for function calls.
	ctx := context.Background()

	// Read a WebAssembly binary containing an exported "fac" function.
	// * Ex. (func (export "fac") (param i64) (result i64) ...
	source, err := os.ReadFile("./path/to/fac.wasm")
	if err != nil {
		log.Panicln(err)
	}

	// Create a new WebAssembly Runtime.
	r := wazero.NewRuntime()
	defer r.Close(ctx) // This closes everything this Runtime created.

	// Instantiate the module and return its exported functions
	module, err := r.InstantiateModuleFromCode(ctx, source)
	if err != nil {
		log.Panicln(err)
	}

	// Discover 7! is 5040
	fmt.Println(module.ExportedFunction("fac").Call(ctx, 7))
}

Note: fac.wasm was compiled from fac.wat, in the WebAssembly 1.0 Text Format, it could have been written in another language that compiles to (targets) WebAssembly, such as AssemblyScript, C, C++, Rust, TinyGo or Zig.

Deeper dive

The former example is a pure function. While a good start, you probably are wondering how to do something more realistic, like read a file. WebAssembly Modules (Wasm) are sandboxed similar to containers. They can't read anything on your machine unless you explicitly allow it.

The WebAssembly Core Specification is a standard, governed by W3C process, but it has no scope to specify how system resources like files are accessed. Instead, WebAssembly defines "host functions" and the signatures they can use. In wazero, "host functions" are written in Go, and let you do anything including access files. The main constraint is that WebAssembly only allows numeric types.

For example, you can grant WebAssembly code access to your console by exporting a function written in Go. The below function can be imported into standard WebAssembly as the module "env" and the function name "log_i32".

_, err := r.NewModuleBuilder("env").
	ExportFunction("log_i32", func(v uint32) {
		fmt.Println("log_i32 >>", v)
	}).
	Instantiate(ctx)
if err != nil {
    log.Panicln(err)
}

The WebAssembly community has subgroups which maintain work that may not result in a Web Standard. One such group is the WebAssembly System Interface (WASI), which defines functions similar to Go's x/sys/unix.

The wasi_snapshot_preview1 tag of WASI is widely implemented, so wazero bundles an implementation. That way, you don't have to write these functions.

For example, here's how you can allow WebAssembly modules to read "/work/home/a.txt" as "/a.txt" or "./a.txt":

_, err := wasi.InstantiateSnapshotPreview1(ctx, r)
if err != nil {
    log.Panicln(err)
}

config := wazero.NewModuleConfig().WithFS(os.DirFS("/work/home"))
module, err := r.InstantiateModule(ctx, compiled, config)
...

While we hope this deeper dive was useful, we also provide examples to elaborate each point. Please try these before raising usage questions as they may answer them for you!

Runtime

There are two runtime configurations supported in wazero: Compiler is default:

If you don't choose, ex wazero.NewRuntime(), Compiler is used if supported. You can also force the interpreter like so:

r := wazero.NewRuntimeWithConfig(wazero.NewRuntimeConfigInterpreter())

Interpreter

Interpreter is a naive interpreter-based implementation of Wasm virtual machine. Its implementation doesn't have any platform (GOARCH, GOOS) specific code, therefore interpreter can be used for any compilation target available for Go (such as riscv64).

Compiler

Compiler compiles WebAssembly modules into machine code ahead of time (AOT), during Runtime.CompileModule. This means your WebAssembly functions execute natively at runtime. Compiler is faster than Interpreter, often by order of magnitude (10x) or more. This is done while still having no host-specific dependencies.

If interested, check out the RATIONALE.md and help us optimize further!

Conformance

Both runtimes pass WebAssembly 1.0 spectests on supported platforms:

Runtime Usage amd64 arm64 others
Interpreter wazero.NewRuntimeConfigInterpreter()
Compiler wazero.NewRuntimeConfigCompiler()

Support Policy

The below support policy focuses on compatability concerns of those embedding wazero into their Go applications.

wazero

wazero is an early project, so APIs are subject to change until version 1.0.

We expect wazero 1.0 to be at or before Q3 2022, so please practice the current APIs to ensure they work for you!

Go

wazero has no dependencies except Go, so the only source of conflict in your project's use of wazero is the Go version.

To simplify our support policy, we adopt Go's Release Policy (two versions).

This means wazero will remain compilable and tested on the version prior to the latest release of Go.

For example, once Go 1.29 is released, wazero may use a Go 1.28 feature.

Platform

wazero has two runtime modes: Interpreter and Compiler. The only supported operating systems are ones we test, but that doesn't necessarily mean other operating system versions won't work.

We currently test Linux (Ubuntu and scratch), MacOS and Windows as packaged by GitHub Actions.

  • Interpreter
    • Linux is tested on amd64 (native) as well arm64 and riscv64 via emulation.
    • MacOS and Windows are only tested on amd64.
  • Compiler
    • Linux is tested on amd64 (native) as well arm64 via emulation.
    • MacOS and Windows are only tested on amd64.

wazero has no dependencies and doesn't require CGO. This means it can also be embedded in an application that doesn't use an operating system. This is a main differentiator between wazero and alternatives.

We verify zero dependencies by running tests in Docker's scratch image. This approach ensures compatibility with any parent image.


wazero is a registered trademark of Tetrate.io, Inc. in the United States and/or other countries

Issues
  • JIT: Exception 0xc0000005 0x8 0x0 0x0

    JIT: Exception 0xc0000005 0x8 0x0 0x0

    I'm testing some code with Wazero, and I notice one odd crash, that I'm not sure if it's either my code (which is Zig) or Wazero. That is strange from previous errors, because it's one "Exception 0xc0000005 0x8 0x0 0x0". It's not an panic or something from testing.Error(err).

    I'm using Windows/amd64.


    The log is:

     go test -tags wasi,km,zig -v -bench=. -benchmem -benchtime=5s -cpu 1
    === RUN   TestEncodeObjectAPI
    Exception 0xc0000005 0x8 0x0 0x0                                                                                                                                              
    PC=0x0                                                                                                                                                                        
                                                                                                                                                                                  
    github.com/tetratelabs/wazero/internal/wasm/jit.(*callEngine).execWasmFunction(0xc00074a240, {0x5dd008, 0xc00009e140}, 0xc000952e70, 0xc000952cf0)                            
            Z:/GOPATH/pkg/mod/github.com/tetratelabs/[email protected]/internal/wasm/jit/engine.go:699 +0x185 fp=0xc00095dbb8 sp=0xc00095dae0 pc=0x4d5305 
    github.com/tetratelabs/wazero/internal/wasm/jit.(*moduleEngine).Call(0xc000954030?, {0x5dd008, 0xc00009e140}, 0xc000952e70, 0xc000494dd0, {0xc000954030, 0x1, 0x1})           
            Z:/GOPATH/pkg/mod/github.com/tetratelabs/[email protected]/internal/wasm/jit/engine.go:582 +0x48f fp=0xc00095dcb8 sp=0xc00095dbb8 pc=0x4d4b2f 
    github.com/tetratelabs/wazero/internal/wasm.(*FunctionInstance).Call(0x53bca0?, {0x5dd008?, 0xc00009e140?}, {0xc000954030?, 0xc000022270?, 0x0?})                             
            Z:/GOPATH/pkg/mod/github.com/tetratelabs/[email protected]/internal/wasm/call_context.go:164 +0x63 fp=0xc00095dd08 sp=0xc00095dcb8 pc=0x4901c3
    benchmark%2ekarmem%2eorg.(*Wasm).Run(...)
            X:/karmem/benchmark/main_wasi_test.go:289
    benchmark%2ekarmem%2eorg.TestEncodeObjectAPI(0xc000061040)
            X:/karmem/benchmark/main_wasi_test.go:113 +0x1f6 fp=0xc00095df70 sp=0xc00095dd08 pc=0x50d556
    testing.tRunner(0xc000061040, 0x58dce8)
            C:/Program Files/Go/src/testing/testing.go:1439 +0x102 fp=0xc00095dfc0 sp=0xc00095df70 pc=0x3e3482
    testing.(*T).Run.func1()
            C:/Program Files/Go/src/testing/testing.go:1486 +0x2a fp=0xc00095dfe0 sp=0xc00095dfc0 pc=0x3e432a
    runtime.goexit()
            C:/Program Files/Go/src/runtime/asm_amd64.s:1571 +0x1 fp=0xc00095dfe8 sp=0xc00095dfe0 pc=0x3587a1
    created by testing.(*T).Run
            C:/Program Files/Go/src/testing/testing.go:1486 +0x35f
    
    goroutine 1 [chan receive]:
    testing.(*T).Run(0xc000060ea0, {0x57e4e0?, 0x35af53?}, 0x58dce8)
            C:/Program Files/Go/src/testing/testing.go:1487 +0x37a
    testing.runTests.func1(0xc000020090?)
            C:/Program Files/Go/src/testing/testing.go:1839 +0x6e
    testing.tRunner(0xc000060ea0, 0xc0000c3cd8)
            C:/Program Files/Go/src/testing/testing.go:1439 +0x102
    testing.runTests(0xc000094320?, {0x72cd40, 0x1, 0x1}, {0x26848cc0598?, 0x40?, 0x738f20?})
            C:/Program Files/Go/src/testing/testing.go:1837 +0x457
    testing.(*M).Run(0xc000094320)
            C:/Program Files/Go/src/testing/testing.go:1719 +0x5d9
    main.main()
            _testmain.go:57 +0x1aa
    rax     0x20
    rbx     0x110000
    rcx     0xc000494270
    rdi     0x1100000012
    rsi     0xc0002de820
    rbp     0xc00095dba8
    rsp     0xc00095dad8
    r8      0x23280
    r9      0x8
    r10     0x90
    r11     0x0
    r14     0xc000966600
    r15     0xc004a90000
    rip     0x0
    rflags  0x10202
    cs      0x33
    fs      0x53
    gs      0x2b
    exit status 2
    

    That issue is ONLY affecst JIT, so I think it's an Wazero issue. The biggest issue is that it crashes the entire program and it's not possible to recover.

    Change:

    wazero.NewRuntimeConfigJIT().WithFinishedFeatures()
    

    To:

    wazero.NewRuntimeConfigInterpreter().WithFinishedFeatures()
    

    Runs the tests without issue:

    === RUN   TestEncodeObjectAPI
    --- PASS: TestEncodeObjectAPI (17.07s)
    

    Also, it's ONLY affects WASM compiled with zig build install -Dtarget="wasm32-wasi" -Drelease-safe, so if you compile as debug zig build install -Dtarget="wasm32-wasi" it will run. A lot slower, but runs. The debug have more bounds checks and so on. So, maybe there's something in my code that is actually crashing the runtime, crashing at one unrecoverable point.


    I'll share the source-code soon.

    bug 
    opened by inkeliz 27
  • wasi: exposes CloseWithExitCode to correct implementation of proc_exit

    wasi: exposes CloseWithExitCode to correct implementation of proc_exit

    Before, when the WASI function "proc_exit" was invoked, not only did the module stay alive, but also only the calling goroutine would receive an error with the exit code.

    panic(wasi.ExitCode(exitCode))
    

    Now, this corrects the implementation to actually shutdown the module, and ensure any callers can see the exit code, not just the caller who invoked exit.

    _ = m.CloseWithExitCode(exitCode)
    

    The changes needed for this were numerous, but allow other implementations, such as AssemblyScript abort handlers, to close the same way:

    • Adds Module.CloseWithExitCode which allows propagating an exit code to any callers of exported functions.
    • Dispatches Module.Close to Module.CloseWithExitCode(0)
    • Replace wasi.ExitCode with sys.ExitError which is returned to any in-flight callers. This formalizes the concept regardless of WASI.
    • Ensures all "close-once" guards are tested on engines.
    • Reuses the numeric field used for the closed flag to store the exit_code atomically.
    • Weave in exit errors into existing test cases to reduce code heft.

    This also folds the partially maintained WASI RATIONALE into the top-level doc.

    opened by codefromthecrypt 18
  • Is it possible to grow api.Memory programmatically?

    Is it possible to grow api.Memory programmatically?

    There are scenarios where we may grow shared memory programmatically:

    module, _ := v.runtime.InstantiateModuleFromCode(ctx, policy)
    module.Memory().Grow(1) // error: unresolved reference 'Grow'
    

    However, the Grow method is not defined on the api.Memory interface. It's only defined on the internal MemoryInstance struct:

    func (m *MemoryInstance) Grow(newPages uint32) (result uint32) {
    	// [...]
    }
    

    Is it intentionally designed like that, or there is another API to grow shared memory?

    opened by danielpacak 17
  • Add emscripten_notify_memory_growth import?

    Add emscripten_notify_memory_growth import?

    Is your feature request related to a problem? Please describe. Compiling using emscripten requires emscripten_notify_memory_growth, defined at https://emscripten.org/docs/api_reference/emscripten.h.html#abi-functions.

    This is one single function and that is useless for Wazero. That is require for malloc.

    Minimal code:

    # include "stdint.h"
    # include "stdlib.h"
    # include "stdio.h"
    
    uint8_t *InputMemory;
    uint8_t *OutputMemory;
    
    int main() {
        OutputMemory = (uint8_t *) malloc(8000000);
        InputMemory = (uint8_t *) malloc(8000000);
    
        if (InputMemory == NULL || OutputMemory == NULL) {
            printf("Erro");
            return 1;
        } else {
            printf("Okay");
            return 0;
        }
    }
    

    Compile with:

    emcc wasm.c -o wasm.wasm -O3 -s ALLOW_MEMORY_GROWTH
    

    Requires emscripten_notify_memory_growth.

    Describe the solution you'd like Maybe Wazero can define such import, so any emscripten compiled wasm will work without declaring additional modules.

    Describe alternatives you've considered It's possible to fix by using:

        env, _ := host.NewModuleBuilder("env").
            ExportFunction("emscripten_notify_memory_growth", func(_ int32) {}).
            Instantiate(ctx)
    

    That is very small footprint, but very annoying to declare it everytime.

    Additional context Maybe we can do something similar of AssemblyScript and create one new Emscripten package? However, it's very small, maybe can be declared on WASI? But, it's not WASI anyway. :\

    enhancement 
    opened by inkeliz 16
  • Add support for sign-extension instructions (post MVP feature)

    Add support for sign-extension instructions (post MVP feature)

    Hello,

    I'm opening this issue to report an error I ran into where it appeared wazero was unable to instantiate an AssemblyScript program compiled with asc.

    Here is the error I got:

    functions: invalid function at index 106/280: invalid instruction
    

    Tools like wasm2wat are able to read through the file without issues, so it appears correct tho I do not know whether they perform checks similar to those in wazero.

    I'm attaching the program that triggered the error: test.wasm.gz

    Let me know if you need any other information.

    opened by achille-roussel 16
  • Add tinygo and rust examples that include memory allocation

    Add tinygo and rust examples that include memory allocation

    Hi, thanks for the awesome project! I was taking a look over examples, but I didn't find an example of passing complex values. I'm sorry if I missed something, but do you have something like this? https://wasmedge.org/book/en/embed/go/memory.html#pass-complex-parameters-to-wasm-functions

    opened by knqyf263 15
  • Custom data that is passed to host calls via `HostFunctionCallContext`

    Custom data that is passed to host calls via `HostFunctionCallContext`

    Hello! I am excited about wazero as a means to use Wasm without requiring CGO. Looking forward to ARM64 support!

    I was trying to add wazero as an engine to wapc-go and ran into a small snag. I need the ability to attach custom data to the module instance in order to store function invocation state (context, payload, error, etc). This option is available in other Wasm runtimes and should be easy to add to wazero.

    Envisioned usage:

    Instantiation

    	if err := m.store.Instantiate(m.module, moduleName); err != nil {
    		return nil, err
    	}
    
    	ic := invokeContext{
    		ctx: context.Background(),
    		// ctx and request payload is set prior to calling `store.CallFunction`
                    // response payload or error is set after calling the `hostCallHandler` (below)
    	}
    
    	m.store.SetInstanceData(moduleName, &ic)
    

    Invocation

    func (i *Instance) Invoke(ctx context.Context, operation string, payload []byte) ([]byte, error) {
    	*i.ic = invokeContext{
    		ctx:       ctx,
    		operation: operation,
    		guestReq:  payload,
    	}
    
    	results, _, err := i.m.store.CallFunction(i.name, "__guest_call", uint64(len(operation)), uint64(len(payload)))
    
    	// Inspect response payload or error in `invokeContext`
            // results[0] = 1 for success, 0 for failures
    }
    

    Host call

    func (m *Module) my_host_call(ctx *wasm.HostFunctionCallContext, operationPtr, operationLen, payloadPtr, payloadLen int32) int32 {
    	ic := ctx.Data.(*invokeContext)  // <--- Grabs the custom user data
    	data := ctx.Memory.Buffer
    	operation := string(data[operationPtr : operationPtr+operationLen])
    	payload := make([]byte, payloadLen)
    	copy(payload, data[payloadPtr:payloadPtr+payloadLen])
    
    	ic.hostResp, ic.hostErr = m.hostCallHandler(ic.ctx, operation, payload)
    	if ic.hostErr != nil {
    		return 0
    	}
    
    	return 1
    }
    

    Response payload or error are accessed via other host calls: full example here

    opened by pkedy 15
  • Support WASI poll_oneoff for clock events

    Support WASI poll_oneoff for clock events

    Is your feature request related to a problem? Please describe. Related to https://github.com/tetratelabs/wazero/issues/271. The following code in Rust causes the following panic.

    std::thread::sleep(time::Duration::from_secs(10));
    
    thread '<unnamed>' panicked at 'thread::sleep(): unexpected result of poll_oneoff', library/std/src/sys/wasi/thread.rs:57:22
    

    Describe the solution you'd like Support for the poll_oneoff WASI method.

    enhancement 
    opened by clarkmcc 14
  • Allow passing fs.FS when calling functions

    Allow passing fs.FS when calling functions

    Issue

    Close https://github.com/tetratelabs/wazero/issues/563

    ToDo

    • [x] FSContext
    • [x] FSConfig
    • [x] FSKey
    • [x] Override fs.FS in WASI
    • [x] Add an example
    • [x] Unit test
    • [x] Example test
    opened by knqyf263 14
  • Pass serialized Go structs to TinyGo

    Pass serialized Go structs to TinyGo

    First of all, thanks for the allocation examples. https://github.com/tetratelabs/wazero/tree/main/examples/allocation

    I assumed serialized Go struct can be passed to WASM as a byte array like the above examples and it can be decoded in WASM so that we can pass Go structs to WASM and vice versa. I started with JSON serialization as some JSON libraries seem to work with TinyGo. But fastjson doesn't support struct unmarshaling AFAIK and easyjson didn't work in my environment as below.

    2022/05/04 08:06:32 wasm error: unreachable
    wasm stack trace:
            .runtime.runtimePanic(i32,i32)
            .runtime.slicePanic()
            .(*github.com/mailru/easyjson/jlexer.Lexer).FetchToken(i32)
            .(*github.com/mailru/easyjson/jlexer.Lexer).IsNull(i32) i32
            .greet(i32,i32)
    

    TinyGo code is like the following.

    //export greet
    func _greet(ptr, size uint32) {
    	var b []byte
    	s := (*reflect.SliceHeader)(unsafe.Pointer(&b))
    	s.Len = uintptr(size)
    	s.Data = uintptr(ptr)
    
    	var t foo.TestStruct
    	if err := easyjson.Unmarshal(b, &t); err != nil { // fail here
    		log(err.Error())
    	}
            ...
    }
    

    Do you have any recommendations for passing Go structs? It doesn't have to be JSON.

    opened by knqyf263 14
  • asm: complete arm64 instruction encodings for homemade assembler

    asm: complete arm64 instruction encodings for homemade assembler

    This commit implements all the arm64 instruction encodings necessary for our JIT compiler and replaces the golang-asm assembler with our handmade assembler on arm64 platform. Notably, this allows us to do concurrent compilations.

    This closes #233 combined with #406.

    opened by mathetake 14
  • Move wasm, wasi_snapshot_preview1, ieee754 and similar folders out of internal into utils or helpers

    Move wasm, wasi_snapshot_preview1, ieee754 and similar folders out of internal into utils or helpers

    Is your feature request related to a problem? Please describe. Currently we are not able to decode a wasm module before loading it, exporting these was the only way to load it.

    Describe the solution you'd like Move wasm, wasi_snapshot_preview1, ieee754 and similar folders out of internal into utils or helpers

    Describe alternatives you've considered Forking the wazero repository, and exporting the internals ourselves.

    enhancement 
    opened by skelouse 5
  • Ability/example to implement custom host functions defined by WITX

    Ability/example to implement custom host functions defined by WITX

    Is your feature request related to a problem? Please describe.

    I'm interested in implementing custom host functions defined via WITX in wazero, which can be accessed by a Wasm guest.

    The host function WITX files for this project are from the Fastly [email protected] ABI defined here. This is currently implemented on a Rust runtime and it would be great to have this implemented on the wazero zero dependency Go runtime as well.

    Describe the solution you'd like

    The ability to implement a WITX defined host call in a wazero host implementation, ideally with an example.

    Describe alternatives you've considered

    I've looked at the counter example here. It would be nice to see how this maps to a WITX definition.

    https://github.com/tetratelabs/wazero/blob/main/examples/namespace/counter.go

    I'm unsure if this can be implemented given the lack of support for user-defined types.

    https://github.com/tetratelabs/wazero/issues/420

    Additional context

    None at the moment.

    enhancement 
    opened by grokify 10
  • Compile functions at runtime

    Compile functions at runtime

    Is it (or will it) be possible to extend a running wasm instance with a new function?

    E.g. compile a function from wasm binary representation and add it to the function table. The new function should be able to call all other internal functions. It could be restricted to function signatures that are already present in the module.

    waforth is doing something similar, but compiles a complete module each time, instead of extending the running one (which is not possible in the js-interface).

    enhancement 
    opened by ktye 5
  • Evaluate the correct built-in RNG implementation

    Evaluate the correct built-in RNG implementation

    Is your feature request related to a problem? Please describe. A while back, we switched from math to crypto RNG. This seemed correct at the time, but go's docs hint at a sandbox problem

    // Reader is a global, shared instance of a cryptographically
    // secure random number generator.
    //
    // On Linux and FreeBSD, Reader uses getrandom(2) if available, /dev/urandom otherwise.
    // On OpenBSD, Reader uses getentropy(2).
    // On other Unix-like systems, Reader reads from /dev/urandom.
    // On Windows systems, Reader uses the RtlGenRandom API.
    

    What I'm concerned with is a WebAssembly module exhausting the host entropy source. Elsewhere, such as clocks (#616) we don't expose something that can be used as a covert channel, or break the sandbox.

    Moreover, there's a tacit "capabilities" approach in how people describe WASI, though implementation is very inconsistent across projects. A capabilities approach would default to a fake random, or at least something that can't exhaust the host.

    Describe the solution you'd like

    I'd like advice on if we should change the default and what it would change to. If we are to stay the same, that's also fine, but we should raise a PR to update RATIONALE.md on it.

    So, I think we need to clarify for the API

    • what the value users should supply, which satisfies what imports need?
      • ex an adaquately seeded CSPRNG vs something else
    • what is the default when one was never supplied?

    Related context

    Imports that will consume this:

    • "wasi_snapshot_01" "random_get
      • https://github.com/WebAssembly/WASI/blob/snapshot-01/phases/snapshot/docs.md#-random_getbuf-pointeru8-buf_len-size---errno
    • "wasi-random" "getrandom"
      • https://github.com/WebAssembly/wasi-random/blob/main/wasi-random.wit.md#getrandom
    • "go" "runtime.getRandomData"
      • https://github.com/golang/go/blob/master/misc/wasm/wasm_exec.js#L286

    Related imports we can address now or another way, possibly arch-specific, later:

    • "env" "seed"
      • https://www.assemblyscript.org/concepts.html#special-imports
    • "wasi-random" "insecure-random"
      • https://github.com/WebAssembly/wasi-random/blob/main/wasi-random.wit.md#insecure-random
    enhancement 
    opened by codefromthecrypt 3
  • Serialize a compiled module

    Serialize a compiled module

    Describe the solution you'd like Is it possible to replicate this feature from wasmer-go? Compiling a module results in a significant number of allocations, so I'd like to compile a batch of modules ahead of time to reduce the runtime memory overhead.

    enhancement 
    opened by clarkmcc 12
Owner
Tetrate Labs
Open Source projects from Tetrate
Tetrate Labs
🐹🕸️ WebAssembly runtime for Go

Wasmer Go Website • Docs • Slack Channel A complete and mature WebAssembly runtime for Go based on Wasmer. Features Easy to use: The wasmer API mimics

Wasmer 2.1k Aug 8, 2022
🐹🕸️ WebAssembly runtime for Go

Wasmer Go Website • Docs • Slack Channel A complete and mature WebAssembly runtime for Go based on Wasmer. Features Easy to use: The wasmer API mimics

Wasmer 2.1k Aug 12, 2022
WebAssembly runtime for wasmer-go

gowasmer When compiling Go to WebAssembly, the Go compiler assumes the WebAssembly is going to run in a JavaScript environment. Hence a wasm_exec.js f

mattn 91 Jul 28, 2022
Go compiler for small places. Microcontrollers, WebAssembly, and command-line tools. Based on LLVM.

TinyGo - Go compiler for small places TinyGo is a Go compiler intended for use in small places such as microcontrollers, WebAssembly (Wasm), and comma

TinyGo 11.3k Aug 11, 2022
WebAssembly interop between Go and JS values.

vert Package vert provides WebAssembly interop between Go and JS values. Install GOOS=js GOARCH=wasm go get github.com/norunners/vert Examples Hello W

null 76 Aug 12, 2022
WebAssembly for Proxies (Golang host implementation)

WebAssembly for Proxies (GoLang host implementation) The GoLang implementation for proxy-wasm, enabling developer to run proxy-wasm extensions in Go.

MOSN 37 May 28, 2022
A package to build progressive web apps with Go programming language and WebAssembly.

Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm). Shaping a UI is done by

Maxence Charriere 6.4k Aug 14, 2022
A package to build progressive web apps with Go programming language and WebAssembly.

Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm). Shaping a UI is done by

Maxence Charriere 6.4k Aug 8, 2022
Vugu: A modern UI library for Go+WebAssembly (experimental)

Vugu: A modern UI library for Go+WebAssembly (experimental)

Vugu 4.5k Aug 16, 2022
A template project to demonstrate how to run WebAssembly functions as sidecar microservices in dapr

Live Demo 1. Introduction DAPR is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful app

Second State 129 Aug 12, 2022
Tiny, blazing fast WebAssembly compute

Sat, the tiny WebAssembly compute module Sat (as in satellite) is an experiment, and isn't ready for production use. Please try it out and give feedba

Suborbital 289 Aug 7, 2022
WebAssembly Lightweight Javascript Framework in Go (AngularJS Inspired)

Tango Lightweight WASM HTML / Javascript Framework Intro WebAssembly is nice, Go on the web is nice, so I ported Tangu to Go and WebAssembly. Tangu is

enimatek 4 Jun 8, 2022
Running a Command line tool written in Go on browser with WebAssembly

Running a command line tool written in Go on browser with WebAssembly This repo contains code/assets from the article Files: . ├── article.md

wcchoi 79 Jul 3, 2022
This library provides WebAssembly capability for goja Javascript engine

This module provides WebAssembly functions into goja javascript engine.

YC-L 1 Jan 10, 2022
A Brainfuck to WebAssembly compiler written in Go.

brainfuck2wasm A Brainfuck to WebAssembly compiler written in Go. I am writing this compiler for a Medium article. When I complete the compiler, I'll

Luke I. Wilson 2 Jun 6, 2022
Dom - A Go API for different Web APIs for WebAssembly target

Go DOM binding (and more) for WebAssembly This library provides a Go API for dif

Denys Smirnov 460 Aug 4, 2022
golang-runtime-di is a framework for runtime dependency injection in go

golang-runtime-di description golang-runtime-di is a framework for runtime dependency injection in go. usage quickstart add it to your go.mod: go get

DB Systel GmbH 2 Aug 1, 2022
Golang-WASM provides a simple idiomatic, and comprehensive API and bindings for working with WebAssembly for Go and JavaScript developers

A bridge and bindings for JS DOM API with Go WebAssembly. Written by Team Ortix - Hamza Ali and Chan Wen Xu. GOOS=js GOARCH=wasm go get -u github.com/

TeamOrtix 74 Jul 15, 2022
🐹🕸️ WebAssembly runtime for Go

Wasmer Go Website • Docs • Slack Channel A complete and mature WebAssembly runtime for Go based on Wasmer. Features Easy to use: The wasmer API mimics

Wasmer 2.1k Aug 8, 2022
🐹🕸️ WebAssembly runtime for Go

Wasmer Go Website • Docs • Slack Channel A complete and mature WebAssembly runtime for Go based on Wasmer. Features Easy to use: The wasmer API mimics

Wasmer 2.1k Aug 12, 2022
WebAssembly runtime for wasmer-go

gowasmer When compiling Go to WebAssembly, the Go compiler assumes the WebAssembly is going to run in a JavaScript environment. Hence a wasm_exec.js f

mattn 91 Jul 28, 2022
Multi cluster kubernetes dashboard with batteries included. Build by developers, for developers.

kubetower Multi cluster kubernetes dashboard with batteries included. Built by developers, for developers. Features Restart deployments with one click

Emre Savcı 33 Aug 2, 2022
Nada is a JS runtime, just like Nodejs. The difference is that Nada allows JS developers to easily achieve millions of concurrent applications.

Nada is a JS runtime, just like Nodejs. The difference is that Nada allows JS developers to easily achieve millions of concurrent applications. It also adds some new enhancements to THE JS syntax (types, interfaces, generics) that fundamentally address JS's perennial complaints.

null 22 Jul 11, 2022
Identify containers at runtime and observe them. No container runtime required. Read only access to the kernel.

Linux Telemetry The Double Slit Experiment Taken from an interesting physics anomaly where the behavior of a physical system mutates simply by being o

Kris Nóva 13 Mar 30, 2022
Strict Runtime Dependency Injection for Golang

wire Wire is runtime depedency injection/wiring for golang. It's designed to be strict to avoid your go application running without proper dependency

Muhammad Surya 35 Apr 21, 2022
Query, update and convert data structures from the command line. Comparable to jq/yq but supports JSON, TOML, YAML, XML and CSV with zero runtime dependencies.

dasel Dasel (short for data-selector) allows you to query and modify data structures using selector strings. Comparable to jq / yq, but supports JSON,

Tom Wright 3.5k Aug 9, 2022
Query, update and convert data structures from the command line. Comparable to jq/yq but supports JSON, TOML, YAML, XML and CSV with zero runtime dependencies.

dasel Dasel (short for data-selector) allows you to query and modify data structures using selector strings. Comparable to jq / yq, but supports JSON,

Tom Wright 3.5k Aug 3, 2022
Simple, zero-dependency scheduling library for Go

go-quartz Simple, zero-dependency scheduling library for Go. About Inspired by the Quartz Java scheduler. Library building blocks Job interface. Any t

Eugene R. 926 Aug 12, 2022
A powerful zero-dependency json logger.

ZKits Logger Library About This package is a library of ZKits project. This is a zero-dependency standard JSON log library that supports structured JS

Qingshan Luo 16 Jun 15, 2022