Adding R bindings to sassy

[sounkou-bioinfo]

Hi,

Thanks for this great crate ! This pull request adds two distinct R bindings using the sassy create. A more idiomatic extendr based R binding and a more traditional Rust+ R's C API approach. The second approach allows us more facilities like reading bytes from R connections and greater performance (see benchmark results compared to wrapping the python library in R).

Feel free to ignore this pull request if it is out of scope. It is put as draft to see if it is of interest within the upstream repo

LLM usage: The code and documentation were written with Codex 5.5 xhigh within Pi coding Agent. We take responsibility of the output after testing and benchmark results.

Rsassy, sassyRS, and Python binding benchmark

• Machine and build details
• Input data
• Benchmarked calls
• Summary

This report compares the R-facing overhead of three bindings to sassy:

• Rsassy: R bindings through R’s native C API.
• sassyRS: an extendr prototype.
• Python sassy via reticulate: the published sassy-rs Python
  binding called from R with reticulate.

The benchmark uses a deterministic 1 Mbp DNA text by default, not the
tiny toy string used in examples. Exact and two-mismatch copies of the
query are inserted every 100 kbp so each binding has real matches to
return.

Machine and build details

The native benchmark build is expected to be installed before rendering
with:

RUSTFLAGS="-C target-cpu=native" SASSY_RUST_FEATURES=native-simd R CMD INSTALL r/Rsassy
RUSTFLAGS="-C target-cpu=native" SASSY_RUST_FEATURES=native-simd R CMD INSTALL r/sassyRS
uv venv --python 3.11 .venv-benchmark
uv pip install --python .venv-benchmark sassy-rs
export RETICULATE_PYTHON="$PWD/.venv-benchmark/bin/python"

field	value
system	Linux
release	6.8.0-78-generic
machine	x86_64
cpu_model	13th Gen Intel(R) Core(TM) i5-13500
R	R version 4.6.0 (2026-04-24)
platform	x86_64-pc-linux-gnu
RUSTFLAGS	-C target-cpu=native
SASSY_RUST_FEATURES	native-simd
RETICULATE_PYTHON	/root/sassy/.venv-benchmark/bin/python
cargo	cargo 1.91.1 (ea2d97820 2025-10-10)
rustc	rustc 1.91.1 (ed61e7d7e 2025-11-07)
python	Python 3.11.14
simd_flags	sse sse2 fma sse4_1 sse4_2 avx bmi1 avx2 bmi2 avx_vnni

Input data

batches	iterations_per_batch	warmup	text_length	pattern_length	k	inserted_matches	insertion_spacing
7	1000	2	1e+06	42	2	10	1e+05

Benchmarked calls

binding	batches	iterations_per_batch	text_length	pattern_length	k	matches	min_seconds	median_seconds	mean_seconds	p95_seconds	max_seconds	calls_per_second
Rsassy reusable raw	7	1000	1e+06	42	2	10	0.000267	0.000269	0.0002686	0.0002704	0.000271	3717.472
Rsassy reusable character	7	1000	1e+06	42	2	10	0.000273	0.000273	0.0002736	0.0002754	0.000276	3663.004
Rsassy one-shot raw	7	1000	1e+06	42	2	10	0.000277	0.000278	0.0002784	0.0002804	0.000281	3597.122
sassyRS one-shot raw	7	1000	1e+06	42	2	10	0.000409	0.000409	0.0004107	0.0004154	0.000416	2444.988
Python sassy via reticulate	7	1000	1e+06	42	2	10	0.000488	0.000490	0.0004901	0.0004930	0.000493	2040.816

Summary

binding	median_seconds	calls_per_second	matches
Rsassy reusable raw	0.000269	3717.472	10
Rsassy reusable character	0.000273	3663.004	10
Rsassy one-shot raw	0.000278	3597.122	10
sassyRS one-shot raw	0.000409	2444.988	10
Python sassy via reticulate	0.000490	2040.816	10

#> Wrote benchmark results to /root/sassy/r/benchmarks/results/r-bindings.csv

[RagnarGrootKoerkamp]

Do we need 57 modified files for this? Please shrink it to something a human can understand.

Do we need 3 APIs? That's just gonna make confusion and not help anyone. Going via python sounds silly. Otherwise I don't care which one you pick but please reduce it to 1. Would it make sense to have the same API as python?

