Asked to give a talk: Rust for research support engineers. Any ideas?

help
1

I’m preparing a 30-minute internal talk for a research support engineering (RSE) audience at a European technical university. The topic is whether it makes sense for our team to add Rust to the set of technologies we can reasonably support across many research groups (from computational-heavy labs to groups that mostly live in Python/R/Excel and just need “enough software” to move faster).

I’m looking for practical experiences that can help me present a balanced, decision-oriented view. I’m not trying to argue “Rust everywhere,” but I also don’t want the discussion to devolve into “why Rust should be banned.” What I’d really like is: where Rust is a strong fit in an RSE context, where it’s a poor fit, and how teams have navigated that boundary.

If you’ve used Rust in research software or research-support settings, I’d love to hear:

  • What kinds of projects did Rust pay off for (e.g., performance-critical components, robust tooling, reproducibility, deployment)?
  • If Rust wasn’t the right choice in a case, are there adjacent areas where it would have been a good fit (e.g., move a single component to Rust, keep Python for orchestration)?
  • What adoption path worked best: CLI tools, libraries used from other languages, services, or complete applications?
  • What onboarding/training approaches worked for a mixed-experience team?
  • Any university-environment gotchas?

Context note: we also have some people on campus who work deeply on Rust itself and typically don’t need much support from our team — so I’m mainly interested in Rust as a tool for research software across other disciplines, not “Rust language research.”

Thanks for any experiences or pointers!

2

There is this report from EPCC in Edinburgh that investigates Rust in HPC by comparing the performance of a simple CFD application written in Rust to reference implementations in C and Fortran. Hope that helps in terms of ideas or references for your talk.

My opinions on the report. Paragraph needs the context of the report as I'm too lazy to summarize it.

While the conclusion of the report states that Rust's memory safety approach can be problematic in HPC, based on discussions I had with the author after publication I believe the conclusion should rather be that Rust's memory safety approach must be taken into account in terms of developer knowledge and time. I wanted to investigate the Rust implementation used for the test and see if I could avoid any unnecessary cloning for the parallel implementation—which is the cause of the parallel Rust implementation being slower that the C and Fortran versions—, but I lost track of that. So take my opinions with a grain of salt, but I do think Rust can be as fast and that at the end of the day, memory safety is a good thing everywhere, including HPC.[1]

  1. Which may not suffer much in terms of memory safety bugs that can be exploited, but it still sucks if you get a segfault 24 hours into your simulation, after wasting lots of time and resources. ↩︎

1 Like
3

Thanks @jofas, exactly kind of help I am looking for.