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
This blog explains how the Go runtime metrics /cpu/classes/total:cpu-seconds is calculated. Go1.22.7 is used as source code reference.
When I wrote this blog, go has just released go1.25rc2 and go1.23 is quite a long time ago release. In go1.23 release note, go team shares that Go 1.23 makes two significant changes to the implementation of time.Timer and time.Ticker. This blog focuses on the second change:
the timer channel associated with a Timer or Ticker is now unbuffered, with capacity 0. The main effect of this change is that Go now guarantees that for any call to a Reset or Stop method, no stale values prepared before that call will be sent or received after the call.
It will talk about why buffered channel is a problem, why unbuffered channel is used, the cases affected and how go implements this change.