Question

Would such a language be feasible or are there specific features in go that absolutely require some form of a gc?

note: I am not anti-gc, but coming from a C/C++ background and working on a real-time server application, I prefer to maintain some level of control how and when memory is reaped (can’t have a 10s garbage-collection happening in the middle of a live run).

Are my concerns realistic, given my requirements? Or is the go gc so good that my concerns are unfounded?

Go’s gc is my only reservation about attempting a port of my C++ real-time server to go.

Answer 1

Go with optional GC would require language changes. Here’s a perfectly valid Go function that will make a C programmer’s skin crawl:

func foo() *int {
    a := 1
    return &a
}

This is fine because the Go compiler will figure out that the variable a needs to be allocated on the heap. It will be garbage collected later and you don’t have to care. (Well, ok, in some situations you might. But most of the time you don’t.)

You can concoct all kinds of scenarios where the compiler will do things like this. It just wouldn’t be the same without a garbage collector.

There are things you can do to help GC times, but to a certain extent you’ll be nullifying the advantages of the language. I hesitate to recommend these practices, but are options:

• Free lists
• With the unsafe package you can even write your own allocator and manually free memory, but you’d need a function for every type you want to allocate. Or use reflection to pass in the type you want to allocate, return an empty interface, and use type assertions to get concrete values out.

The bottom line is, Go probably isn’t a good choice for applications with hard real-time requirements. That said, I also don’t think you’ll see anything approaching a 10 second garbage collection. Consider what your requirements really are and if you have any doubts, do some measurements.

Try the latest Go code if you can. There are some garbage collector improvements and some compiler optimizations that cause fewer allocations. If your release time frame is shorter, though, you may be stuck with the current stable release for several months.