Requiring a value to be provided at usage/definition site would go a long way. Also, of course, having to provide a default value by hand when initializing an array. Go also has easy-to-use callbacks, so having also APIs that take a callback returning a sentinel/default value should be easy enough. The problem isn't having defaults, but having pervasive defaults that are set in stone by the language itself, even in places where it doesn't make sense.
For low-level code that fiddles with uninitialized memory buffers and allocators, things might get complicated, if zero values are not allowed. (Rust's struggles around `MaybeUninit` is a poster child example of the ensuing complexity.) However, I think that a very Go-style solution would have been that the type system allows for zero-initialized types, but everything around the provided APIs and language semantics makes creating them hard. It's a similar solution with "our strings are UTF-8, but we don't check and world doesn't explode if they are not". I generally dislike this kind of "worse is better" design, but it certainly fits Go very well.
The main problem with Go, arguably, would be what to do with null pointers. They could have gone with separate reference types for "definitely not null" and "may be null", with a specialized if-like check-and-coerce-operation, without having full generics and sum types like Rust does.
Because Go has a GC and thus is capable of having arbitrary object graphs, there shouldn't be a problem of initializing multiple values with a reference to the same object, so user providing a default value and the API cloning it to fill the array should work. And in case of a "may be null" ref, having it to be null is not a problem.