
FFI from Go to Rust - steveklabnik
https://github.com/medimatrix/rust-plus-golang
======
amelius
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](https://code.google.com/p/go/issues/detail?id=8310)

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

[https://github.com/golang/go/issues/8310](https://github.com/golang/go/issues/8310)

~~~
amelius
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.

~~~
enneff
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.

------
creichert
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](https://github.com/creichert/haskellrustdemo)
(Careful, it will not compile with rust 1.0 beta (use of unstable library
feature 'libc')).

~~~
burntsushi
> (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](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).

------
Nycto
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](http://nim-
lang.org/manual.html#foreign-function-interface)

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

~~~
samatman
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.

~~~
comex
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.

