Hacker News Reader

Comment by agentgt | Hacker News Reader

Has anyone successful linked to a Rust library from another language (ie Python). I know Rust offers FFI and will apparently make its data representations C like if annotated and I think has some ABI.

This is the second post I have seen in the last couple of days of "glibc is bad lets rewrite it in Rust". However the problem is not that glibc is just bad but rather everything links to it. If other languages can't talk to Rust easy this would be a nicer problem to focus on first (before rewriting glibc).

I guess this is sort of how its done: http://siciarz.net/24-days-of-rust-calling-rust-from-other-l...

Rust -> C <- Other language. You have to create the C header files (I'm surprised Rust compiler or something similar doesn't automate this).

View on HN

I wrote a simple example of calling out into Rust from Python using cffi: https://github.com/maciejkula/python-rustlearn.

The gist of it is: it's really easy.

I don't know when this was last updated, but:

http://jakegoulding.com/rust-ffi-omnibus/

It's got a nice breakdown of how to bring rust libraries into a few languages. There are a few tutorials about how to make rust produce a static or shared library, but it's pretty straightforward.

You don't necessarily need C header files. Rust is able to export symbols easily with the C ABI; if your language has the ability to take a library and call such symbols (Python/Ruby do; for example), you're fine. It's only C++ where you need a header file because that's how C++ binds with any library. It's not a Rust-to-any-language issue, header files are a Rust-to-C++ issue only; really, an any-language-to-C++-or-C issue (I think such a tool exists, too).

A C header is not needed at runtime, it is purely a way to easily describe the symbols in a library that exist in a (somewhat) type-safe way. It's the lingua franca for describing libraries, and tooling (such as Rust's bindgen, or Python's cffi) can consume them to do the setup/create the information necessary to call functions from other languages. This is much nicer than manually trying to transcribe the Rust (or whatever) signatures into your application.

> header files are a Rust-to-C++ issue only

Or... C? (And of course other languages too, as just discussed.)

> It's the lingua franca for describing libraries, and tooling (such as Rust's bindgen, or Python's cffi) can consume them to do the setup/create the information necessary to call functions from other languages.

Hence the "not necessarily" in my comment. The parent seemed to be painting this as extra unnecessary work; I was saying that a header file is _not_ necessary except for binding to C/C++.

If you want to write a C API that will be called from many languages; you should have a header file so that bindgen tools can consume it. If you want an API that will only be called by Python .... not so necessary, you may want a header file anyway but it depends on the situation.

> Or... C?

Sure, goes without saying :)

Too late for me to edit, but regarding the C header file situation, this tool has been around for a bit:

https://github.com/Sean1708/rusty-cheddar

I haven't used it personally, but it looks useful.

Skylight[1] from what I understand is a ruby gem written in Rust. It monitors your ruby runtime and sends the data to the central servers for analysis.

1: https://www.skylight.io/

It was also one of the first production uses of Rust.

Reply on news.ycombinator.com