I'm not nearly as angsty as the parent on this subject, but they don't really free the developer from guessing about hidden allocations--Go's allocations are still very much hidden even if developers can reasonably guess about the behavior of the escape analyzer. I think it would have been better if Go _required_ explicit assignment of all variables. That said, despite not being a big fan of this particular decision, Go is still by far the most productive language I've used--it strikes an excellent balance between type safety and productivity even if I think some things could be improved.

Zero values prioritize implementation convenience (we always have a zero value so we don't need to handle any cases where we don't have a value, just says those are zero) over application convenience (maybe my type should not have a default and the situation where it has no value is an error)

Take either of Rust's library types named Ordering - core::cmp::Ordering (is five less than eight or greater?) or core::sync::atomic::Ordering (even if it's on another core this decrement definitely happens before that check) neither of these implements Default because even though internally they both use the zero bit pattern to mean something, that's a specific value, not a default.

They're like PHP: silent failures that ever push forwards through the system.