In addition to the architecture-independent numeric types, Go provides three architecture-specific numeric types. Although there are far fewer of them, they often get a lot more usage.

Numeric Types

…

There is also a set of predeclared integer types with implementation-specific sizes:

uint     either 32 or 64 bits
int      same size as uint
uintptr  an unsigned integer large enough to store the uninterpreted bits of a pointer value

What does it mean for a type’s size to be architecture-dependent?

Well, it means that if you compile you code to run on, say, the 386 architecture, then int, and uint will hold 32 bits of data. But if you compile for the amd64 architecture, the same types will hold 64 bits of data.

But importantly, just because you may be compiling and running your code for the 386 architecture doesn’t mean that int and int32 are the same!

… Explicit conversions are required when different numeric types are mixed in an expression or assignment. For instance, int32 and int are not the same type even though they may have the same size on a particular architecture.

Okay, but why bother with this complexity?

In a word: efficiency.

While any CPU (not counting truly ancient ones) can handle both 32-bit and 64-bit numbers, they can’t do it with equal efficiency.

Manipulating 64-bit numbers on the 386 architecture involves manipulating two sets of 32-bit numbers, because the CPU’s native operations operate only on 32-bit numbers at a time.

So when should you use these architecture-specific types? Well, most of the time, actually. Generally, use int and uint for for loops or internal counters, unless there’s a risk of overflow (you’re counting large numbers that could exceed the min/max values of a 32-bit value), or you know you need a specific format for compatibility (i.e. writing the exact memory bits to the network or disk or similar).

Quotes from The Go Programming Language Specification, Version of January 19, 2023