According to my limited experience (small tools such as a process monitor linking to libproc) it is astonishingly easy and convenient to call C code from Go: no need to write bindings, as Cgo allows to access C symbols directly from Go. I would be interested in what are the difficulties when dealing with larger projects.

For illustration, here's how I call the openproc() function from libproc:

    import (
	/*
	 #cgo LDFLAGS: -lproc
	 #include <proc/readproc.h>

	 PROCTAB* my_openproc(int flags) { return openproc(flags); }
	 */
	"C"
    )

    func parse_procs() {
        proc := C.my_openproc(C.PROC_FILLUSR | C.PROC_FILLCOM | C.PROC_FILLSTAT)
        ...
    }

This illustrates one issue I found with Cgo: calling functions with variable number of arguments is not supported. I had to define a new C function "my_openproc" with a fixed number of arguments, which you can see in the metadata of the import statement. It also includes the compiler and Cgo directives that make editing a Makefile unnecessary. The code for the whole tool is contained in one Go file.

> It's a royal pain writing go that talks to C code, compared to say, lua or python

This is plain wrong, you can pretty much call C code directly, while in Python and the like you really have to write a wrapper.

Of course in Go you will write a wrapper anyway to give the library a more Go-like API, but I don't see how this could be any worse than in any other language.

> there just _isnt_ a way to make other languages pickup go libraries and run the symbols from them afaik...

To get non-Go code to call Go code is trickier (also Go really wants to run your main()), but can be done, and there are even libraries to write Python extensions in Go, see:

http://gopy.qur.me/extensions/

Also, there's assembly. http://stackoverflow.com/a/6535590/131264

There's no single definition for Serious Work. It's just an insult to belittle people whose work is different than your own.

Let me help you out so you don't feel belittled or insulted. Serious Work is anything that will ever leave the confines of my experimental system to be used, viewed, or edited by anyone else. Doesn't matter if it's a trivial script-like tool or if it's a complex app.