A problem with Go's FFI is that the Go folks haven't decided yet whether objects can move in memory. If that is the case, then storing a pointer to a Go object is a no-go, since the object the pointer points to may have moved when the pointer is dereferenced in a foreign function. See [1] for some discussion.

[1] https://code.google.com/p/go/issues/detail?id=8310

We have decided. Don't store pointers to Go objects.

https://github.com/golang/go/issues/8310

I only see "Disabling comments until we post our new proposal. We are still working on the wording."

I really hope the concerns that were raised on this issue-page are not simply ignored, and I hope that this new proposal allows for an efficient FFI interface.

No, they are not ignored. Comments were disabled because we are well aware of the problem space, so further discussion was not adding anything.

The garbage collector has been rewritten for 1.5 and work continues on that front. Once the tree has stabilised (we're in the stabilisation period of our release cycle now) we will have a better idea how to resolve this issue.

This is very cool. I'd be interested to see more data interaction and how to call a Go function from Rust.

I implemented a similar experiment with Haskell and Rust[0]. It does some simple math and also passes a Haskell callback function into Rust code. Unfortunately, I think we lose quite a bit of information by passing through C code (e.g. Rust's parametric polymorphism).

[0] - https://github.com/creichert/haskellrustdemo (Careful, it will not compile with rust 1.0 beta (use of unstable library feature 'libc')).

> (Careful, it will not compile with rust 1.0 beta (use of unstable library feature 'libc'))

FYI, `libc` is on crates.io: https://crates.io/crates/libc

Just add `libc` as a dependency in your `Cargo.toml` and you should be good to go on beta (assuming that was the only thing holding you back).

I spent a moment seriously considering whether I had time to submit a pull request adding a Nim layer:

http://nim-lang.org/manual.html#foreign-function-interface

Or you could just use Nim rather than Go or Rust, and get high performance, clean code, and extremely easy C FFI.

I wish this crowd could recognize a constructive comment. Nim is a legitimate alternative to trying to shim Go and Rust together.

I still think it's cool that the OP tool exists, that's not my point.

The comment as written is perfunctory and has a dismissive tone - it would be more constructive if it went into more detail and avoided that tone. I'd also say it's off topic to some extent, since nobody has actually claimed that architecting an app from scratch in a combination of Go and Rust (as opposed to using existing {Go, Rust} code from the other) is a good design - although I can imagine someone might think it is.

Did you even browse the link? TFA is not a tool, it's 10 LOC showing how to build a shared library in Rust, and how to use it from Go via the cgo FFI.