Why Rust Isn’t Ready for Engineering Software (Yet)

Created on August 15, 2025

2025   ·   CAE,   Scientific-Computing,   Rust,   C++,   HPC   ·   Simulation-tools,   Programming

I wanted to develop a feature-rich, open-source CAE application in Rust. Easy memory safety and performance a tier above garbage-collected languages? Sign me up. Finally, a way to escape the data races and the tyranny of C++ compilers that think "segmentation fault" is an acceptable personality trait.

I was ready to go all in — maybe even color my hair blue before writing my first lines in Rust. Rust seemed like my ticket to a modern, sane, productive development experience. Sure, I expected a few bumps along the way, but hey, Rust is supposed to make large projects easy, right? No big deal.

Then I started looking for Rust packages and libraries to actually build my software… and the cracks appeared fast. The options were mostly half-finished "work in progress" crates or abandoned passion projects that haven’t seen a commit since the end of COVID-19 lock down.

Need a CAD kernel like OpenCascade? Nope. A meshing library like Gmsh? Try again. A robust GUI toolkit like Qt? Not unless you’re ready to wrap it yourself and pray it compiles.

And then there’s integration with C++ or Fortran code — the stuff where decades of CAE development already live. What’s the point of jumping through hoops for Rust’s memory safety if you have to bind it to massive, battle-scarred codebases that don’t provide that safety?

It didn’t take long to realize my “options” in Rust were:

  1. Write every single library I need from scratch.
  2. Use unsafe bindings to the C++/Fortran libraries — completely defeating the whole point of using Rust in the first place.

So instead of reinventing the wheel, I grabbed my trusty C++ toolkit and got back to writing actual code — because at least there, I can get work done without pretending my build system is a research project.

Here’s why.

1. Interoperability With C++ and Fortran is a Minefield

Rust’s FFI works fine for plain C, but CAE libraries don’t live in a happy little C-shaped world. They live in C++ (templates, overloaded operators, inheritance) or Fortran (fresh hell arrays, anyone?).

Wrapping these in Rust means:

  • Writing hundreds of lines of unsafe glue code
  • Losing half the API because the C++ parts are too complex to map
  • Debugging segfaults that magically ignore Rust’s advertised memory safety

Examples:

  • Wrapping OpenCascade for geometry modeling? Weeks of header wrangling.
  • Calling PETSc or Trilinos from Rust? Back to the C API — less functionality, worse performance.

At that point, why not just write in C++ or Fortran?

2. MPI and HPC Support: Still Stuck in Hobby Mode

Most CAE solvers run on clusters — MPI isn’t optional. Rust has rsmpi, a thin wrapper over the C API, but:

  • No idiomatic integration with Rust’s async model
  • Spotty support for MPI-3 features like remote memory access and non-blocking collectives
  • Minimal adoption on vendor-tuned compilers (Intel MPI, Cray MPI)

Technically possible, practically painful.

3. GPU Acceleration: Brace Yourself

Modern CAE codes rely heavily on GPUs. CUDA, OpenGL, DirectX, Vulkan — GPU integration in Rust is still “aspirational.”

  • CUDA bindings (rust-cuda) are incomplete or lag NVIDIA releases
  • HIP and SYCL support? Almost nonexistent
  • Vendor math libraries like cuBLAS, cuSPARSE, cuFFT have no idiomatic Rust wrappers

You can write GPU kernels in Rust — if you want to reinvent half the CUDA driver API in unsafe. At that point, C++ is simpler.

4. Missing Mature Geometry, Meshing, and Visualization Libraries

CAE software is geometry and meshes. Rust’s ecosystem is sparse:

Want cutting planes, mesh overlays, stress maps? Either code them yourself in wgpu or wrap a C++ library — back in unsafe land.

5. Large-Scale Build & Tooling Woes

CAE projects combine Fortran solvers, C++ kernels, and potentially Rust. Cargo is great, but:

  • Poor integration with CMake, Bazel, and other multi-language systems
  • Debugging mixed Rust/C++ stacks is awkward with gdb or lldb
  • Profiling tools like Intel VTune or Arm MAP have weaker Rust support

When your workflow is “fight the build system” instead of “write features,” productivity suffers.

6. Long-Term Stability and Industry Risk

CAE software often lasts 10–20 years. Rust’s ecosystem moves fast:

  • Crates can break between releases
  • No guarantee today’s “best” bindings will exist in five years

Conservative CAE companies avoid constant rewrites. Stability matters more than novelty.

7. A Hopeful Future

Rust is growing. Rust still doesn’t have the production ready plug and play engineering libraries but it has seen rapid development in tools for building those libraries such as:

The community is actively building engineering capabilities — much like Python’s growth in scientific computing. Python succeeded for ease of use but faltered in runtime performance, which is why C++ and Fortran still dominate CAE backends but Python has taken over a large chunk of the less intensive frontends and data processing APIs. But Rust could challenge or even upend C++ and Fortran in the coming decades thanks to its combination of safety and high performance.

There are still some promising Rust projects that I am watching out for:

  • A developing CAD kernel: Truck
  • A good but not great GUI toolkit: gtk-rs

Challenges remain in engineering-focused meshing libraries and Rust-native MPI support.

Conclusion

Rust is exciting, safe, modern, and fun. But for CAE — where performance, interoperability, and mature ecosystems matter — it’s not ready.

Today, serious CAE projects thrive in C++/Fortran. Rust may eventually become a viable alternative, but for now, the tooling and ecosystem aren’t there yet.



Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • What I do & why