5 ms·

It’s an interesting idea for sure but it isn’t a general purpose language, so the problem domains it can solve is very very different vs what Rust is trying to

It’s an interesting idea for sure but it isn’t a general purpose language, so the problem domains it can solve is very very different vs what Rust is trying to do.

tialaramex 2y ago
Nigel has said that emitting "unsafe" Rust is a reasonable thing for a hypothetical WUFFS 1.0 to be able to do as an alternative to C. As with good "unsafe" Rust written by humans WUFFS would know exactly why what it's doing is fine, it's just that the Rust compiler can't necessarily see that, hence the need to label it "unsafe". Today C makes most sense given the WUFFS language is still in flux. [Edited to fix a serious typo]
- 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.
- vlovich123 2y ago
  I’m responding to this: > that can then be shipped like normal C, so you don't get the ecosystem friction like with ex. Rust. Emitting Rust doesn’t help with this.
  - tomjakubowski 2y ago
    it helps in the other direction: less friction to use from rust
    - fiddlerwoaroof 2y ago
      But more friction to use from just about every other language.

It’s an interesting idea for sure but it isn’t a general purpose language, so the problem domains it can solve is very very different vs what Rust is trying to do.

tialaramex 2y ago

Nigel has said that emitting "unsafe" Rust is a reasonable thing for a hypothetical WUFFS 1.0 to be able to do as an alternative to C. As with good "unsafe" Rust written by humans WUFFS would know exactly why what it's doing is fine, it's just that the Rust compiler can't necessarily see that, hence the need to label it "unsafe". Today C makes most sense given the WUFFS language is still in flux. [Edited to fix a serious typo]

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.
vlovich123 2y ago
I’m responding to this: > that can then be shipped like normal C, so you don't get the ecosystem friction like with ex. Rust. Emitting Rust doesn’t help with this.
- tomjakubowski 2y ago
  it helps in the other direction: less friction to use from rust
  - fiddlerwoaroof 2y ago
    But more friction to use from just about every other language.