It is unmaintained and has some very serious issues with 64-bit cleanliness (it assumes C int being the same size as Go int, but C int is virtually always 32-bit whereas Go int is either 32-bit or 64-bit depending upon GOARCH).
The same author has another project here which was meant to be a second pass at this (from what I can tell):
But as far as I know nothing was ever released on that project.
The approach used here of exposing QML is the most practical one, IMO. The Qt API is huge (not to mention C++ as opposed to C based) and creating a monster wrapper around it in Go is no easy task (especially if you wanted it to feel like Go) and would be a bear to maintain. Sticking with QML gives you a much smaller surface area to worry about while still giving you most of the benefit of using Qt as a GUI toolkit (at least with Qt 5.1+).
The main reason why the Go support was done in this fashion is that developing applications in such a declarative manner seems to be a better experience despite any difficulties in creating the tooling.
Just opinion, but if I were writing a new program on top of qt I'd always go for qml. The qt 5.x releases are rapidly fleshing it out, and you get guaranteed opengl, good scripting, declarative layout, and super easy accelerated animations and transitions. That and it has much less code overhead than raw c++, even when using it is also painfully easy with signals and slots.
The 5.1 controls module is 95% of the way there to fully native looking QML. At that point, qt widgets are just a fallback.
