(disclaimer: My opinion on Go is based on my own limited experience from writing a few private projects using OpenGL.)
Go seems like an exercise in frustration to me at the moment for anything GUI or low-level OS-related.
Many GUI libraries use an object model that's difficult to map onto Go's heavily restricted interfaces, especially with a lack of generics.
In addition, interacting with popular libraries (such as libsdl or even OpenGL) that use thread-local variables (TLS) means using ugly workarounds like this one:
So I think it really comes back to the "right tool for the right job." For most command-line utilities, and for anything networking-related, Go would be my first choice.
But for anything that needs a modern GUI toolkit and uses OpenGL, it would be difficult for me to justify.
Again, I love the model Go provides for programs and packages purely written in Go; it's only when interfacing with system-level components that I get cranky.
Go seems like an exercise in frustration to me at the moment for anything GUI or low-level OS-related.
Many GUI libraries use an object model that's difficult to map onto Go's heavily restricted interfaces, especially with a lack of generics.
In addition, interacting with popular libraries (such as libsdl or even OpenGL) that use thread-local variables (TLS) means using ugly workarounds like this one:
http://code.google.com/p/go-wiki/wiki/LockOSThread
So I think it really comes back to the "right tool for the right job." For most command-line utilities, and for anything networking-related, Go would be my first choice.
But for anything that needs a modern GUI toolkit and uses OpenGL, it would be difficult for me to justify.
Again, I love the model Go provides for programs and packages purely written in Go; it's only when interfacing with system-level components that I get cranky.