I've started a new side project for improving my Go knowledge, and I plan to also write more by hand (although I'll be making heavy use of AI as a tutor).
The project: Two AI models are about to play chess against each other. This has most likely already been done, but it sounds like fun, especially the arena mode where a lot of the learning will happen: I want to go deep on Go's concurrency model: goroutines, channel orchestration, memory profiling, GC tuning, and the dark art of stopping goroutine leaks under heavy load.
It comes in two stages.
Stage one is the real thing: the two models actually playing, move by move, on screen.
Stage two is where the learning happens. A single game is boring concurrency. So I swap the real models out for mock players (fake opponents that cost nothing and answer instantly) and run thousands of games at once as a load test. No API calls, no bill, just pure pressure on the runtime. I can even make the mocks hang on purpose to force the exact goroutine leaks I'm trying to learn to catch. That's where memory creeps and the garbage collector starts to sweat.
The rule I'm setting myself: the AI plays the chess, but I write the engine. No AI for the core Go code. I'll use it as a tutor and a reviewer: "find the leak in this," "explain this profile", but the concurrency logic, I type myself.
40 minutes a day. Small, consistent reps. Let's see how far that goes. Wish me luck...
If you were learning a concurrency model from scratch, what would you build to do it?
Top comments (0)