I don't agree with the GP, but if Go were very similar to C and the only big difference would be that C has no GC it would pretty easy to picture what the C equivalent of Go code would be. Exactly the same but with calls to `free()` at the end of some functions. (or preempted between instructions at unpredictable places)
Don't make GC's a bigger deal then they are. They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead.
There's also the overhead of the mark phase, which has to work out dynamically what could be worked out statically in a system with manual memory management. That's where much of the overhead of GC comes from.
I'll add to that that the overhead is not proportional to the amount of garbage your application generates, it's proportional to the amount of data blocks your application has allocated. Garbage collection is also often performed by suspending the application (stop the world) at unpredictable moments and with an unpredictable duration. Garbage collection can thus be a serious problem for some type of applications. This is why the GC should be optional.
> They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead.
That's not actually true. They also allow you to do things that you otherwise couldn't. Try implementing persistent [1] maps or sets without a GC.
Sort of. But you can't statically decide it. In fact, really the only way to do it is with a GC (or ref. counting, etc.). You can't know until runtime when a node will need to be freed.
And my point still stands. The GC allows you to do things you otherwise couldn't.
Don't make GC's a bigger deal then they are. They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead.