This is because the byte ordering is the byte ordering of the target type which has no meaning when the target is only 8 bits wide.

Said another way, guid is 16 bytes. That’s it, no endianness needed.

@davecheney Thank you for comment.

the target is only 8 bits wide.

It is an element size (not an entire slice).
So binary.Read supports only 1,2,4,8,16 bytes which are the size of numeric types, right ?

guid is 16 bytes. That’s it, no endianness needed.

I think we should take care endianness.

MS supports a GUID API to avoid Guid endianness issue. (refer to Remarks)

https://docs.microsoft.com/en-us/archive/blogs/openspecification/guids-and-endianness-endi-an-ne-ssinguid-or-idne-na-en-ssinguid

So binary.Read supports only 1,2,4,8,16 bytes which are the size of numeric types, right ?

it supports integer types of varying but sizes. If you decode into something larger than a byte then endianness comes into play.

binary.Read does not support what you are trying to do.

binary.Read ignores the endian argument if the data you're reading into is a byte slice. You have to read into a larger type, e.g. int32, for endianness to matter.

You can always reverse your byte slice after reading.

func reverse(b []byte) {
   for i := 0; i < len(b)/2; i++ {
       b[i], b[len(b)-1-i] = b[len(b)-1-i], b[i]
   }
}

@davecheney @randall77 Thank you for comment and example code !

I understood binary.Read doesn't support what I want to do.
So, I close this issue.