Hacker News Reader

Comment by shakow | Hacker News Reader

I'm curious to know what people find to be missing in the Rust/C interop? I only used it for a few simple functions, so I could not hit any hard points.

View on HN

Seeing how Zig has reimplemented the C preprocessor just to make C interop easier/smoother, there's always room for improvement beyond plain old function importing/exporting.

I of course, think that C FFI is as good as I personally need it to be. It's as good or better than most other languages that are not C.

Zig doesn't just implement the C preprocessor, instead the Zig compiler is also a C compiler, there are no separate compiler toolchains or build systems required for mixed Zig+C projects and you can directly import C headers into Zig source files.

I think C++ interop is the bigger deal than plain C. You end up needing to launder everything through C because of the lack of standard C++ ABI, plus there's a bunch of ergonomic awkwardness because C++ and Rust have a bunch of standard-library primitives that serve the same purpose but can't by passed by reference directly (vectors, slices, strings, tuples, etc.), and need to be manually marshaled back and forth if you have a Rust-flavored thing on one side but want to use a C++ library that expects C++-flavored things on the other.

I think at least for non-mutable stuff, C++ string_view (approximately rust &str), span (approximately rust slices), and the like should make at least some operations as simple as pointer casts, but having tooling to automate the boilerplate would be nice, and they're also new/not that widely supported (std::span is from C++ 20). And mutable stuff, if you want to be able to write idiomatic/ergonomic code on both sides, seems like a much bigger lift.

But this is the same story with pretty much every language, right? I remember dealing with some of the C++ interop layers in Common Lisp back about 10 years ago. All around an awful experience, and not really because of either CL or the interop layers themselves. It's just a boatload of complexity and the bigger the C++ library you want to target, the more likely it becomes that you have to deal with essentially all of the language.

Compare that to C, where the story is often as good as "import the header and you're done".

I'm not sure if there's a good path to a long-term solution, but I've been pushing to get nice C APIs in all the libraries I'm invested in, specifically because of this issue.

On Windows that solution is COM, which many consider dead, while it actually won the .NET vs COM wars during Longhorn, and was eventually improved with .NET type system (WinRT).

So while .NET type type doesn't cover all of C++, it does cover enough not to have clunky C interfaces, and nowadays many Windows APIs only have such COM/UWP interfaces as public API.

Microsoft is in the process of adding Rust to their COM/WinRT infrastructure.

One of the beauties of COM is that it is interface based component model, so it goes quite well with languages that have interfaces/traits as feature.

Calling simple and idiomatic procedural C interfaces [0] "clunky" and then contrasting them with the abomination that is COM is worthy of disagreement. Maybe the latter has its uses (I've never suffered enough through it to actually use it) but it definitely wins the clunkyness award. And that starts with its ridiculously unsearchable name.

[0] I really don't care if in C or a different language, but I'm not aware of relevant programming subcultures where that simplicity of interfacing is such an important pillar to their culture and their success.

With first class support (C++/WinRT, VCL, .NET) writing COM components is no different from ordinary C++ classes.

Yes, C is clunky and primitive, it was my opinion in 1992 coming from Turbo Pascal 6, and it hasn't changed since.

No different from ordinary C++ classes? (which are themselves more complex than what you need to suffer through with C)?

Seriously, here is just one taste of the intricacies of the COM: https://www.codeproject.com/Articles/9190/Understanding-The-...

This is 90's enterprise OOP technology. There is no good excuse to use this other than technical debt.

Naturally it is 90's enterprise technology, specially when you dig a 2005 article instead of a 2020 one.

There is no good excuse to use outdated articles to attack technology one hates.

Here, some 2020 stuff to educate yourself.

https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...

When I attack C's clunky and archaic coding, I do so with full knowledge of C17 and how little it has changed with K&R C that I learned in 1992, in API design and OS security.

Here is an example of good code (written in C) exposed as a library with a clean procedural interface. Nothing archaic about that.

https://github.com/rytc/enet_single/blob/master/enet_single....

COM is a solution to tunnel C++ interfaces through C APIs though, and it ceates a lof of complexity to support OOP APIs which should have been plain procedural APIs to begin with (compare the mess that is WinRT with the traditional Win32 windowing functions).

No one uses COM via C boilerplate unless they are masochists.

WinRT is no mess, and I look forward to the day everyone has to put up with them, now that both application models are being merged anyway.

Coincidentally, as an anecdotal data point, COM via C boilerplate (out of necessity) is all I've ever seen. And while it made me bloody angry each single time, I'm happy I didn't have to deal with the dogpile that was built on top of it.

There’s a project to help bridge Rust and C++ https://cxx.rs/

There is, but it doesn't go as far as something like SWIG for example. You can't point it at a trait and say "make a C++ class for that" or vice versa.

SWIG is what people really want.

Even C++ doesn't have proper interoperability with C++ ;)

IMHO going through C APIs is fine, because C++ interoperability is much harder and a moving target, just because the language surface is so much bigger than plain C.

See https://github.com/dtolnay/cxx as an example of the kind of things people are building to explore this space.

It should be possible to compile C code in a Rust project without an external C compiler, or it should be possible to import a C header into a Rust source file directly (so basically, creating separate "Rust bindings" for a C library shouldn't be required).

See Zig as an example for excellent C interoperability.

As soon as a C/C++ compiler toolchain and build tools need to be involved in a Rust project you're basically loosing all advantages of Cargo and are back to the relative brittleness of cross-platform C/C++ builds.

In my experience Rust/C interop just works except for variadic args. Variadic args require nightly unless it was stabilized since I last checked.

It hasn't required nightly for... I think ever? Unless I'm misunderstanding what you're asking for.

_Implementing_ a variadic function in rust requires nightly. I'm guessing that's what they meant. Calling one has been available for forever.

Ah yes, thanks. https://doc.rust-lang.org/nightly/unstable-book/language-fea...

(I was only thinking of calling)

Essentially people would like to be able to move seamlessly between idiomatic Rust and C (or even C++) without needing any manual intervention. This also would ideally include having an automatically safe API but this may require some glue on both sides of the API boundary.

Reply on news.ycombinator.com