The API of GoCV matches the API of OpenCV quite well. A particularly good API to showcase is the display window. With the display window, one is able to display the image the webcam is receiving live. It's also a very useful tool for debugging, in cases where one might want to write a new classifier.

I have developed programs for many years. It's fair to say I've seen many design patterns and packages. Among the prickliest problems to have for almost all programming languages is the foreign function interface, when a program has to call a library written in another language. Not many are well done. Most are shoddily done, as if something is plastered over the underlying foreign function interface (FFI). In Go, FFI is handled by cgo.

Very often, library authors (myself included) get too smart, and attempt to manage resources on behalf of the users. While at first blush this may seem to be good UX, good customer service even, this ultimately leads to much pain. At the time of writing, Gorgonia itself had just undergone a series of refactors to make the resource metaphors more clear, specifically with regards to CUDA usage.

With all this said, GoCV is probably one of the most consistent Go libraries with regards to its cgo usage. The part where GoCV is consistent is in its treatment of foreign objects. Everything is treated as a resource; hence, most types have a .Close() method. There are certainly other beauties of GoCV, including the customenv build tags, which allow library users to define where OpenCV is installed, but the chief compliment I have for GoCV is in its consistency with regards to treating OpenCV objects as an external resource.

The treatment of objects with the resource metaphor guides us in our use of the GoCV API. All objects must be closed after use,which is a  simple rule to abide by.