Making int 32-bit or 64-bit depending upon the bitness of the current arch is one of the few Go language decisions I disagree with, primarily because it causes

Making int 32-bit or 64-bit depending upon the bitness of the current arch is one of the few Go language decisions I disagree with, primarily because it causes confusion with CGo since int in C/C++ (while technically compiler-specific) is, in practice, always 32-bits even on 64-bit platforms. People writing CGo code can avoid this easy enough by understanding the issue and using C.int where they want C style ints, but I've run into more than a handful of examples of actual code in the wild using CGo that has issues because it expected 'int' in Go to be the same size as 'int' in C, which it will be if the arch is 32-bit, but won't be if the arch is 64-bit. eg: https://github.com/visualfc/go-ui/issues/11 https://github.com/visualfc/go-ui/issues/11 IMO the right call would be just go with what C does and treat both int and int32 as 32-bit ints, int64 exists if you need it, but having 'int' size be different between C/C++ and Go on the same arch violates principal of least surprise, IMO.