Go's generic type inference is hard to read if I start from unify.go, infer.go, and call.go directly. A simpler way is to treat it like a small set of LeetCode problems: each problem has a clear input, a target behavior, and a check for whether the model is good enough.
Idea from Yuchen. Text written by AI.
Prometheus golang_client helps to expose go runtime/metrics so you can collect it, and the block below shows a short example.
collectors.WithGoCollectorRuntimeMetrics accepts various rules and prometheus collector package also offers several options.
This page offers a table to show prometheus exposed go runtime metrics naming, and the rules to enable them for reference. It solves 2 painpoints listed below.
This page helps you to quickly query when a metric of runtime/metrics was supported. For example, you can query the table to know metrics /gc/gogc:percent was added in go1.21.0
Background: I wrote notes and blogs regularly to record my thoughts and experiences. However, I found due to my carelles I wrote some typos, either Chinese or English, and I was aware this when I read them later. This is a painpoint for me so I would like to find a workflow to tackle it.
I first try to find a specialized spell check for both Chinese and English but failed, as a result, I try to integrate AI code review by qodo-ai/pr-agent in my github action.
This blog explains how the Go runtime metrics /cpu/classes/total:cpu-seconds is calculated. Go1.22.7 is used as source code reference.