4 ms·

What would be the primary benefit of emitting Rust rather than C? Both would be considered safe (assuming Wuffs generates correct code), and Rust could access t

by nequo 2y ago

What would be the primary benefit of emitting Rust rather than C? Both would be considered safe (assuming Wuffs generates correct code), and Rust could access the C code via FFI. Is there something I’m missing?

vlovich123 2y ago
Nominally it can safely elide bounds checks via unsafe that it has proved are actually safe within the constraints of Wuffs, which is what it does for C (+ the language is built for more easy translation to vectorizated than something like llvm is able to do for general purpose languages). So basically higher performance. FFI nominally has a runtime and compile time cost - whether that matters for you in particular will depend on your needs, but being able to publish a very simple crate without a build.rs to manage can have an attraction.
tialaramex 2y ago
I expect that the Rust emitted by a hypothetical future WUFFS transpiler would be much easier to just drop into an existing Rust project than some C via a C FFI. It's common for C libraries that do get wrapped today (e.g. openssl) to have a two phase wrapping, a -sys crate which turns the C into Rust C FFI and then another crate to turn the Rust C FFI into something actually palatable to ordinary people.
jcranmer 2y ago
The C abstract machine is slightly funkier than unsafe Rust (things like C lacking a way to do signed integer overflow without UB or needing to adhere to strict aliasing in C), so I would expect that lowering to unsafe Rust would be slightly more likely to be correct.
IshKebab 2y ago
Probably not too much from a "final product" point of view, but using a pure Rust library is a whole lot easier than C from a faff point of view. Especially for cross-compilation.
pcwalton 2y ago
One benefit would be that Rust users could use Wuffs code without having to install a C compiler. Pure-Rust solutions are much more convenient in the Cargo ecosystem than wrangling -sys crates.
- edflsafoiewq 2y ago
  You could also use c2rust.

by nequo 2y ago

vlovich123 2y ago

Nominally it can safely elide bounds checks via unsafe that it has proved are actually safe within the constraints of Wuffs, which is what it does for C (+ the language is built for more easy translation to vectorizated than something like llvm is able to do for general purpose languages). So basically higher performance. FFI nominally has a runtime and compile time cost - whether that matters for you in particular will depend on your needs, but being able to publish a very simple crate without a build.rs to manage can have an attraction.

tialaramex 2y ago

I expect that the Rust emitted by a hypothetical future WUFFS transpiler would be much easier to just drop into an existing Rust project than some C via a C FFI. It's common for C libraries that do get wrapped today (e.g. openssl) to have a two phase wrapping, a -sys crate which turns the C into Rust C FFI and then another crate to turn the Rust C FFI into something actually palatable to ordinary people.

jcranmer 2y ago

The C abstract machine is slightly funkier than unsafe Rust (things like C lacking a way to do signed integer overflow without UB or needing to adhere to strict aliasing in C), so I would expect that lowering to unsafe Rust would be slightly more likely to be correct.

IshKebab 2y ago

Probably not too much from a "final product" point of view, but using a pure Rust library is a whole lot easier than C from a faff point of view. Especially for cross-compilation.

pcwalton 2y ago

One benefit would be that Rust users could use Wuffs code without having to install a C compiler. Pure-Rust solutions are much more convenient in the Cargo ecosystem than wrangling -sys crates.

edflsafoiewq 2y ago
You could also use c2rust.