[kyrra]

The most common solution in go is to use cgo[0] when wanting to bind with another language. From C you can then do whatever you'd like. That's how people are interacting with OpenGL[1] or QT[2] for example. Though, it seems like most common use cases of Go are to stay within the libraries supported by the shipping library or 3rd party libraries written in pure Go.

[0] http://golang.org/cmd/cgo/

[1] https://github.com/go-gl/gl

[2] https://code.google.com/p/goqt/

[kasey_junk]

Right, but how is that different than JNI?

For instance one of the major complaints about the JNI is that adds a pretty high performance penalty to any native calls (and typically you want native calls when performance is important). Does Go's FFI not have this performance penalty? If not, why not?

Like with the JNI, Go's garbage collector needs to understand life cycle semantics of objects coming in/out of the native binding, how is this accomplished and does it do a good job? Does it complicate the garbage collection of other unrelated parts of the system?

Basically, if you are going to claim that the JNI is awful (and I think that is a valid claim) and then imply that Go's isn't, I'd like to know why that is.

[Zariel]

The go runtime will manage memory of thins allocated in Go land but you must manage memory in C land.

If you allocate memory using C.malloc you must use C.free otherwise you will leak memory.

[kasey_junk]

Which again is very similar to JNI. I'm genuinely curious as to how Go's FFI differs from Java's to make that a distinguishing characteristic between the 2 languages.

[twic]

So how can native code get access to objects on the Go heap?