Go

I wrote a small validator that accepted interface{} and walked fields marked validate:"required". The happy path worked, so I naturally declared victory before trying a pointer, a nil pointer, or anything that was not a struct.

The first version began with this:

v := reflect.ValueOf(x)
for i := 0; i < v.NumField(); i++ {
	// inspect v.Field(i)
}

Passing &User{} produced reflect: call of reflect.Value.NumField on ptr Value. Recovering the panic would hide the real question: what inputs does this validator promise to accept? I chose structs and non-nil pointers to structs, with ordinary errors for everything else.

func validate(x interface{}) error {
	v := reflect.ValueOf(x)
	if !v.IsValid() {
		return errors.New("cannot validate nil")
	}
	if v.Kind() == reflect.Ptr {
		if v.IsNil() {
			return errors.New("cannot validate nil pointer")
		}
		v = v.Elem()
	}
	if v.Kind() != reflect.Struct {
		return fmt.Errorf("cannot validate %s", v.Kind())
	}

	t := v.Type()
	for i := 0; i < v.NumField(); i++ {
		if t.Field(i).Tag.Get("validate") != "required" {
			continue
		}
		if isZero(v.Field(i)) {
			return fmt.Errorf("%s is required", t.Field(i).Name)
		}
	}
	return nil
}

The harder policy is what “required” means. For this validator it rejects empty strings, numeric zero, false, and nil pointers, maps, slices, and interfaces. That makes false invalid, so a required boolean is usually a design smell; a pointer can represent the distinct states absent, false, and true.

I ignore unexported fields. A general validator should not turn another package’s private representation into public input policy.

Nested structs are not automatically validated. A field gets nested validation only when its tag asks for it; otherwise adding a private detail to a child type could unexpectedly change the parent’s contract. Nil optional pointers remain acceptable, while a required nil pointer fails at its own field path.

Errors report the Go field path as well as the failed rule. A bare “required” is compact but useless once validation descends into two nested structs with similarly named fields.

Reflection removes field-by-field plumbing, but the useful part is still the contract: accepted top-level shapes, the meaning of “required,” whether nesting is opt-in, and useful error paths. Once those choices are explicit, the reflective code can stay small and unsurprising.

I wanted one struct to describe both its JSON name and a tiny validation rule. The obvious declaration was:

type User struct {
	Name string `json:"name" validate:"required"`
}

My first parser split the raw tag on spaces and colons. It worked until quoting became interesting, which took approximately seven minutes. reflect.StructTag already understands the convention:

t := reflect.TypeOf(User{})
f, _ := t.FieldByName("Name")
fmt.Println(f.Tag.Get("json"))
fmt.Println(f.Tag.Get("validate"))

Output:

name
required

Tags are metadata attached to fields in the type. Reflection exposes them; the compiler does not enforce what validate:"required" means. Misspelling the key gives an empty string, indistinguishable from an explicitly empty value when using Get.

Only exported fields are useful to packages such as encoding/json, because reflection cannot generally set unexported fields from another package. I also avoid turning tags into a miniature programming language. Once a rule needs conditions, database access, or cross-field state, ordinary Go is clearer.

One more trap: reflect.TypeOf on a pointer yields a pointer type. To inspect its fields I use t.Elem(). Reflection is precise, but it is not especially interested in guessing what I meant.

Three Go 1.2 additions fixed three unrelated annoyances in one week. None is glamorous, which is usually a sign that I will use it.

First, go test now measures statement coverage directly:

The cover tool is still distributed separately in go.tools, so I installed it first:

$ go get code.google.com/p/go.tools/cmd/cover

$ go test -cover
PASS
coverage: 71.4% of statements
ok      example/parser   0.012s

For detail I use go test -coverprofile=cover.out, followed by go tool cover -func=cover.out or go tool cover -html=cover.out. Coverage works by rewriting source with counters. It tells me which statements ran, not whether the assertions were intelligent. I can reach 100 percent while testing almost nothing; I have demonstrated this skill repeatedly.

Second, crypto/tls gained better control over protocol and cipher behavior, including TLS 1.2 support. For a client that must reject obsolete protocol versions I can set the minimum explicitly:

tr := &http.Transport{
	TLSClientConfig: &tls.Config{
		MinVersion: tls.VersionTLS11,
	},
}
client := &http.Client{Transport: tr}

I still let the standard library choose cipher suites unless interoperability forces my hand. A handwritten list ages, and a secure-looking list copied from a weblog ages especially well.

Finally, sync/atomic now has swap operations. I used one to replace a numeric generation and retrieve the previous value as a single atomic action:

old := atomic.SwapUint64(&generation, next)
log.Printf("generation %d -> %d", old, next)

The important phrase is “single atomic action.” Loading and then storing separately leaves a window in which another goroutine can intervene. A swap closes that window, but it does not magically protect related fields or establish a larger invariant. For that I still use a mutex.

The default coverage mode counts whether statements execute. When tests exercise code concurrently, -covermode=atomic makes counter updates safe, at additional cost. I do not compare benchmark timings from an instrumented coverage build with normal timings. The inserted counters are deliberately observable work.

