denis256 notes and projects

Rill, a Go toolkit for composable concurrency, had a quiet but useful week: the maintainers added a local lint hook and then cleaned up public comments. This is not a feature release, but it matters if you contribute to Rill because CI style now has a local path, and the exported docs for Batch and MapReduce read a bit cleaner.

Local lint now has a repo path

The main operational change is the new hook config. It adds a local contributor path for golangci-lint, using the upstream golangci/golangci-lint hook at v2.12.2 and the golangci-lint-full hook id. That lines up with the repo direction from the nearby lint work already present in .golangci.yaml, which enables errorlint, godoclint, modernize, and goimports.

For users of the library, this does not change runtime behavior. For contributors, it changes where feedback happens. Instead of waiting for a GitHub check to complain about a docs lint issue or import format, the same class of failure can be caught before the branch is pushed. That is the correct place for lint noise: on the machine where the diff is still cheap to fix.

The config is small, which is good. There is no custom wrapper script and no new build tool hidden in the tree.

repos:
  - repo: https://github.com/golangci/golangci-lint
    rev: v2.12.2
    hooks:
      - id: golangci-lint-full

A few concrete points are worth noting:

• golangci-lint-full is now the local hook target.
• rev: v2.12.2 pins the lint tool version.
• prek autoupdate is named as the refresh path when CI and local hooks disagree.

Doc comments got a small cleanup

The other change is a typo pass across exported comments. In batch.go, Batch take becomes Batch takes. In internal/core/reduce.go, the MapReduce comment changes inout to input. That is two words, but both sit in API docs that Go users are likely to read through pkg.go.dev.

This kind of change is boring until a user is copying an example at 23:00 and one awkward word makes them pause. Rill sells a simple mental model: stream values through typed channels, control parallelism, and keep error handling at the edge of the pipeline. Comments on Batch and MapReduce are part of that interface. They are not implementation details.

Batch is especially important because it is one of the places where the library maps directly to real systems. A worker groups items until a size or timeout condition is met. Bad comments around that behavior can push users toward wrong batching assumptions, such as thinking the function only emits full batches. The typo fix does not change behavior, but it removes friction from the documented contract.

Contributor experience over feature churn

A small week like this can still tell you something about project maintenance. Rill is a tiny API surface on top of Go channels. That means accidental churn is more expensive than it looks. A new flag or helper would be easy to add, but the project value comes from keeping the channel pipeline model predictable.

The two commits fit that bias. One commit makes local checks more repeatable. The other tightens generated documentation. Neither changes go.mod, dependencies, public functions, or error semantics. If you are upgrading Rill as an application dependency, this activity should not force code changes.

For contributors, the useful preparation is modest:

• Run the hook before opening a pull request if you use the configured runner.
• Expect docs lint to matter, since godoclint is enabled in the repo lint config.
• Treat exported comments as part of the public API review, not as a final cleanup task.

What this means for Rill users

Operators and library consumers can read this as maintenance work, not as a migration signal. There are no new options for Batch, no changes to MapReduce, and no dependency bump that would pull new code into builds. The package still targets Go 1.25 in go.mod.

The more relevant point is documentation quality. Rill examples use concurrency counts, background workers, timeouts, and stream conversion. Those examples are easy to misunderstand when comments drift. A project that keeps lint and comments tidy is less likely to let stale examples survive for long. That is not a guarantee, just a healthy signal.

If you maintain code around Rill, no immediate action is needed. If you contribute, update local hooks and let the linter fail before CI does. That saves everyone a review round for things a machine can catch.

What to watch

The next useful signal is whether the new hook stays in sync with CI. The config comment already says to run prek autoupdate when CI lint fails but the local hook passes. That is blunt and practical. It also means contributors should treat stale hook revisions as a normal maintenance item.

Watch for follow up work around docs lint findings. Since godoclint is enabled, future changes may tighten exported comments rather than public behavior. That is fine for a library like Rill. The API is small, so clear docs carry more weight than a long release note.

Finally, do not read these commits as a feature preview. The week was about contributor hygiene and public comment quality. Small, but not pointless.