Кстати, как я понял, Go резервирует большое адресное пространство для более эффективной работы сборщика мусора. А именно - таким образом они пытаются уменьшить вероятность коллизий консервативного сборщика мусора (а у них он консервативный). Таким образом, проблема не специфична именно что для Go - при любой реализации рантайма (вне зависимости от языка) с консервативным сборщиком мусора приходится выбирать - либо высокая вероятность коллизий (а следовательно и утечек памяти), либо резервируем большое адресное пространство, но тогда будут проблемы на архитектурах с "тесным" адресным пространством (32 битным например).