Hacker News Reader

Comment by lmirosevic | Hacker News Reader

"Go has garbage collection, only. [...] Day 1 design decision." http://talks.golang.org/2012/splash.slide#51

Can someone tell me why GC was the obvious choice as opposed to say automatic reference counting?

If you squint your eyes enough, automatic reference counting is a garbage collection method. But if you are going down that road, there are other garbage collector schemes which often produces way better performance in the common situations, i.e., copying collection or Mark'n'sweep.

But it is a trade-off. Refcounting collectors need to address pointer cycles. And they are also quite slow due to all the refcount bookkeeping going on all the time. But they have the nice property that the lifetime of an object won't linger around in a zombie state. And there are no point in time where the system is in a "collecting" state and cannot give service.

That said, many modern, multi-core malloc() routines contain a lot of ideas from GCs in them. The gap is closing fast.

Maybe because they don't want the production code to deal with reference cycles? I don't know the real reason, better to ask Rob Pike directly ! :)

Because tracking memory allocation and ownership in a concurrent program is very hard. Programmers have to track a lot of that stuff in their heads, and it's easy to make mistakes. If the language is garbage collected, however, the programmer doesn't have to think about that.

Reply on news.ycombinator.com