iota-generated constants versus explicit constants

The useful comparison is between constants generated with iota and constants that have explicit values. Both approaches create immutable compile-time values, so there is no meaningful runtime speed advantage. The decision is about readability, maintenance, and whether the numeric values must remain stable.

With iota, an enum-like declaration is concise: const (Pending State = iota; Running; Done). Go evaluates iota as zero, one, and two, and omitted expressions repeat the previous expression. This works well when the constants are related, private to the program, and naturally sequential.

The explicit alternative is const (Pending State = 0; Running State = 1; Done State = 2). It is more repetitive, but each value is visible and remains unchanged if a new constant is inserted between existing lines. That stability is important when the numbers are stored or exchanged with another system.

iota becomes especially valuable when the relationship is a formula rather than simple counting. For bit flags, Read Permission = 1 << iota followed by Write and Execute clearly expresses the power-of-two pattern and avoids manually calculating one, two, and four.

Explicit values are better for HTTP or RPC contracts, database enums, metrics labels that encode numbers, and file formats. In those situations, changing a value can break another deployment or reinterpret existing data, so a few repeated assignments are a reasonable cost.

Neither approach gives Go a closed enum. Code can still convert another integer to the named type, so validation may be required at input boundaries. I would not claim that iota automatically makes every value safe.

My default is iota for internal sequences and bit patterns, but explicit constants for durable or externally visible identifiers. The boundary of the program, rather than syntax preference, determines the choice.