Go Developer Tools

Small, exact answers to the questions that cost a working Go developer an afternoon. Each one runs in your browser, in Go compiled to WebAssembly — the same packages, with the same tests, that would run on a server.

Nothing you paste is transmitted. There is no endpoint behind any of these pages, so there is nothing to send it to: the module is fetched once from this origin and everything after that happens in the tab. Disconnect the network once a page has loaded and it keeps working.

Every tool here is free and needs no account. None of them costs a credit, and none of them asks for one.

• Go Time Layout Converter — strftime to Go, and back

  Convert a C strftime format string to a Go reference layout and back, directive by directive, with every unmappable directive named rather than guessed.

• Go Method Sets — why *T implements the interface and T does not

  Paste a type and an interface and get both method sets computed by go/types, with the compiler's own error and the rule it follows from.

• Go Struct Field Alignment — offsets, padding, and what reordering saves

  Paste a struct and get every field's offset, the padding between them, the total size, and a reordered version with the saving — for the architecture you choose.

• Go Slice Growth — what append actually does to the capacity

  Watch a slice's capacity grow append by append: the formula's answer, the allocator's rounding, the size class it lands in, and the bytes left behind.

• Go Goroutine Dump Analyzer — read a SIGQUIT or panic stack dump

  Paste a goroutine dump and get it grouped by state and by stack, with wait durations and the stacks held by far more goroutines than they should be.

How these work

Every tool is a thin page in front of an ordinary Go package. The parsing, the arithmetic and the type checking are all done by that package, compiled once to WebAssembly; the page reads your input, hands it over, and draws what comes back. Nothing is reimplemented in JavaScript, which is the only way the answer a page gives can be the answer Go gives.

The section ships two modules rather than one per tool. The tools that read Go source need the compiler's own front end — go/ast and go/types — which is most of a Go toolchain by size, so they share one module and the rest share a much smaller one. A page loads only the module it needs, and only when you open it.

Where the answers come from

Where a tool describes runtime behavior, it derives the numbers from the Go toolchain installed at build time rather than from a blog post: size classes and the slice growth thresholds are read out of the standard library's own source, and every page that depends on them says which Go version they came from. Where a notation cannot express something, the tool names the gap instead of guessing at it — a converted format string that quietly prints the wrong field is worse than no answer at all.