go-kata: twenty Go drills aimed at idiom, not syntax

A practice set, not a tutorial

The README opens with a Bruce Lee line about practicing one kick ten thousand times rather than practicing ten thousand kicks once, and that is the entire pitch. The repository is called Go Katas, it has 2,359 stars and 188 forks, MIT licensed, Go as the language, and its last push was 2026-07-09.

What the author wants it to be is narrow: small, standalone challenges that drill specific Go patterns into muscle memory. The framing question in the README is not how to write Go but where working code and idiomatic code diverge, with the answer given as safety, memory efficiency and concurrency control.

Then comes the section titled what should it NOT be, and it is unusually emphatic. This is not intended to teach coding. Go is not being used as a general-purpose learning vehicle. It is not intended to teach Go in general. The stated motivation is a specific career situation: developers with years of production experience who decide to switch to Go and do not want to discard everything they know. Their two questions are whether that transfer is possible, and if so, which parts are worth studying in order to recognise where their instincts mismatch what the Go ecosystem expects.

So the audience is narrower than the star count suggests. If you are starting Go, this will skip everything you need. If you have written production code in another language and want to know where your habits will embarrass you, every kata here was chosen with that in mind.

Twenty katas across six themes

The index is grouped, and the grouping is the real content. The numbering runs 01 through 20 with no gaps, but the numbers are interleaved across categories, which tells you the kata list grew over time and was sorted into themes afterwards.

The largest group is context, cancellation and fail-fast concurrency with eight katas. Its stated purpose is preventing leaks, enforcing backpressure and failing fast under cancellation. The titles are specific enough to be useful: a fail-fast data aggregator, a graceful shutdown server, a context-aware error propagator, a rate-limited fan-out client, a cache stampede shield built on singleflight with a TTL, a worker pool using backpressure and `errors.Join`, a leak-free scheduler, and a context-aware channel sender that does not leak producers.

Performance, allocation and throughput takes four: a concurrent map with sharded locks, a zero-allocation JSON parser, an NDJSON stream reader that has to handle long lines, and a `sync.Pool` buffer middleware.

Errors gets three, and they are the ones a Go reviewer will care about most: a retry policy that respects context, a cleanup chain exercising `defer`, LIFO ordering and error preservation, and what the README calls the typed nil interface trap, where a nil error stored in an interface is not equal to nil.

The remaining groups are smaller. HTTP and middleware has two, an interface-based middleware chain and an HTTP client hygiene wrapper. Filesystems, packaging and deployment has two, an `io/fs` config loader and an `embed.FS` switch between development and production. Testing and quality gates has one, a harness covering subtests, parallelism and fuzzing. That last group being a single kata is telling, since the testing kata is the one you would most want to see solved properly.

The usage instructions do not match the layout

This is the one place where the repository contradicts itself, and it will waste your time if you follow it literally.

The How to Use section tells you to navigate to any `XX-kata-yy` folder, read the `README.md` inside it, initialize a module inside the folder, write your solution, then compare against a provided Reference Implementation if available. None of those folder names exist. The tree contains six thematic directories, and each one holds numbered subdirectories:

01-context-cancellation-concurrency/
02-performance-allocation/
03-http-middleware/
04-errors-semantics/
05-filesystems-packaging/
06-testing-quality/

The kata links in the index confirm it. Every link is of the form `./01-context-cancellation-concurrency/01-concurrent-aggregator`, so the real path is theme directory then kata directory, and the `kata-` pattern the instructions mention appears nowhere.

The second mismatch is the per-kata module. The instructions say to initialize a module inside the folder, but there is exactly one `go.mod` at the root of the repository declaring `module github.com/medunes/go-kata`. Whether a kata folder ships its own manifest is not visible from the root listing, but the root module means `go test ./...` from the root is the fast way to check everything.

The third mismatch is the most consequential for expectations. Step four says to compare against the Reference Implementation, and the index text for this repository hedges by saying the focus should be on solving common software engineering problems the Go way. The word if available in the instructions is doing real work. Treat solutions as your own record and only expect to find one when a link actually points at it.

