# exercism/go: the Go track behind Exercism, kept running without community pull requests

> exercism/go holds the Go track that Exercism students fetch, the exercise stubs, reference solutions, generators and CI configuration for them. The repository is not archived and was pushed on 2026-10-13, but it explicitly refuses community contributions, which tells you something about who maintains it and what kind of change is realistic.

**exercism/go** — Exercism exercises in Go.

- Repository: https://github.com/exercism/go
- Website: https://exercism.org/tracks/go
- Stars: 1,195 · Forks: 686
- Language: Go
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/exercism-go

## A track repository that has closed its pull request window

The first thing the README tells you is not about Go at all. It warns that the repository does not accept community contributions, and points to an Exercism blog post called "freeing our maintainers" for the reasoning. Feedback still has a route: the Go section of the Exercism forum. The topic tags on the repository include `community-contributions-paused` and `maintained-autonomous`, and the two visible GitHub Actions badges are a Configlet CI check and an Exercise tests check.

So the shape of this repository is a small maintainer group shipping track content, with CI acting as the gate rather than peer review. That has consequences for anyone evaluating it. If you need a new exercise added, a stub rewritten, or a test case extended, this is not the place to propose it. If you need to know exactly what a Go learner will download and what the CI will run, it is the authoritative place.

Status facts are short. The repository is MIT licensed, it is not archived, the default branch is `main`, the homepage is the Go track page on exercism.org, and the last push was on 2026-10-13. It has no GitHub releases at all, so there is no version history to pin. Consumers get the `main` branch or the track fetch, never a tagged artefact.

## An exercise enters the track through an entry in config.json

Every exercise in the track is configured by one entry in the `exercises` array of `config.json` at the root of the repository. The README walks through a hypothetical optional exercise called `fizzbuzz` to show the shape of such an entry:

```json
{
  "slug": "fizzbuzz",
  "uuid": "mumblety-peg-whatever",
  "core": false,
  "unlocked_by": "two-fer",
  "difficulty": 1,
  "topics": ["conditionals"]
}
```

The fields carry real weight for a student. `core` decides whether the exercise is part of the core syllabus. `unlocked_by` names the exercise that has to be completed before this one appears, so the track can be sequenced as a progression. `difficulty` and `topics` drive how the exercise is presented on the site.

The `uuid` is worth a second look, because it is a human-readable placeholder in the example, and it exists to give an exercise a stable identity that survives a slug being renamed. The repository points to the Exercism documentation page on `config.json` for the full field reference. Note also that `config.json` carries a second responsibility: its `ignore_pattern` key decides which files are stripped when a student fetches an exercise. One file, two unrelated jobs, and both are the kind of thing worth reading before you rely on the track.

## The four files that make up an exercise directory

Under `exercises/`, each exercise is a directory, and the README is explicit that the file list can vary from one exercise to the next. The canonical listing it shows looks like this:

```sh
~/go/exercises/fizzbuzz
$ tree -a
.
├── cases_test.go
├── example.go
├── fizzbuzz.go
├── fizzbuzz_test.go
├── .meta
│   └── description.md
│   └── gen.go
│   └── hints.md
│   └── metadata.yml
└── README.md
```

The division of labour is worth understanding. `fizzbuzz_test.go` is the main test file a student runs. `fizzbuzz.go` is a stub file, present only in some early exercises, giving a starting point. `example.go` is a reference solution used by CI to verify the test suite itself. `cases_test.go` holds generated test cases sourced from the problem specifications repository, and it appears only in some exercises. `go.mod` is the module file, and the README notes it should be generated automatically by the generator code rather than edited by hand.

The `.meta` directory holds track specific files that are not shipped to students: a `description.md` used to generate the track specific part of the exercise README, `hints.md` for extra track specific guidance, `metadata.yml` for track specific metadata that overrides the shared metadata, and `gen.go`, the generator that produces `cases_test.go`. Some exercises carry extra files beyond this list, such as the `series` exercise, which contains extra test files.

## Ignored files: what the student never receives

The fetch step strips a defined set of files from every exercise directory, and this is the mechanism that keeps reference solutions from leaking into the student's copy.

Two categories are ignored. The `.meta` directory and everything in it goes, along with any file matching the `ignore_pattern` defined in `config.json`. The README spells out the current pattern in plain language: it matches any filename containing the word `example`, unless it is followed by the word `test`, with any number of characters in between. So `example.go` disappears, while a file such as `example_test.go` is spared, since `test` follows `example`.

The reason reference solutions can be written plainly is stated directly: because they are skipped by `exercism fetch`, there is less need for the example code to be a model of style, expression and readability, or to use the best algorithm. Examples can be plain, simple, concise, even naïve, as long as they are correct. That is a deliberate trade of pedagogical elegance for a smaller solution review surface, and it means you should not read `example.go` as a style guide for your own Go.