Atomics also require aligned, correctly typed storage and a design whose state really fits in one word. My generation counter does. A configuration containing a counter, pointer, and status does not become coherent because each field can be manipulated atomically. Readers could observe a combination that never represented one published configuration.

I keep the atomic operation beside a comment describing that single-word invariant. Otherwise the next maintenance change tends to add a companion field and quietly invalidate the reasoning.

These features share a useful property: they turn homemade approximations into explicit operations. I deleted a coverage script, avoided a custom TLS dialer, and replaced a dubious load/store pair. Upgrades are pleasant when the final diff is mostly subtraction.

One of my test programs had a rude goroutine: it performed a long loop containing function calls while another goroutine waited to print progress. With one processor, older Go releases could let the loop dominate longer than I liked.

func spin(n int) int {
	total := 0
	for i := 0; i < n; i++ {
		total += step(i)
	}
	return total
}

func step(i int) int { return i & 7 }

Go 1.2 introduces partial preemption when entering non-inlined functions. The scheduler can arrange for a goroutine to yield when it reaches one of these safe points. I built this experiment with -gcflags=-l so the tiny step call would remain a call. It does not make arbitrary Go code preemptible at every instruction. A tight loop with no calls can still be an unpleasant neighbor, and long cgo calls remain a different matter.

That distinction matters. I first described the change to a colleague as “preemptive scheduling,” then wrote a no-call loop and disproved my own sentence. Progress became much fairer when the loop called step, but not because the runtime had acquired a general-purpose interruptible stack map for every program counter.

The other runtime change I can actually feel is stack size. New goroutine stacks in Go 1.2 start at 8 KiB rather than the smaller segments used before. That spends more virtual and physical memory up front, but avoids repeated stack splitting in modest call chains. In a crude test creating 100,000 blocked goroutines, memory is therefore not simply “100,000 times a tiny number.” Goroutines are cheap, not free.

The segmented stacks still grow by linking stack segments. This is why a function prologue checks whether enough stack remains before proceeding. The check and occasional split are part of the cost hidden behind an ordinary call.

I confirmed the scheduling effect with GOMAXPROCS=1, because multiple operating-system threads otherwise conceal starvation by running both goroutines simultaneously. That is a useful test setting, not necessarily a production recommendation. With more processors, synchronization and cache traffic enter the result; the single-processor run isolates whether one runnable goroutine gets a chance to yield to another.

Channel sends, receives, and system calls introduce other scheduling boundaries. My example intentionally removed those ordinary blocking points so the function-call behavior could be seen without a busy server around it.

My practical rule remains boring: do not add runtime.Gosched to every loop as seasoning. First determine whether the loop really starves useful work, then put natural blocking or chunking boundaries into the algorithm. Go 1.2 improves the worst behavior around calls, but it does not repeal scheduling.

I upgraded a small service to Go 1.2 and immediately found a use for the new full slice expression. That sounds implausibly efficient for an upgrade, so naturally it followed a bug.

I had a helper that accepted a prefix of a work buffer and appended a marker:

func mark(p []byte) []byte {
	return append(p, '!')
}

buf := []byte("abcdef")
prefix := buf[:3]
marked := mark(prefix)
fmt.Printf("%s %s\n", marked, buf)

I expected a separate abc!. I got:

abc! abc!ef

The ordinary two-index slice preserves the unused capacity of the backing array. prefix had length 3 but capacity 6, so append reused the array and replaced d. The helper’s signature did not advertise permission to alter bytes beyond the visible slice, but capacity quietly granted exactly that permission.

Go 1.2 adds a third index:

prefix := buf[:3:3]

For a[low:high:max], the length is high-low and the capacity is max-low. Now the output is:

abc! abcdef

Because len(prefix) == cap(prefix), append must allocate another backing array. This is not an immutable slice. The helper can still change prefix[0], and anyone sharing the original array will see that change. The third index controls append’s room, nothing more.

It is also useful when dividing one large buffer among independent workers:

left := buf[0:3:3]
right := buf[3:6:6]

Appending to left can no longer wander into right. Before 1.2 I used append([]byte(nil), buf[:3]...), which copies eagerly and obscures why. The full slice expression is both cheaper and more precise when all I need is a capacity fence.

The indices must satisfy 0 <= low <= high <= max <= cap(a). The upper capacity bound is checked at run time just like an ordinary slice bound. I find it useful to print both dimensions when debugging ownership:

fmt.Printf("len=%d cap=%d\n", len(prefix), cap(prefix))

Reslicing later cannot recover the fenced-off capacity. The slice header handed to the helper records only a pointer, length, and reduced capacity; it carries no secret reference to my original wider view.

For an array rather than a slice, the omitted low index still defaults to zero. I write all three values at boundaries anyway; explicit fences are easier to review than clever shorthand.

My caveat is that I would not scatter three-index slices everywhere. Most slices should share capacity normally. I use the extra index at ownership boundaries, where an append by a callee would otherwise mutate storage it does not conceptually own.