6 ms·

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.

by shakow 6y ago

eptcyka 6y ago
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.
- deleted 6y ago
  [deleted]
- flohofwoe 6y ago
  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.
steveklabnik 6y ago
See https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx as an example of the kind of things people are building to explore this space.
ChrisSD 6y ago
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.
apendleton 6y ago
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.
- eslaught 6y ago
  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.
  - pjmlp 6y ago
    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.
    - jstimpfle 6y ago
      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.
      - pjmlp 6y ago
        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.
pirocks 6y ago
In my experience Rust/C interop just works except for variadic args. Variadic args require nightly unless it was stabilized since I last checked.
- steveklabnik 6y ago
  It hasn't required nightly for... I think ever? Unless I'm misunderstanding what you're asking for.
  - Dr_Emann 6y ago
    _Implementing_ a variadic function in rust requires nightly. I'm guessing that's what they meant. Calling one has been available for forever.
    - steveklabnik 6y ago
      Ah yes, thanks. https://doc.rust-lang.org/nightly/unstable-book/language-features/c-variadic.html https://doc.rust-lang.org/nightly/unstable-book/language-fea... (I was only thinking of calling)
flohofwoe 6y ago
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.

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.

by shakow 6y ago

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.

eptcyka 6y ago

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.

deleted 6y ago
[deleted]
flohofwoe 6y ago
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.

steveklabnik 6y ago

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

ChrisSD 6y ago

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.

apendleton 6y ago

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.

eslaught 6y ago
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.
- pjmlp 6y ago
  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.
  - jstimpfle 6y ago
    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.
    - pjmlp 6y ago
      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.

pirocks 6y ago

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

steveklabnik 6y ago
It hasn't required nightly for... I think ever? Unless I'm misunderstanding what you're asking for.
- Dr_Emann 6y ago
  _Implementing_ a variadic function in rust requires nightly. I'm guessing that's what they meant. Calling one has been available for forever.
  - steveklabnik 6y ago
    Ah yes, thanks. https://doc.rust-lang.org/nightly/unstable-book/language-features/c-variadic.html https://doc.rust-lang.org/nightly/unstable-book/language-fea... (I was only thinking of calling)

flohofwoe 6y ago

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.