[R-pkg-devel] R, Rust and CRAN

[Simon Urbanek]

Jeroen,

sorry, I think you misunderstood: CRAN machines have the compilers, but the packages were not detecting it properly and/or were violating the CRAN policies as noted, so that's why I was saying that it would make sense to have a unified approach so that each package author doesn't have to make the same mistakes over again.

Cheers,
Simon


> On Nov 13, 2022, at 7:27 AM, Jeroen Ooms <jeroen using berkeley.edu> wrote:
> 
> On Sat, Nov 12, 2022 at 12:49 AM Simon Urbanek
> <simon.urbanek using r-project.org> wrote:
>> 
>> this does not directly address your question, but I think it would make a lot of sense to standardize the process, given how many issues there were with packages using Rust (mainly not detecting compilers correctly, not supplying source code, unsolicited writing into user's directories, not checking binaries etc.). Doing this right is not entirely trivial which is presumably where the "friction" comes from.
> 
> All we need is the rustc/cargo toolchain to be installed on the CRAN
> win/mac builders (it already is on Fedora/Debian). As mentioned above
> (and before in e.g. https://jeroen.github.io/erum2018), rust uses the
> native C FFI, does not need any runtime library, and can be called
> directly from an R package using the C interface.  There is really no
> need for frameworks or engines (like Rcpp/rJava/V8), this is precisely
> what makes Rust so nice as an embedded language, and why it is being
> adopted in many C projects such the Linux kernel, that would never
> want to deal with Java/C++/JS.
> 
>> I'm not a Rust user myself, but just based on the other languages that have interfaces from R I would think that Rust users could coalesce and write a package that does the heavy lifting and can be used by packages that contain Rust code as a foundation - that's what most other language interfaces do. (It's quite possible that some of the projects you listed would be a good start). I would not recommend putting that burden onto each package author as it screams maintenance nightmare.
> 
> I understand the sentiment but Rust is very different from e.g. Java.
> There really isn't much "heavy lifting" to do, because there are no
> complex type conversions or runtime library involved. If the same
> structs are used in C and Rust, the C functions can directly call Rust
> functions and vice versa. Therefore it is possible for libraries to
> incrementally port pieces of C code to Rust without breaking the ABI.
> Just have a look at the hello world examples such as:
> https://github.com/r-rust/hellorust or for a real world example:
> https://cran.r-project.org/package=gifski
>