Are you sure about that? I don't think you'll be running Go on an AVR. Likewise to this day Go still can't pin pointers so interop with native C libraries is a royal pain(this is something that C# and Java both support).
People love to bag on C but there are domains where it can go that a GC'd language can't. I wouldn't be so quick to equate the two.
I don't think Go needs to be a like-for-exact-like analog of C to be a valid replacement. For many C programs, the memory management pattern they use is something that could be handled just as easily with GC, and done so in such a way as to lift a significant burden on the programmer.
I mentioned this in another comment, but definitely, if you need to manage your own memory—don't use Go. I must disagree that GC disallows Go as a replacement for the language. But I will respect your opinion if you think it does!
Much if modern C usage is in this space even if it's not as visible to the average developer.
GCs have a host of problems like needing a 2x working set, pauses and the fact that you can't control allocation locations for better cache usage. Go may be fast but it will never unseat C/C++/Rust in performance for the reasons above.