The playground uses nacl/amd64p32 and only has 32bit ints and thereby knows that math.MaxInt64 as a const will definitily be to large to fit in an int in the call to to strings.Repeat.

The max length of a slice that can be theoretically attempted to be allocated depends on the platform and the element size. The compiler does not propagate the "h" and math.MaxInt64 all the way to runtime.makeslice and checks this at compile time. Therefore the runtime checks this before attempting to allocate memory.

Most amd64 machines have a 48bit address space (some newer ones seem to exist with 57bit?) So the runtime checks if the length of the slice to be created (depending on the element size) could be tracked at all (regardless if available ram which might be even smaller). And math.MaxInt64 wont be able to be handled by any existing amd64 machine and would require 16 exibytes of adressable ram.
Therefore its "len out of range" of the supported length for a byte sized slice.

I didn't expect this to work, I just expected a different error message.

If I try:

package main

import (
	"math"
	"strings"
)

func main() {
	strings.Repeat("hh", math.MaxInt64)
}

I get:

panic: strings: Repeat count causes overflow

goroutine 1 [running]:
strings.Repeat(0x1071f5b, 0x2, 0x7fffffffffffffff, 0xc42004bf78, 0xc42007e058)
	/usr/local/go/src/strings/strings.go:540 +0x1a9
main.main()
	/Users/bep/go/src/github.com/bep/temp/main.go:9 +0x45

Repeat can know if the len of the resulting string overflows int and therefore it would never work aside from any memory limits due to limits of int. The library functions generally do not check if the specific platform is able to allocate such large slices themselves or if there is enough available ram. While the makeslice error could be more informative (it handles all cases e.g. negative len and to large len equally) the panic message is I think set in stone due to the GO1 compatibility guarantee.

Fair enough.