As said by Akavall, arrays are hashable. That means they can be used as a key to a map.
They are also pass by value. Each time you pass it to a function or assign it to another variable it makes a complete copy of it.
They can be serialized by encoding/binary.
They also can be used to control memory layout. Since it is not a reference, when it is placed in a struct, it will allocate that much memory as part of the struct instead of putting the equivalent of a pointer there like a slice would.
Bottom line, don’t use an array unless you know what you are doing.
Hashable/serializable are all nice to have, but I’m just not sure if they are indeed that compelling to have
What would you do if you wanted to have a map of md5 hashes? Can’t use a byte slice so you would need to do something like this to get around the type system:
// 16 bytes
type hashableMd5 struct {a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p byte}
Then create a serialization function for it. Hashable arrays mean that you can just call it a [16]byte.
Sounds like getting closer to C’s malloc, sizeof
Nope, that has nothing to do with malloc or sizeof. Those are to allocate memory and get the size of a variable.
However, CGo is another use case for this. The cgo command creates types that have the same memory layout as their corresponding C types. To do this, it sometimes needs to insert unnamed arrays for padding.
If problems can be solved with … nil/insignificant performance penalty using slices …
Arrays also prevent indirects making certain types of code faster. Of course this is such a minor optimization that this is insignificant in nearly all cases.