3 ms·

Just dropping to C for a smallish segment of a rust program kind of makes sense if you want to eke out performance here, no?

by leoh 1y ago

bjackman 1y ago
You can always just use unsafe. This is about how to allow code to do this without unsafe blocks.
Arnavion 1y ago
It does, though even for a small segment you end up needing a lot of boilerplate - a dependency on the cc crate, a build.rs that invokes the cc crate, extern declarations to tell the Rust caller about the C function, potentially some bindgen if your small segment is not so small ... and you still end up having to do some amount of thunking between & / * / MaybeUninit because of that anyway. So if there is a "pure Rust" way to do it with `unsafe`, writing that is often easier. The pure Rust impl also has the advantage that you can validate it with Miri, unlike the C impl case because Miri cannot emulate arbitrary C code.
- leoh 1y ago
  This is a good point and perhaps points to an opportunity with cargo, macros, the rust language, or other aspects of the build system.
IshKebab 1y ago
Yeah but the C toolchain is a huge pain, and makes things like cross-compiling and compiling to WASM harder. It's really nice if you can keep your program pure Rust. Go has similar characteristics.
- nottorp 1y ago
  > compiling to WASM I thought Rust was supposed to be a systems language?
  - IshKebab 1y ago
    It is. And you can compile it to WASM.
- treyd 1y ago
  Go is in a much worse situation here since the toolchain doesn't give you any help with C dependencies. In Rust you can mostly just wrap the C library as a crate and the end developer doesn't need to care very much. If you want to use their system headers then you need to let them know, but that's not an issue if the headers are bundled. Cargo knows how to absorbs any C-built object files into the final binary and it just works. In Go, in every scenario, the end developer needs to go through the effort of managing all the necessary the cgo calls when any of their dependencies use C libraries, the whole way up the dependency tree. It's really really not supported.

Just dropping to C for a smallish segment of a rust program kind of makes sense if you want to eke out performance here, no?

by leoh 1y ago

Just dropping to C for a smallish segment of a rust program kind of makes sense if you want to eke out performance here, no?

bjackman 1y ago

You can always just use unsafe. This is about how to allow code to do this without unsafe blocks.

Arnavion 1y ago

It does, though even for a small segment you end up needing a lot of boilerplate - a dependency on the cc crate, a build.rs that invokes the cc crate, extern declarations to tell the Rust caller about the C function, potentially some bindgen if your small segment is not so small ... and you still end up having to do some amount of thunking between & / * / MaybeUninit because of that anyway. So if there is a "pure Rust" way to do it with `unsafe`, writing that is often easier. The pure Rust impl also has the advantage that you can validate it with Miri, unlike the C impl case because Miri cannot emulate arbitrary C code.

leoh 1y ago
This is a good point and perhaps points to an opportunity with cargo, macros, the rust language, or other aspects of the build system.

IshKebab 1y ago

Yeah but the C toolchain is a huge pain, and makes things like cross-compiling and compiling to WASM harder. It's really nice if you can keep your program pure Rust. Go has similar characteristics.

nottorp 1y ago
> compiling to WASM I thought Rust was supposed to be a systems language?
- IshKebab 1y ago
  It is. And you can compile it to WASM.
treyd 1y ago
Go is in a much worse situation here since the toolchain doesn't give you any help with C dependencies. In Rust you can mostly just wrap the C library as a crate and the end developer doesn't need to care very much. If you want to use their system headers then you need to let them know, but that's not an issue if the headers are bundled. Cargo knows how to absorbs any C-built object files into the final binary and it just works. In Go, in every scenario, the end developer needs to go through the effort of managing all the necessary the cgo calls when any of their dependencies use C libraries, the whole way up the dependency tree. It's really really not supported.