Warning

This post was published 31 days ago. The information described in this article may have changed.

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Asked to give a talk: Rust for research support engineers. Any ideas?

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 posts - 2 participants

Read full topic

🏷️ Rust_feed