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?
I flagged because perennial complaining about the license is boring, adds nothing of value to the conversation, and just leads to the same tired series of arguments.
MIT and CC-BY-4.0 are the industry standards for code snippets and documentation, respectively.
If the author intends for the work to be copyleft, non-commercial, or a combination of those, there are specific licenses within the Creative Commons family that satisfy those requirements. These are already widely used for open-source books on GitHub.
This is why I suggested "any Creative Commons licenses" rather than a specific one. My goal wasn't to spark an argument over which one is the "best", but rather to provide the author with options to choose from, depending on their specific needs.
>My goal wasn't to spark an argument over which one is the "best", but rather to provide the author with options to choose from, depending on their specific needs.
GitHub has Issues and Pull Request features for exactly this purpose.
Are you proposing that people who want to use this code should just assume they can do so, violate the implied copyright, and accept the associated risk?
You're talking about a library of markdown files for your own personal use to practice writing some code, posted to github, and includes a bunch of language about how to contribute, explicit instructions to fork it, etc.
Imagine giving a flying shit about the lack of a license, in that context. Couldn't be me.
The lack of a license file is by several orders of magnitude the least interesting thing about this repo.
So it's the nature of the repo for you, then. Presumably you wouldn't take the same position if the repo contained a substantial software system.
> Imagine giving a flying shit about the lack of a license, in that context. Couldn't be me.
Some of us are accountable to other people for these kinds of things. One comment mentioned possibly using this for a team transitioning to Go. In that context, license can matter. Having explicit authorization to use it changes it from an open question that can raise concerns, to something you don't have to worry about.
Btw well done on adding to the "perennial complaining about the license". The top comment made a perfectly reasonable request, that may have been useful to the OP author. It wasn't a complaint. You could have just not commented. And flagging was an obnoxious choice.
>Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Complaining about the license falls under this. Someone asked my it was flagged, I answered. One flag isn't enough to kill a comment, btw. I was far from the only one who flagged.
>Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
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.
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.
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.
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?
I would guess that most folks would consider a bunch of problem prompts with no reference solutions to be not so useful. How would you check your understanding? How would you know if you were writing go code which would be frowned upon by industry veterans?
And on top of that, putting these in AGENTS.md makes no sense whatsoever. You’ll simply waste tokens and confuse the hell out of your agents. I wonder if gp assumed this is another repo of design patterns without reading anything there at all. Pasting a bunch of design patterns into AGENTS.md may not be the brightest idea either but at least that isn’t absurd.
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
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.
What is the difference between a "prod grade kata" and a practice project?
I fail to see the value to someone transitioning to Go if there aren't any reference solutions.
How would one know if one's code is idiomatic, without either a reference or someone to ask?
And if you have someone to ask, what's the point of this repo?
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?
https://github.com/MedUnes/go-kata-solutions seems like they intended to create the solutions too, but seems like there's no progress yet
Could you please add a LICENSE file to the repository? MIT or any Creative Commons licenses would be a great choice.
I'm not sure why this has been flagged - its not possible to copy code from the repo, as it defaults to All-Rights-Reserved (aka proprietary)
Unless that's explicitly the intent, in which case that's fair
I flagged because perennial complaining about the license is boring, adds nothing of value to the conversation, and just leads to the same tired series of arguments.
It is quite possible that the author isn't aware that "all rights reserved" is the default and intended the license to be more open.
If they do want to keep it proprietary, it would be nice to make that explicit.
MIT and CC-BY-4.0 are the industry standards for code snippets and documentation, respectively.
If the author intends for the work to be copyleft, non-commercial, or a combination of those, there are specific licenses within the Creative Commons family that satisfy those requirements. These are already widely used for open-source books on GitHub.
This is why I suggested "any Creative Commons licenses" rather than a specific one. My goal wasn't to spark an argument over which one is the "best", but rather to provide the author with options to choose from, depending on their specific needs.
>My goal wasn't to spark an argument over which one is the "best", but rather to provide the author with options to choose from, depending on their specific needs.
GitHub has Issues and Pull Request features for exactly this purpose.
Are you proposing that people who want to use this code should just assume they can do so, violate the implied copyright, and accept the associated risk?
Yes, that is exactly what I'm proposing.
You're talking about a library of markdown files for your own personal use to practice writing some code, posted to github, and includes a bunch of language about how to contribute, explicit instructions to fork it, etc.
Imagine giving a flying shit about the lack of a license, in that context. Couldn't be me.
The lack of a license file is by several orders of magnitude the least interesting thing about this repo.
So it's the nature of the repo for you, then. Presumably you wouldn't take the same position if the repo contained a substantial software system.
> Imagine giving a flying shit about the lack of a license, in that context. Couldn't be me.
Some of us are accountable to other people for these kinds of things. One comment mentioned possibly using this for a team transitioning to Go. In that context, license can matter. Having explicit authorization to use it changes it from an open question that can raise concerns, to something you don't have to worry about.
Btw well done on adding to the "perennial complaining about the license". The top comment made a perfectly reasonable request, that may have been useful to the OP author. It wasn't a complaint. You could have just not commented. And flagging was an obnoxious choice.
You're afoul of these, from the HN guidelines:
>Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Complaining about the license falls under this. Someone asked my it was flagged, I answered. One flag isn't enough to kill a comment, btw. I was far from the only one who flagged.
>Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Complaining about why I flagged is discouraged.
Do better.
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.
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.
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.
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?
I’m sure this is useful for me who is a staff+ engineer building a team who are transitioning to go.
Including these Kata in AGENTS.md is extremely useful.
Buy your team John Arundel's books.
Source: Transitioned my team.
[flagged]
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
https://news.ycombinator.com/newsguidelines.html
I would guess that most folks would consider a bunch of problem prompts with no reference solutions to be not so useful. How would you check your understanding? How would you know if you were writing go code which would be frowned upon by industry veterans?
And on top of that, putting these in AGENTS.md makes no sense whatsoever. You’ll simply waste tokens and confuse the hell out of your agents. I wonder if gp assumed this is another repo of design patterns without reading anything there at all. Pasting a bunch of design patterns into AGENTS.md may not be the brightest idea either but at least that isn’t absurd.
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:
I wish it had solutions.
And automatic tests in some cases.