Thank you for the insightful response. I think you're mostly correct here, though there are, of course, subtleties. Other than C and C++, Go is one of the best

Thank you for the insightful response. I think you're mostly correct here, though there are, of course, subtleties. Other than C and C++, Go is one of the best languages for controlling memory. Not freeing, of course, but making it very clear where there are allocations, where there are copies, exactly how much memory is being used by any particular data structure. Portability - you can run binaries created by gccgo in many many places beyond amd64/x86/arm. No, certainly not as many as C... but probably as many as anyone would ever want to support. So unless you're targeting a specific embedded application, then Go is probably fine. GC is getting a big push in Go and in 6 months they're going to make hard real time guarantees about the GC... i.e., no more than 10ms pause every 50ms, and the GC will be hybrid stop-the-world/concurrent, so some memory may be collected while other code continues to run. Otherwise, yes, you're right, there are (of course) some limitations to using Go over C. However, there are some huge benefits to using Go over C as well... such as memory safety. There will never be a buffer overflow in your code. Also, concurrent code will be a thousand times more readable and easier to reason about. That's not to say that C isn't the right choice sometimes... I just think the places where C is the best choice are becoming more and more rare, and not just due to Go, but Rust as well.