Hypothetical use of the Rust programming language

[stfnp]

Motivation

A few years ago I started a small prototype where I tried implementing some parts of this program in Rust. The language and its tooling are, in my opinion, very well designed and a great improvement over C++. But I also realized that the ecosystem of libraries was not yet mature enough for the task. Especially the options for scientific computing and GUI programming were lacking when compared to mature C++ libraries like Eigen and Qt.

There have been a lot of improvements since then, but many roadblocks still remain. So this issue is meant for keeping an eye on Rust, tracking any relevant developments and thinking about possible routes for a gradual transition.

Lacking areas

GUI Programming

• gtk-rs

  • Rust bindings for GTK
  • Probably the most mature option right now
  • Has relm4 for a more idiomatic programming style
  • Some people say GTK looks bad on Windows and macOS

• sixtyfps

  • Still relatively new, but very promising
  • Supports C++ and Rust, good for a gradual transition

• iced

  • One of the more mature pure-Rust alternatives
  • Still lacking lots of features

• egui

  • Immediate mode, which comes with advantages and disadvantages
  • Almost supports requirements already:
    • [x] Tree
    • [x] Table
    • [x] Plot
    • [x] 3D Graphics

Scientific Computing

• ndarray

  • Multi-dimensional array class similar to numpy.ndarray
  • Something like this might be needed in the future, the C++ alternative is Eigen's unsupported tensor module
  • Handles only dynamic arrays, no fixed-size

• nalgebra

  • General linear algbra library
  • Fixed-size and dynamic matrices and vectors
  • No multi-dimensional arrays
  • Sparse matrices still experimental

• Low-level bindings

  • OpenBLAS
  • LAPACK
  • SuiteSparse
  • Intel MKL

None of those, as far as I can tell, have anything similar to Eigen's expression templates.

Good areas

Serialization

• serde
  • Library for serialization and deserialization
  • No boilerplate thanks to #[derive(Serialize, Deserialize)]
  • json, msgpack and more

Tooling

• Built-in unit testing
• cargo-deb: Cargo subcommand for generating deb packages
• cargo-rpm: Cargo subcommand for generating rpm packages
• cargo-bundle: Cargo subcommand for generating bundles/packages for different systems (.app, .deb, .msi)
• flamegraph: Benchmarking

Utilities

• cached: Library for caching function results
• smallvec: Library for stack allocated vectors (similar to boost small_vector)
• rayon: Parallel programming

Possible routes for transition

Rewriting the whole thing in Rust at once doesn't make much sense. But since VirtualBow's solver, pre- and postprocessor have been split into three separate components, it would be possible to try and switch them one by one. The solver would be a good first candidate for this, because it needs no GUI and is ripe for a major overhaul anyway.

• Benchmark Rusts linear algebra libraries and bindings against Eigen and make a decision based on features and performance
• Remove remaining interdependencies between the C++ codebases of the solver and the GUI. Make the GUI call the solver via "extern C" instead (maybe even pass the data via json/msgpack).
• Rewrite the solver in Rust with the same C interface
• Keep the UI in Qt/C++ or look for alternatives
  • Rust libraries as listed above
  • Non-Rust alternatives like QML, Flutter, ...