One module, three dependencies, four make targets

The dependency surface is small and current. The root `go.mod` declares Go 1.25.5 and two direct requirements:

require (
	github.com/stretchr/testify v1.11.1
	golang.org/x/sync v0.19.0
)

`testify` covers assertions and `golang.org/x/sync` is why kata 09 can ask you to build a singleflight cache. The three indirect requirements are the usual testify transitives, and the absence of a web framework or an ORM is itself a statement about scope: the HTTP and middleware katas are about composition patterns, not about any particular router.

The Makefile has four targets and each one tells you something about how the author works:

test:
	go run gotest.tools/gotestsum@latest --format=testdox  -- -covermode=atomic -coverprofile=coverage.txt ./...
benchmark:
	go test -bench=. -benchmem ./...

The test target fetches gotestsum at the latest version on every run rather than pinning it, and asks for testdox output, which prints each test name as a sentence. That matters more than it sounds: for a practice repository, reading the list of named cases you made pass is the feedback. Coverage is written atomically to `coverage.txt`, which is what the codecov badge reads.

The fourth target is the interesting one. `format-check` runs `gofmt -l .`, and on any unformatted file it prints a GitHub Actions `::error::` annotation, then the offending filenames, then a `gofmt -d` diff, then exits 1. Writing a CI annotation into a local Makefile target is deliberate: the same command produces a nice inline failure on a pull request, so formatting cannot drift without the diff being shown in the review.

There is also a `format` target running `go fmt ./...` for the local case. So: format before you commit, format-check before you push.

Badges, automation and the absence of releases

Three badges sit under the title, and they describe the automated checks without a contributing guide having to explain them: GitHub Actions for tests, CodeQL, and codecov pointed at the `master` branch.

The default branch is `master`, and there is a `CONTRIBUTING.md`, a `README_TEMPLATE.md`, a `.gitignore` and a `.github/` directory. The template file is worth a moment's attention, because it implies a repeatable process for adding kata: a template shape that a new exercise is expected to follow, which is how a collection like this stays internally consistent.

What is absent is a release history. There are no GitHub releases for this repository, so there is no version to pin, no changelog, and no migration to think about. For a set of standalone exercises that is arguably correct, since you consume it by cloning rather than by depending on it. The practical difference is that you get no signal about which Go versions the katas were last adjusted for beyond the `go 1.25.5` directive in `go.mod`.

Zero issues were open at the time of writing, and the topics are minimal: `go`, `golang`, `golang-examples`. There is no topic for concurrency or testing, which makes this repository notably harder to find through search than its content deserves. If you arrived here from a link rather than from search, that is the repository's discoverability problem, not yours.

The topics list is also where the deliberate non-goal shows up again. No `tutorial`, no `learning`, no `beginner`. The tags match the README.

Editorial conclusion

The unusual thing about go-kata is what it refuses to do. It is not a Go tutorial, it does not teach syntax, and it does not even promise you a reference solution for most exercises. What it offers instead is a curated list of the places where experienced engineers transferring into Go most often write code that compiles and works but is not what a Go developer would have written. That is a real gap, and the Bruce Lee framing at the top of the README is exactly right about it: the value is in repetition, not in first exposure. The twenty katas cover cancellation and fail-fast behaviour, allocation and throughput, HTTP middleware composition, error wrapping semantics, filesystem and embedding choices, and test harness design, which is close to a map of where idiomatic Go opinions actually live. Two practical notes before you start. The How to Use section tells you to open an `XX-kata-yy` folder, which is not how the repository is laid out, so navigate by the six thematic directories and the index instead. And the whole set shares one module with three direct dependencies, so a solution for a single kata is built against the same dependency graph as the other nineteen. Make a branch, run `make test` before and after, and read the diff in the output rather than the pass count.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MedUnes/go-kata on GitHub
4. README