Hacker News Reader

Comment by datalus | Hacker News Reader

Rust has good C interoperability. So from C++ it’d look like a C library. You can either write your own glue code or use something like cbindgen to autogen the header file.

View on HN

Many interesting SDKs come with C++ APIs that aren't necessarily translatable to C. Choosing Rust for engine development has the potential of severely hamstringing the team. It is the same tough uphill battle for all languages that aren't C++. Even more so now that the smoke is slowly rising from the battlefield of licensed engines and only a few contenders remain standing. And all of them have a massive C++ codebase and litttle incentive to toss that out.

If there will be a transition to any other language in that space, it'll take a decade or two.

There is an effort to automate generating mid-level C bindings for C++ code automagically, to enable easier wrapping in high level Rust APIs, by an unofficial Academy [of Motion Pictures] Software Foundation group. It is called C++-- [1].

At this time we only target the VFX C++ ecosystem but I'd be surprised if people wouldn't use (and extend) this to cover a broader set of C++ libs.

Maybe you can give an example of a C++ API that you deem not "translatable to C"?

[1] https://github.com/vfx-rs/cppmm

That's kind of hilarious given the role that C++ to C compiler had in the early development of the language [1]. But sounds useful, thanks for the link.

[1] https://en.wikipedia.org/wiki/Cfront

There is also this, [1], which wasn't on my radar until today:

"Corrosion, formerly known as cmake-cargo, is a tool for integrating Rust into an existing CMake project. Corrosion is capable of importing executables, static libraries, and dynamic libraries from a crate."

[1] https://github.com/AndrewGaspar/corrosion

For example, OpenVDB uses templates with user provided arguments at the very heart of its tree structure. Similar things happen in PCL and CGAL. They are template-heavy libraries by design.

OpenCV on the other hand seems to instantiate all possible variants of cv::Mat for their Python bindings. They don't such a big space of valid and useful template parameters and IIRC the specifics are abstracted away from the algorithms working on them.

True, Google is at least trying to make it easier to bind to C++ [0]. It's still pretty experimental, though.

0: https://github.com/google/autocxx

Interestingly, somebody pointed out in a previous discussion that a potentially significant interoperability hurdle (which is the case for the Qt libraries) is that, if a library makes use of multiple inheritance levels, it translates poorly into any language not supporting inheritance.

Reply on news.ycombinator.com