Show HN: Go playground powered by WASM that runs in the browser

    #!/usr/bin/env bash
    {
      find . -name "*.go" -print
      echo package.json
    } | entr bash -c '
    set -euxo pipefail
    clear
    go fmt
    clear
    go build
    :
    '

There seems to be another interpreter that seems to be able to provide some autocomplete using some other third party tool, but it seemed to run from beginning every time (same effect as `go run`) and I havent tried it.

Each cell runs in a 0.3 secs on Linux, but 3 seconds + on Windows.

If you want just straight terminal check out Gomacro, that's a interpreter that runs really fast, didn't find any differences to compiled Go.

There are 3 big reasons for large Go binaries.

1. Unicode data is ~1 MB. It's needed to implement all the unicode-aware string functions like strings.EqualFold()

2. reflection. For reflection to work, every struct used in a Go program needs to have a description information that tells names and types of all fields. This adds up

3. Precise garbage collector also requires struct descriptions like reflection but even more information like: layout of stack frame for every function.

Those are problems that could, in theory, be worked-around.

A build could exclude Unicode info and functions that require it.

A different garbage collector could be used that doesn't require knowing layout of structs and stack frames.

Reflection could be changed to require explicit opt-in (99% of structs are not reflected upon).

Realistically none of that will happen in the official Go implementation. For better or worse most of the work is sponsored by Google and Google runs Go on servers. With 512 MB of memory, it makes little difference if your binary is 10 MB vs 9 MB, especially if you compete with even more bloat (in runtime memory use, not necessarily binary size) of Java / Python / Ruby / Node.

There are a couple of not-very-mature Go-like implementation that are trying to address this (tinygo, emgo) but they have long way to go.

I've lost track of the process (there were several proposals) so I'm not sure where we're at now.

I guess not much changed, so the current state of WASM is mostly for porting and running non-JS code (such as Go's here) in the browser.

It's also faster than JS (if passed through an optimizing compiler) so it might be useful for non-IO-bound code.

Outside the browser it's being used as a sort of universal bytecode (a la JVM). https://wasmer.io/