## Local setup: fork, clone, fetch the linter, run the tests

The development setup section is short and concrete. You need a recent version of Go installed, ideally the current release or the previous one, a GitHub account, and a fork of `exercism/go` under your own name. The clone command it gives is:

```bash
git clone https://github.com/<you>/go
```

Then it says to test the clone by changing into the `go` directory and typing the two repository scripts, in this order:

```bash
bin/fetch-golangci-lint
bin/run-tests
```

After that, the README says you should see tests pass for all exercises. The lint binary is fetched by a script rather than assumed present, which keeps the toolchain version aligned with the repository's expectations.

One line in that section is easy to skim past and matters for anyone who knows the older Go workflow. The README notes that, unlike most other Go code, it is not necessary to clone this into your GOPATH, because the repository only imports from the standard library and is not expected to be imported by other packages. The code should be formatted with `gofmt`.

## A misspelling checker kept out of CI on purpose

The repository points to a misspelling tool and says you can install it and occasionally run it to find low hanging typo problems. What it does not do is wire it into the pipeline, and it gives the reason in a reference to pull request 570: it is not added into CI since it could give false positives.

That is a small but instructive detail about how this repository treats its own checks. The two badges at the top of the README are the Configlet CI check, which validates track configuration, and the Exercise tests check, which runs the exercise test suites. A linter is fetched locally by `bin/fetch-golangci-lint`, and `bin/run-tests` is the gate that matters. The repository keeps its automated checks narrow and deterministic, and pushes anything noisy into a local, opt-in step. The practical effect for a contributor is that `bin/run-tests` is the command that decides whether your change is acceptable, and the formatting rule that matters is `gofmt`.

## Where the exercise content comes from, and the .meta override

The exercises do not originate inside this repository. Test data and README text come from the Exercism problem-specifications repository, which collects common information for all exercises across all tracks, and this track adds its own layer on top. Where track specific documentation is needed, the files in an exercise's `.meta` directory override or augment the exercise README. `description.md` feeds a track specific description into the exercise README, and `hints.md` adds track specific information alongside the generic problem-specification description.

`metadata.yml` is the track specific override for exercise metadata itself, and `.meta/gen.go` regenerates `cases_test.go` from the shared test data whenever that data changes upstream. The README describes the flow as synchronizing exercises with problem specifications, and the `cases_test.go` file is labelled as generated rather than hand written. A track that is downstream of a shared specification inherits that specification's cadence: content fixes land in the problem-specifications repository first and reach Go students only after this repository regenerates and the Exercise tests workflow passes.

That layering also means the two content sources can disagree. The shared version is the default, and the `.meta` files are the exception, so a reader comparing an exercise's text on exercism.org with the problem specifications will sometimes see differences that come from the Go track's own overrides.

## Conclusion

exercism/go is worth adopting as the source of truth for Go exercises, test data and track configuration, and it is a poor fit as a place to send a patch: the README states the repository does not accept community contributions, so a fork with a new exercise or a reworded stub will not be merged through the usual pull request route. Before depending on it, check the config.json entry for the specific exercise you care about, run bin/run-tests after bin/fetch-golangci-lint to confirm the suite passes on your Go version, and read the exercise README a student actually receives, because example.go and the .meta directory are stripped out by exercism fetch and are the parts students never see.

## FAQ

### Can I contribute a new exercise to exercism/go?

Not through pull requests. The README states plainly that the repository currently does not accept community contributions, and it points to a blog post about freeing the maintainers for the details. Feedback and problem reports can be raised in the Go section of the Exercism forum instead.

### How do I run the test suite for the exercism Go track locally?

Clone your fork of the repository, change into the `go` directory, then run `bin/fetch-golangci-lint` followed by `bin/run-tests`. The README says you should then see tests pass for all exercises. You do not need to place the clone inside your GOPATH, since the repository only imports from the standard library.

### Why can I not find example.go after fetching an exercise from exercism/go?

Reference solutions and generator files are ignored on fetch, along with the whole `.meta` directory and any filename matching the `ignore_pattern` in config.json. That pattern currently matches any filename containing `example` unless the word `test` follows it, so `example.go` is never delivered to a student.

### Where does the Go track get its exercise test cases and README text?

Both come from the Exercism problem-specifications repository, which holds common information for exercises across all tracks. Track specific additions live in each exercise's `.meta` directory: `description.md` and `hints.md` adjust the README, `metadata.yml` overrides exercise metadata, and `gen.go` regenerates the `cases_test.go` file from the shared data.

## Sources

- [exercism/go on GitHub](https://github.com/exercism/go)
- [Issues](https://github.com/exercism/go/issues)
- [License: MIT](https://github.com/exercism/go/blob/main/LICENSE)
- [Project website](https://exercism.org/tracks/go)
- [README](https://github.com/exercism/go/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/exercism-go