Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Integration with other languages #14
Rust's core support for interfacing with C is fairly strong, but wrapping a C library still involves tedious work mirroring declarations and writing C shims or other glue code. Moreover, many projects that are ripe for Rust integration are currently using C++, and interfacing with those effectively requires maintaining an alternative C wrapper for the C++ APIs. This is a problem both for Rust code that wants to employ existing libraries and for those who want to integrate Rust into existing C/C++ codebases.
For interfacing with "high-level" languages, there is the additional barrier of working with a runtime system, which often involves integration with a garbage collector and object system. There are ongoing projects on these fronts, but it's early days and there are still a lot of open questions.
Some potential avenues of exploration include:
While having more automatic binding to C would be nice, it would be much more useful if we could bind to C at all. The lack of
referenced this issue
Feb 8, 2017
I understand that to offer a C API is still necessary to reach many other languages who have not yet moved to C++. But it would be a wasted chance to not create a symbiosis between C++ and Rust as 1st class partners. Rust needs a proper C++ interface lib to gain momentum for the tool builders and millions of application developers out there who would like to just try Rust i their existing C++ project for a small task. This interface has to be comfortable, complete and rock solid and always up to date.
Another route for C/C++ integration that I have seen is to use Rusts macro system to allow somewhat seamless context switching between code in different languages. Notable example: https://github.com/google/rustcxx
A possible avenue for developing that approach would be to offer some specific language syntax integration to make it less verbose than in that crate, and usable with arbitrary languages.
To elaborate on my previous comment, I think there are two main ways to offer Rust integration with a different language:
Something like bindgen would fall under 1, while something like rustcxx would fall under 2.
Approach 1 would be the more ergonomic option from a user-of-the-API point of view, as you only need to know Rust to call functionality provided by a library in a different language. However, depending on language it might not be possible to generate the necessary Rust bindings automatically, requiring a lot of effort for the initial API translation and for maintaining the binding code over time. Examples here are dynamic languages where the interface is defined by runtime code, and C/C++, where the interface depends on things like which header files are included, and how much of it is actually documented as a public interface.
Approach 2 on the other hand would probably require to know both Rust and the language you are calling into, but be generally easier to implement, as there would only need to be support for the "context switching" into the other language, and not for every library written in it you want to call.
Approach 2 would also probably be a good basis to implement Approach-1 Rust bindings themself, as you would just wrap the language switching behind an API.
It seems to me that a lot of the "we use language X, and want to partially migrate to Rust" scenarios would be well served by approach 2, as you would be able to gradually move the API and dependency barrier between the two code bases instead of needing to maintain an explicit Rust API upfront or migrating all at once.
I explored Rust taking advantage of TypeScript.
Being able to pass in a trait reference into a function requiring a supertrait would be extremely helpful here. rust-lang/rust#5665