Like others have mentioned, RAII-style stuff doesn't work so well with a GC language.

Go does provide a "defer" statement, which cause a function call to execute when the current function returns. This makes it easy to visually co-locate resource acquisition and release, as well as ensuring the release code runs regardless of how the function is exited.

It looks like this:

    f := os.Open("someFile")
    defer f.Close() // will run when current function exits

It's easy and works well (IMO).

This is a general property of most garbage collected languages - you don't know when a gc takes place (if ever) to run finalizers.

For this reason Java has try-with-resources, C# using, Haskell bracket and Go defer.

Note that you can attach a finalizer to a Go struct: https://golang.org/pkg/runtime/#SetFinalizer

I'm not sure exactly where you see that so I'm not entirely sure of the context (I tried looking in the first chapter), but a general problem with garbage-collected languages is that while the runtime will eventually get around to cleaning up unused resources, you don't always have guarantees about when. So you still generally need to close files when you're done with them, or you may run out of filehandles. I've encountered this issue in multiple languages, it's not Go-specific.

> I would have thought that a modern language

The only thing modern about Go is that it's just a few years old, but it's based on programming language concepts that were mainstream in the late 90s.