Golang bindings for libguestfs

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.


Filed under Uncategorized

4 responses to “Golang bindings for libguestfs

  1. akismet-cb6e2f69f5e49d2f14d4bc3935d6e90d

    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 🙂

  2. 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!

    • rich

      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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.