What does crypto/rand.Text() return in Go, and why prefer it over hand-rolling a token?

## The call ```go func Text() string ``` `crypto/rand.Text` takes nothing and returns a string. It fills 26 bytes from the package's cryptographic source and maps each one onto the standard RFC 4648 base32 alphabet — the 26 uppercase letters plus the digits 2 through 7, 32 symbols in total. Twenty-six symbols of five bits each is why the documentation can promise at least 128 bits of randomness. Because the alphabet has exactly 32 symbols and a byte has 256 values, the mapping divides evenly: every symbol is equally likely. That is not an accident of the implementation, it is why base32 was chosen over, say, a 62-character alphanumeric alphabet, where reducing a random byte onto the alphabet would skew the result unless you handle it carefully. ## Why the API has no knobs Every parameter a token API exposes is a parameter somebody gets wrong. `Text` has none: - **No length.** You cannot ask for a shorter token and quietly drop below the guarantee the documentation makes. If you slice the result to ten characters you have thrown that guarantee away, and you now own the arithmetic. - **No alphabet.** You cannot pass a character set whose size makes the reduction skew. - **No error.** It calls `crypto/rand.Read`, which since Go 1.24 always fills its buffer and never returns an error. So there is no error branch — and therefore no place for the classic bug of falling back to a statistical generator when the "impossible" error fires. What you lose is control over format. The output is uppercase and alphanumeric; if your product needs lowercase, hyphen groups or a numeric code, `Text` is not it and you build from `crypto/rand.Read` or `crypto/rand.Int` instead. ## What it replaces Before Go 1.24, the standard shape was: allocate a byte slice, fill it with `crypto/rand.Read`, then turn the bytes into a printable string with an encoder. That code is fine when written carefully, and it is still the right thing when you need a specific format. But it is four decisions wide — slice length, encoder, error handling, and whether the encoder's output is URL-safe — and a review has to check all four every time. `rand.Text()` is one decision wide, and the decision has already been made by the standard library. ## Where it fits in a reset-link worker A worker that consumes a queue of reset requests and hands links to a mailer wants one value per message, generated locally, with no failure mode: ```go func resetLink(base string) (token, link string) { token = rand.Text() return token, base + "?t=" + token } ``` No error path, nothing to plumb, nothing to mock. The characters need no percent-encoding in a query string, and they are unambiguous when a user retypes them, which is why base32 excludes the digits 0 and 1 and the letters they resemble. ## Neighbouring calls in the same package - `crypto/rand.Read(b []byte)` — fills a slice with random bytes. This is what you want for a key, a salt, or anything you will pass to a cipher rather than show to a person. - `crypto/rand.Int(rand io.Reader, max *big.Int) (*big.Int, error)` — returns a uniformly distributed value in the half-open range `[0, max)`. This is the call for a six-digit confirmation code or for choosing an index into a custom alphabet. It takes and returns `*big.Int`, which is clumsy for small numbers but is what keeps the distribution uniform; it panics if `max` is not positive. - `crypto/rand.Reader` — the `io.Reader` behind all of them, and the value you pass as the first argument to `Int`. ## The reviewer's rule of thumb If the value is a short secret a human or a URL will carry, reach for `Text`. If it is bytes a cryptographic primitive will consume, reach for `Read`. If it is a number in a range, reach for `Int`. A hand-rolled string built out of `Read` plus a custom alphabet needs a reason in the pull-request description, because the standard library now covers the common case and the custom version has more places to be wrong.