Anyway yes, I'm open to merging R bindings. But you'll have to write short and to the point readme with usage instructions because I have never used R. Does it need pushing something to a registry? Do we need CI for that similar to python?

Side note: did you read your full PR? If not, why should i read it and what should the takeaway be? Dropping 4 tables on me without conclusion is useless.

(Ie: i don't mind AI code. But please no AI text.)

[sounkou-bioinfo]

Do we need 57 modified files for this? Please shrink it to something a human can understand.

Do we need 3 APIs? That's just gonna make confusion and not help anyone. Going via python sounds silly. Otherwise I don't care which one you pick but please reduce it to 1. Would it make sense to have the same API as python?

Anyway yes, I'm open to merging R bindings. But you'll have to write short and to the point readme with usage instructions because I have never used R. Does it need pushing something to a registry? Do we need CI for that similar to python?

Side note: did you read your full PR? If not, why should i read it and what should the takeaway be? Dropping 4 tables on me without conclusion is useless.

(Ie: i don't mind AI code. But please no AI text.)

The PR was read (and its text written by me), would be irresponsible otherwise.

There are no 3 APIs, but 2, the python roundabout (in process R-python interop via reticulate) is to get an interpreted code baseline and test conformance when applicable. This is common when a library does not offer R bindings.

The benchmark text is rendered via code https://github.com/sounkou-bioinfo/sassy/blob/19511d76fbb7cd7baeb7fff7c72a7e36b6974c22/r/benchmarks/benchmark-r-bindings.Rmd, i just copy past it. Conclusion is using low level Rsassy approach is the best way to go if speed were the only criteria. There are other criteria described below.

The R packages have README.md files generated from README.Rmd files. Other programmatically generated files are the .Rd files in man directories. These are standard literate programming practices in the R community that i agree bloat PRs.

The PR includes a workflow for testing following the current setup.

On the actual code surface removing generated artifacts for Rsassy.:

• One R file
• one C file,
• one rust lib.rs file

Rsassy is the low dependency setup i am comfortable with, i am not a rust developer, the R plumbing is done in C. But i guess it is not idiomatic rust work and it definitely is not as clean as the supported PyO3 binding.

On the api of the R binding, it is the same as with the python binding, with the following exceptions.

• We return data frames, which is the idiomatic R form
• We add altrep and connections support because raw bytes and strings are expansive in R. R Connections moreover give us for free compressed files (including in memory) support.
• The use of the sassy crate is non invasive, the R build will be self contained if we use the vendoring pattern in the remote situation of a CRAN submission. More on the registry issue below

On registry, adding a line on a personal or organization r-universe repo should be enough. I publish packages like this, example here https://sounkou-bioinfo.r-universe.dev/builds, The package can be published on CRAN, but they usually have very old rust edition requirements as this worker point out here https://bsky.app/profile/yutannihilation-en.bsky.social/post/3mm4ole6nmc2q

Bottom line, if the contribution is of interest, i will remove sassyRS package from this PR, remove the benchmarks and add Rsassy centered ci and and publish the package on r-universe (which include tests on multiple platforms and R versions)

Hopefully this response is informative and does not sound rude or is wasting your time

[RagnarGrootKoerkamp]

The PR was read (and its text written by me), would be irresponsible otherwise.

In that case I must apologize. Sorry!
(Unfortunately, I have had some AI-written PR descriptions recently, and I guess I was tired yesterday.)

There are no 3 APIs, but 2, the python roundabout (in process R-python interop via reticulate) is to get an interpreted code baseline and test conformance when applicable. This is common when a library does not offer R bindings.

I'm not fully following here. Could you explain more?

The benchmark text is rendered via code https://github.com/sounkou-bioinfo/sassy/blob/19511d76fbb7cd7baeb7fff7c72a7e36b6974c22/r/benchmarks/benchmark-r-bindings.Rmd, i just copy past it. Conclusion is using low level Rsassy approach is the best way to go if speed were the only criteria. There are other criteria described below.

That makes sense. It's hard for me to say which API would be best. In python, I think we now expose a batch API, so that the function-call overhead is relatively small anyway.

The R packages have README.md files generated from README.Rmd files. Other programmatically generated files are the .Rd files in man directories. These are standard literate programming practices in the R community that i agree bloat PRs.

Ah yeah ok that's just silly. If there's no R in there, only keeping the .md isn't good practice?

The PR includes a workflow for testing following the current setup.

Ah good. I think this could be simplified a bit though; no need to install rust, update system packages, and upload artefacts?

On the actual code surface removing generated artifacts for Rsassy.:

• One R file
• one C file,
• one rust lib.rs file

Rsassy is the low dependency setup i am comfortable with, i am not a rust developer, the R plumbing is done in C. But i guess it is not idiomatic rust work and it definitely is not as clean as the supported PyO3 binding.

Hmmm, I'm confused why this needs C. The rust crate already exposes C bindings; why do those not work directly? I guess this file is wrapping the C-API exposed in Rust in an R-style API. If that's standard than I guess it is what it is. But if something like PyO3 for R exists that would be nicer.

On the api of the R binding, it is the same as with the python binding, with the following exceptions.

• We return data frames, which is the idiomatic R form
• We add altrep and connections support because raw bytes and strings are expansive in R.

ok this is crazy but ok.

• The use of the sassy crate is non invasive, the R build will be self contained if we use the vendoring pattern in the remote situation of a CRAN submission. More on the registry issue below

On registry, adding a line on a personal or organization r-universe repo should be enough. I publish packages like this, example here https://sounkou-bioinfo.r-universe.dev/builds, The package can be published on CRAN, but they usually have very old rust edition requirements as this worker point out here https://bsky.app/profile/yutannihilation-en.bsky.social/post/3mm4ole6nmc2q

Not completely following here yet but that's OK.

Bottom line, if the contribution is of interest, i will remove sassyRS package from this PR, remove the benchmarks and add Rsassy centered ci and and publish the package on r-universe (which include tests on multiple platforms and R versions)

This sounds good! Could you make me co-owner just in case future updates are needed (when other people request it).

A further thing to keep in mind is that Sassy heavily uses SIMD instructions.
Is the R-package pre-compiled or compiled on the users machine?
In the first case, we should compile is with at least AVX-256 enabled (and optionally also AVX-512), and in the latter case we should enable native compilation.

Hopefully this response is informative and does not sound rude or is wasting your time

This was very informative! Thanks!

[sounkou-bioinfo]

The PR was read (and its text written by me), would be irresponsible otherwise.

In that case I must apologize. Sorry! (Unfortunately, I have had some AI-written PR descriptions recently, and I guess I was tired yesterday.)

There are no 3 APIs, but 2, the python roundabout (in process R-python interop via reticulate) is to get an interpreted code baseline and test conformance when applicable. This is common when a library does not offer R bindings.

I'm not fully following here. Could you explain more?

The benchmark text is rendered via code https://github.com/sounkou-bioinfo/sassy/blob/19511d76fbb7cd7baeb7fff7c72a7e36b6974c22/r/benchmarks/benchmark-r-bindings.Rmd, i just copy past it. Conclusion is using low level Rsassy approach is the best way to go if speed were the only criteria. There are other criteria described below.

That makes sense. It's hard for me to say which API would be best. In python, I think we now expose a batch API, so that the function-call overhead is relatively small anyway.

The R packages have README.md files generated from README.Rmd files. Other programmatically generated files are the .Rd files in man directories. These are standard literate programming practices in the R community that i agree bloat PRs.

Ah yeah ok that's just silly. If there's no R in there, only keeping the .md isn't good practice?

The PR includes a workflow for testing following the current setup.

Ah good. I think this could be simplified a bit though; no need to install rust, update system packages, and upload artefacts?

On the actual code surface removing generated artifacts for Rsassy.:

• One R file
• one C file,
• one rust lib.rs file

Rsassy is the low dependency setup i am comfortable with, i am not a rust developer, the R plumbing is done in C. But i guess it is not idiomatic rust work and it definitely is not as clean as the supported PyO3 binding.

Hmmm, I'm confused why this needs C. The rust crate already exposes C bindings; why do those not work directly? I guess this file is wrapping the C-API exposed in Rust in an R-style API. If that's standard than I guess it is what it is. But if something like PyO3 for R exists that would be nicer.

On the api of the R binding, it is the same as with the python binding, with the following exceptions.

• We return data frames, which is the idiomatic R form
• We add altrep and connections support because raw bytes and strings are expansive in R.

ok this is crazy but ok.

• The use of the sassy crate is non invasive, the R build will be self contained if we use the vendoring pattern in the remote situation of a CRAN submission. More on the registry issue below

On registry, adding a line on a personal or organization r-universe repo should be enough. I publish packages like this, example here https://sounkou-bioinfo.r-universe.dev/builds, The package can be published on CRAN, but they usually have very old rust edition requirements as this worker point out here https://bsky.app/profile/yutannihilation-en.bsky.social/post/3mm4ole6nmc2q

Not completely following here yet but that's OK.

Bottom line, if the contribution is of interest, i will remove sassyRS package from this PR, remove the benchmarks and add Rsassy centered ci and and publish the package on r-universe (which include tests on multiple platforms and R versions)

This sounds good! Could you make me co-owner just in case future updates are needed (when other people request it).

A further thing to keep in mind is that Sassy heavily uses SIMD instructions. Is the R-package pre-compiled or compiled on the users machine? In the first case, we should compile is with at least AVX-256 enabled (and optionally also AVX-512), and in the latter case we should enable native compilation.

Hopefully this response is informative and does not sound rude or is wasting your time

This was very informative! Thanks!

Thanks for the feedback ! I should re-open this issue then.

General note, after some benchmark work around the general FFI barrier crossing, in the generic case, using the RSassy approach is likely more fruitful long term. Two main reasons for this: performing parallel work in Rust with better guarantee compare to C and taking advantage of features not exposed to the current C API. Search_Many type of API is not exposed in sassy.h.

But as you said, using extendr or savvy ( a R.rs file) should eliminate the need for the manual C layer (this is a skill issue on my part now).

On registry and publishing, as a trial test, the current head of my fork that only contains Rsassy approach has been publish on my r-universe https://sounkou-bioinfo.r-universe.dev/Rsassy. r-universe is the less conservative way too publish Rust using R packages compared to CRAN (which for various reason has conservative approach toward Rust e.g strict rules around cargo https://cran.r-project.org/web/packages/using_rust.html). Setting up r-universe is fairly straightforward, https://docs.r-universe.dev/publish/set-up.html, the package could be own by a R-sassy or similar GitHub org or your own personal account.

The binary packages for these systems are made available

I am unsure about SIMD support on these runners ( i assume they all have at least avx2). But the users can always install from source and some adjustment to Makefiles should make sure the features are enabled when the CPU supports them.

Edit: on Plateform, it is interesting to know which SIMD architectures would work on WASM. The package now works on webR environment out of the box

[RagnarGrootKoerkamp]

On registry and publishing, as a trial test, the current head of my fork that only contains Rsassy approach has been publish on my r-universe https://sounkou-bioinfo.r-universe.dev/Rsassy.

oh neat! I think it's fine if you just own it. If/once we push to CRAN I think it makes sense for me to be co-owner, but if the package is namespaced to you, that's fine.

I am unsure about SIMD support on these runners ( i assume they all have at least avx2).

Supporting AVX2 is not necessarily enough to activate it during compilation. Here's some notes for how we did this with python / bioconda.

In src/python.rs, we expose the features() function that prints which CPU features are available and which were used during compilation. Would be great if you could add that too as it exactly helps for debugging this.

But the users can always install from source and some adjustment to Makefiles should make sure the features are enabled when the CPU supports them.

Yeah, but that's not really practical. Better to fix it properly.

Edit: on Plateform, it is interesting to know which SIMD architectures would work on WASM. The package now works on webR environment out of the box.

cool!

[sounkou-bioinfo]

On registry and publishing, as a trial test, the current head of my fork that only contains Rsassy approach has been publish on my r-universe https://sounkou-bioinfo.r-universe.dev/Rsassy.

oh neat! I think it's fine if you just own it. If/once we push to CRAN I think it makes sense for me to be co-owner, but if the package is namespaced to you, that's fine.

I am unsure about SIMD support on these runners ( i assume they all have at least avx2).

Supporting AVX2 is not necessarily enough to activate it during compilation. Here's some notes for how we did this with python / bioconda.

In src/python.rs, we expose the features() function that prints which CPU features are available and which were used during compilation. Would be great if you could add that too as it exactly helps for debugging this.

But the users can always install from source and some adjustment to Makefiles should make sure the features are enabled when the CPU supports them.

Yeah, but that's not really practical. Better to fix it properly.

Edit: on Plateform, it is interesting to know which SIMD architectures would work on WASM. The package now works on webR environment out of the box.

cool!

Multi-Versioning and simd support

I decided to go with multiple cross-compilations and ship the DLLs with the package and load specific simd backends at runtime. This should be a useful strategy more generally. The simd backend can be set dynamically, example scalar vs avx2 benchmark here

WebR will always be compiled with simd128. The Demo page for this can be found here https://sounkou-bioinfo.github.io/sassy-webR.

WebR related additions

Some local scripts to test the webR setup

Some additional changes for CRAN compatibility/compliance

• made the package use a vendor.tar.xz for offline installs
• added you as author of the package instead of cph only
• add some scripts related to the vendoring process including script to extract the Licenses and Authors of the Rust crates

The R package versioning will follow sassy_version-r_package-changes (with *.9000 convention for development versions)

[RagnarGrootKoerkamp]

There's still >45 files. Could you drop all generated files, and then add those in a single final commit? (Right now it's >5000 lines which is too much to review, and after it's probably still a lot.)

Which parts should I review and what can I skip? Did you check all (doc) comments? Should I check the API? (I guess I don't really care if it works for you?)

r-packages.yaml looks a bit bloated.

What's up with all the windows-specific files? Are those really needed?

Are all these cleanup configure and Makefile scripts really needed? Feels like this ought to be part of some R tooling rather than hardcoded here?

All this stuff in r/Rsassy/tools feels iffy too. Is all that really needed...???
I'm not very happy to merge vendored.tar.xz like that.

For python, we only have the src/py.rs for bindings, python/__init__.py for the lib, and 2 examples and 1 typing file.

---

In the end it might be simpler if you just put the code in a separate repo and we link it from the readme here? I don't really feel comfortable taking responsibility for this much code.

[sounkou-bioinfo]

There's still >45 files. Could you drop all generated files, and then add those in a single final commit? (Right now it's >5000 lines which is too much to review, and after it's probably still a lot.)

Which parts should I review and what can I skip? Did you check all (doc) comments? Should I check the API? (I guess I don't really care if it works for you?)

r-packages.yaml looks a bit bloated.

What's up with all the windows-specific files? Are those really needed?

Are all these cleanup configure and Makefile scripts really needed? Feels like this ought to be part of some R tooling rather than hardcoded here?

All this stuff in r/Rsassy/tools feels iffy too. Is all that really needed...??? I'm not very happy to merge vendored.tar.xz like that.

For python, we only have the src/py.rs for bindings, python/__init__.py for the lib, and 2 examples and 1 typing file.

In the end it might be simpler if you just put the code in a separate repo and we link it from the readme here? I don't really feel comfortable taking responsibility for this much code.

We will squash the commit history if/when the final pull request will be made. Rsassy can be put in an independent repository to make it non invasive. It will be clearer below why some of the bloat cannot be avoided.

Generic build system requirements and differences

Some notes about the generated files and the bloat compared to the python setup.

Given the setup used here, i followed exactly this layout for the R package https://github.com/r-rust/hellorust. R packages have a set of minimal requirements for submission to the common repositories (CRAN, R-multiverse, Bioconductor). Manual files are mandatory in all cases, Bioconductor would require having vignettes too. Build system files are required too.

For safety compliance, it is recommended that the package installation does not required network connections from external package managers (cargo here).

The r-universe submission https://sounkou-bioinfo.r-universe.dev/Rsassy does not have these restrictions since it is github hosted (soon Bioconductor too since the build system is being transferred to github). It is not a regulated repository and is indeed more like pipy. On CRAN and Bioconductor, all new Package are manually reviewed by humans and cannot violate the rules of these repositories.

Side note: i had a package removed from CRAN because starting from go 1.23 the go build system write things in the users go cache because of telemetry issue.

In All of these cases, unlike the python case, the only thing we control in the build system are the standard build files: configure scripts, Makevars. These files are required since we are building rust libraries.

The vendor.xz file is not required if the package is not submitted to CRAN. I figure even in case of a submission to CRAN, we can generate before submitting the build tarball. But it will need to be generated.

FIle Manifest in the current iteration

R Package Manifest

These files make the directory a package

r/Rsassy/DESCRIPTION
r/Rsassy/NAMESPACE (mandatory but generated from comments in search.R)

LICENCE AND AUTHORSHIP ATTRIBUTION and related tools

This is important for attribution and mandatory when one provide bindings to non ubiquitous library

r/Rsassy/tools/update-authors.R (script to generate the AUTHORS and Licence.note)
r/Rsassy/inst/AUTHORS (this is installed with the package in the user library)
r/Rsassy/inst/LICENCE.note (this is installed with the package in the user library, licence of the used crates, difference from the package Licence)

Package Top Level Documentation

r/Rsassy/README.md (generated from README.Rmd)
r/Rsassy/README.Rmd

CRAN Related

Vendoring

r/Rsassy/src/rust/vendor.tar.xz
r/Rsassy/tools/vendor-rust.R (development tool)

R's API

r/Rsassy/R/search.R (User API)
r/Rsassy/inst/tinytest/test-search.R (Test, bloated because of the multiversion issue)

R's C API plumbing

bloated because we are supporting multiversion and because C is verbose. Moreover we are not using extendr or savvy because of the multiversion issue and skill issue on my part. Usually these frameworks generate the *c and *h as the the R wrappers.

r/Rsassy/src/.c
r/Rsassy/src/.h

Rust Library

this is splitted for readability, overlly verbose because we are handrolling the FFI. Moreover it registers build features
for each DLLs we are builing.

r/Rsassy/src/rust/Cargo.toml
r/Rsassy/src/rust/src/*.rs

Some note related to multiversion, i may have misread something inside sassy, but since the SIMD is a crate wide feature, i could not use the function level multiversioning i used in this demo https://github.com/sounkou-bioinfo/hellorust-multiversion. Correct me if i am wrong here because we would not need to build a complicated runtime dispatch system that require multiple DLLs instead of one.

Function Level Manuals

r/Rsassy/man/*rd

On the rd files in man folder, these are generated from comments in the R files using roxygen2 package, i can consolidated them into one file but i have to either commit that file or accept a package dependency on roxygen2 tags to build them at package install time. Help files are mandatory for R packages (otherwise on get build warnings)

Mandatory build files

For building the package, If we support windows, these are required

r/Rsassy/.Rbuildignore
r/Rsassy/configure
r/Rsassy/configure.win (windows)
r/Rsassy/cleanup
r/Rsassy/cleanup.win (windows)
r/Rsassy/src/Makevars.in
r/Rsassy/src/Makevars.win.in (windows)
r/Rsassy/src/Rsassy-win.def (windows)
r/Rsassy/src/install.libs.R ( this is required since we are building DLLs for SIMD versions)

CI

The bloat is to test the platforms that we are supporting for the package: Linux, MacOS, Windows, WebR/WASM. If the OS_type is limited to Unix in the DESCRIPTION file, the file can be trimmed. Usually it is recommended in the current setup to test on expected user platforms and spot issues. R packages are expected to be installable on the three last R versions (academic setups were installations change more slowly)

[sounkou-bioinfo]

Rsassy is now hosted at https://github.com/sounkou-bioinfo/Rsassy/, the scope of the PR is one file change for documentation of its existance. After more testing on larger workloads and avx512 servers, i will start the fairly tedious process of a CRAN or Bioconductor submission

[RagnarGrootKoerkamp]

Thanks! Yes looks good like this :)

[sounkou-bioinfo]

Thanks! Yes looks good like this :)

Thanks !
i think something that i will try to perform- in line with the benchmark issues in the repo - is to compare RSassy with the bwa and bowtie solutions here https://github.com/crisprVerse

[RagnarGrootKoerkamp]

Oh, I hadn't heard of crisprVerse before. Please do! Would be cool if sassy can replace those and gain some more users :)

I saw your issue sounkou-bioinfo/Rsassy#1 and am watching that repo, so looking forward to the results.

[sounkou-bioinfo]

Oh, I hadn't heard of crisprVerse before. Please do! Would be cool if sassy can replace those and gain some more users :)

I saw your issue sounkou-bioinfo/Rsassy#1 and am watching that repo, so looking forward to the results.

Yeah, lot of esoteric Bioconductor Verses out there ! Only now Bioconductor is waking up to Rust for extending R, Zulip channel here https://community-bioc.zulipchat.com/#narrow/channel/518471-rust . Huge potential for modernising the classical workflow/packages. Cargo is a blessing compared to the C/C++ situation

[RagnarGrootKoerkamp]

(Ah the zulip needs an invite link. Feel free to mail me one if you think it's useful for me to read it.)