Porting to Rust

[Grimelios]

Hello!

My question is somewhat open. I've enjoyed using Bepu with C# quite a bit, so I'd like to keep using it with Rust. The way I see it, there are two clear options in that regard:

1. Call into C# code from Rust.
2. Port Bepu to Rust.

Ross, I recall reading on a forum (I think for Bepu v1) that you considered writing the engine in Rust. Given this, I figured that before diving in, I'd ask whether you have any broad opinions surrounding either option. My thinking is as follows:

1. Two benefits here. First is that setting this up (Rust that calls into C#) is probably faster and easier than porting the engine. Second is that the engine remains untouched by me, which avoids the possibility of mistakes during the port.
2. Clear benefit here is performance, with a minor secondary benefit of using more idiomatic code for Rust. Downsides include the time and effort of a port, along with the (not insignificant) possibility of mistakes on my part that may be difficult to catch, especially if parts of the C# code don't translate cleanly to Rust. If I go this route, I'm hoping that most of the codebase will reasonably track one-to-one, especially given that Bepu is somewhat non-idiomatic for C# anyway (e.g. with frequent use of unsafe code, low-level memory management, and structure references).

I'm happy to port Bepu myself, if only for personal use. Figured that asking your opinion early might save me a lot of potential pain down the road.

Thank you!

[RossNordby]

While most of the core data processing bits would port over ~easily, a lot of the bookkeeping would make you want to tear your hair out in rust. Or C#, for that matter. There's a lot of incredibly complicated parallel shared state; a port would realistically have to abandon any pretense of compiler-enforced safety. A lot of it is slated for a revamp, but even then, oof ouch owie.

I would not recommend writing a port with an expectation of performance improvements. If they exist at all, they'll be small and primarily relevant in corner cases, like cache-sized simulations.

There's already a partial C API and a partial C++ wrapper over in the scratchpad: https://github.com/RossNordby/scratchpad/tree/main/Abomination/AbominationInterop

It doesn't yet support constraints and a bunch of other features, but even if you had to add all of them yourself, it would be two to four orders of magnitude less work than porting the whole engine.

I intend to get the C API completed eventually, but I'm not sure on the timeline. If certain companies throw a bunch of money at me to do it, I'd be able to do it a lot faster, but I put the chance of that around 20%.

[Grimelios]

Appreciate the quick response. Your work continues to impress me. I'll plan to look into the scratchpad at some point, then.

Have a good one!