A set of Idiomatic prod-grade katas for experienced devs transitioning to Go

I’ve been transitioning to Go after years in other ecosystems, and kept running into the same problem: I could write correct Go code, but not idiomatic Go.

Most material focuses on syntax or algorithms. In practice, what caused friction were production mismatches: context cancellation and goroutine leaks, errgroup vs WaitGroup tradeoffs, HTTP client hygiene, error wrapping semantics, allocation control, embed/io/fs for dev–prod parity, etc.

I started collecting small, constraint-driven katas that isolate one such mismatch at a time. Each kata defines explicit pass/fail idiomatic constraints, rather than providing solutions. The goal is deliberate practice, not “best practices” or tutorials.

This repo is curated by someone transitioning to Go, for others doing the same. It’s not meant to be authoritative. If you’re experienced with Go and spot incorrect, unsafe, or misleading constraints, issues and PRs with rationale and references are explicitly encouraged.

I’m especially interested in feedback from people using Go in production on where these constraints are wrong, incomplete, or missing important edge cases.

The instructions mention "Reflect: Compare your solution with the provided "Reference Implementation" (if available)" but not a single line of code is present.

Is this an artifact of it all being ai generated, or work in progress?

Could you please add a LICENSE file to the repository? MIT or any Creative Commons licenses would be a great choice.

If the idea is to have devs implement each kata, wouldn't it be more effective to provide not only automated tests, but also code which should be used as a basis for each challenge?

For example, if supporting a dev tag to serve assets from the filesystem, why not include a simple webserver which embeds the contents?

This would allow aspiring gophers to go straight to the high value modification of a project rather than effectively spend most of the time writing scaffolding and tests.

Hi and thanks so much for the feedback here

If I got it right, the summary is as such:

1- License: I'll add soon, forgot about it (literally)

2- Where is the solution: I hope you all read the contributing guide, I clearly mentioned solutions are not the MAIN point for this repository, it is rather giving problems which are intended to *guide* me/you through hands-on practical constraints on how to face those "go" weird scenarios. I also clearly stated I'm not that much top notch Go dev to provide you with solutions for now

3- No, this is neither chatgpt, nor claude code generated repo.

4- I'm till waiting until someone with enough experience that worked on these problems in real life can either suggest solutions or provide support

5- The project is a hands-on documentation, maybe on-going process. IMHO is better (for me at least) than a youtube video that I forgot about the next day. Struggling into the problem and implementing an okkeyish solution would force me ask and search for the foundational knowledge behind it, read books *with this goal in mind*, what videos *with that intention*, and so on. I'm very hands-on learning person.

6- Would be very nice to have these questions here in form of Github issues as well, then maybe seasoned devs can support both me and you better

7- I haven't expected it to escalate to ~ 1.7k stars in two weeks, with not much effort, and this is IMHO a proof many devs struggle with that exact gap I'm trying to tackle

This honestly just looks like a bunch of ChatGPT output. There’s almost no code (I checked maybe half a dozen topics). Not sure how useful this is for anyone besides the author. Why would I look at this instead of asking an LLM?

As a seasoned Gohper, I agree with few commenters here - this would work best if you would write the task's requirements and provide actual runnable tests to hook the final code into, in order to see if it passes the assignment or not.

there's also https://github.com/cdarwin/go-koans for small go exercises.

you may have issues running in Docker; when i last touched this i needed to modify docker.sh:

  -docker run --rm -ti -v "$PWD":/usr/src/koans -w /usr/src/koans golang:1.6.0-alpine go test
  +docker run --rm -ti -e GO111MODULE=off -v "$PWD":/usr/src/koans -w /usr/src/koans golang:1.18-alpine go test

When it's done, it'll be one hell of a project!

Suggestion: continue in the current LLM-generated track and ask Claude (or whatever) to create an example + unit tests validating the idiom. Then tell Claude to remove half the example, leaving only a stub + failing unit tests. Add a go.mod at root + instructions on how to run all tests. The go initiate is "certified" once he/she has forked the repository and made the tests pass.

I’ve been writing Go for nearly 4 years and work on a team with senior Go engineers. Concurrency is the language feature people seem to talk about most when talking about Go, and yet we use it so rarely; usually it’s just a second pass optimisation rather than something thought about from the start.

I wish it had solutions.