Running and Testing Go Snippets with the Go Playground

The Go Playground is the quickest way to compile and run a small Go snippet without installing Go locally. Paste a self-contained program into the editor, select Run, and inspect its standard output or error messages.

It is especially useful for reducing a bug to a few lines, checking language behavior, and giving another developer a compact reproduction. It is not a replacement for a local Go environment: programs run in a sandbox with restricted I/O, finite resources, and a deliberately unusual clock.

What the Go Playground does

The Playground sends your program to a service that vets, compiles, links, and runs it inside a sandbox. The service then returns the resulting output. According to the service page, it follows the latest stable Go release; the referenced page identifies that release as Go 1.27.1.

This makes the Playground useful for language experiments and small, self-contained examples. It also means results can change after the Playground moves to a newer stable release. If a behavior matters to your example, make the assumptions visible in the code rather than relying on a particular local setup.

Running a snippet

A conventional Playground program uses package main and defines main:

package main

import "fmt"

func main() {
	items := []string{"compile", "run", "inspect"}
	for i, item := range items {
		fmt.Printf("%d: %s\n", i+1, item)
	}
}

The only communication a Playground program has with the outside world is through standard output and standard error. That is enough for fmt.Println, diagnostic messages, and test results, but not for interactive input or dependencies on external files and services.

Most of the standard library is available, with some exceptions. The service documentation does not provide a package-by-package exclusion list, so the practical rule is to keep Playground examples self-contained and try the packages they require.

Run a test without writing main

The Playground has a useful testing mode: when a program contains tests or examples but has no main function, the service runs the tests.

Here is a complete main-less snippet:

package main

import "testing"

func Double(n int) int {
	return n * 2
}

func TestDouble(t *testing.T) {
	got := Double(21)
	want := 42

	if got != want {
		t.Fatalf("Double(21) = %d; want %d", got, want)
	}
}

Paste it into the Playground and run it. Because there is a TestDouble function and no main, the service treats the snippet as a test program. A successful run includes a PASS result. Changing want to 41 gives you a compact failing example with the message supplied to t.Fatalf.

This is handy for sharing a function together with an executable statement of its expected behavior. It also avoids adding a demonstration-only main function to code that is naturally expressed as a test.

Benchmarks are a different matter. The Playground documentation says they will likely not be supported because the sandbox has limited resources. Even when a benchmark-shaped snippet can be compiled, the Playground is the wrong environment for meaningful performance measurements. Use a controlled local or CI environment instead.

The clock does not start at the current time

Playground time begins at 2009-11-10 23:00:00 UTC. The fixed starting point gives programs more deterministic output, which makes their results easier to cache.

You can observe it with this snippet:

package main

import (
	"fmt"
	"time"
)

func main() {
	fmt.Println(time.Now().UTC())
}

The printed timestamp starts at the Playground's fixed 2009 date rather than the current date on your machine. This matters when demonstrating expiration checks, timestamp validation, deadlines, or date-based calculations. A snippet that asks whether a real certificate, token, or record has expired can therefore reach a different answer in the Playground.

Keep time-sensitive examples explicit. Passing a timestamp into the function under test is usually clearer than having the function call time.Now internally:

func expired(now, deadline time.Time) bool {
	return !now.Before(deadline)
}

The caller can then supply a fixed now, making the example understandable in both the Playground and a normal test suite.

Code that depends on external communication

A network request is a poor fit for the Playground because it depends on communication other than stdout or stderr:

package main

import (
	"fmt"
	"net/http"
	"os"
)

func main() {
	resp, err := http.Get("https://example.com")
	if err != nil {
		fmt.Fprintln(os.Stderr, "request failed:", err)
		return
	}
	defer resp.Body.Close()

	fmt.Println(resp.Status)
}

Do not build a Playground demonstration around that request succeeding. The same design warning applies to reading user input or expecting a local configuration file to exist. Replace those dependencies with literals, in-memory readers, or small test fixtures embedded directly in the snippet.

For example, code that normally parses a file can accept an io.Reader; the Playground example can then pass strings.NewReader. That improves the snippet and often improves the production API as well.

Design around the sandbox

The service imposes execution-time, CPU, and memory limits. Programs intended to run indefinitely, consume large datasets, stress the scheduler, or measure fine performance differences are therefore unsuitable.

A good Playground example should:

• contain all required source and data;
• finish quickly;
• report results through stdout, stderr, or tests;
• avoid network, filesystem, and interactive-input dependencies;
• use explicit test data for time-sensitive behavior;
• demonstrate one behavior rather than recreate an entire service.

For stable-language experiments, use go.dev/play, which follows the latest stable release. The underlying Playground service can also be used as a backend by other community sites, but the Go project asks integrators to contact the team first, send a unique user agent, and ensure that the service benefits the Go community.