libguestfs ≥ 1.23.7 now has almost completely functional golang bindings.
So what (you are probably not asking) did I like and dislike about Go? There are some good points:
- Very fast compilation
- Interoperability with C
- Compiles to native code
- Appears to have proper garbage collection
Unfortunately I think that, like Vala, it’s a bit of a missed opportunity to fill the C replacement niche. It looks as if the language designers have never used a functional language, or if they did, they didn’t “get” it. Some of the real downsides include:
- No type inference. Because obviously it’s 2013 and I want to write types everywhere.
- Bondage-and-discipline, but in odd ways and to no apparent benefit. Like what’s the point of all the odd rules around
:=vs=, and what types you can and can’t assign and pass to functions? And why do you have to declare imports, when the compiler could work them out for you (it’ll even moan if you import something which is not used!) - Hello, world is about 8 lines of code. Camel case! Java rang, wants its boilerplate back.
- No breakthrough on error handling.
- The whole design of GOROOT/GOPATH is completely broken. It’s actually worse than Java’s broken CLASSPATH crap which is some kind of achievement, I guess.
They refuse to add exceptions (probably a good point), but the alternative is C-style error checking on every other line. It’s not even enforced error checking, so bad programmers will still be able to write bad code. And there are good ways to handle errors, eg. process-based transactions, Erlang-style, etc. But that seems to have passed them by.
Oh well, there’s still room for the breakthrough C replacement language.
Richard WM Jones 
Well, there is at least some kind of type inference on assignment (eg x := 5)… And exceptions can be “emulated” using panic and recover. Declaring imports allows you to “rename” them if needed, auto inference of the import would not be possible in the case where you have two packages a/x and b/x (x would be the namespace then in the code).
Now I’m not arguing that Go is perfect, but some of the points above looked a bit unfair to me 🙂
:=hardly counts as type inference. It’s the same asautoin C++.Interesting. I really like go. Having written some Vala projects, I can compare with that and to me it feels like the best “C-replacement”.
But on the type note – is it really important to have “real” type inference? Because this is really not C/C++. Except primitives, there are actually no types. It’s really dynamic duck typing. Who wants “real” types in 2013? Or I am missing your point.
Good work on those bindings. Thanks!
Go is strongly typed (stricter than C).
The type system is, deliberately it seems, not very rich. For example there seem to be no enums/variants or unions. Anyway there doesn’t seem to be anything that Hindley-Milner type inference couldn’t handle.