I had a nice comparison because I first tried to do a native implementation in C++ and - wanting to do some custom low-level "stuff" for my simulation actor system (related to allocation and networking) - I ran into so many footguns that it slowed me tremendously. As soon as I tried to do the same with Rust, it was a breeze and I was able to write a lot of unsafe code that does very particular things that I need, while exposing a completely safe API for the rest of the engine and game. Being then able to also use Rust in the browser quite seamlessly with WASM allowed me to have a super straightforward and high-perf communication channel between the simulation backend and browser UI. The only real Rust disadvantage that hurts a lot is compile times. Sometimes I do fight types/the borrow checker, but only when I try to do weird things, in general I perceive it as a huge help in scaffolding things.
Very nice, how did you decide on your simulation? did you build a generic simulation engine you can reuse, or is your simulation tightly coupled to the objects you are simulating? It's fun seeing this, I have been recently thinking of a simulation game and wondering if to use a generic simulation library such as SimPy
I build a simulation engine, based on a high performance distributed actor system library I wrote for just this purpose. It is generic, but a lot of the performance trade-offs are with Citybound's needs as the main driver.
Their actor implementation / event loop works on a higher level than mine. Mine is super simplistic intentionally to offer high performance. Being optimised for cache locality, processing similar actors in batches, using custom allocators and having encoding-free communication, it has many parallels to data-driven game engine design or even entity component systems.
First time I hear about compile times being an issue with Rust.
Is that a general problem with bigger projects or can you identify language features that add specifically to the problem?
First compilation is slow. After that it’s much better during development times. This can mean that ci can take a ton of time if you don’t do even the smallest bit of optimization.
Wow, I get frustrated and feel unproductive if my feedback loop is longer than 2-5 SECONDS. This must require a seriously different approach to trial and error exploration
A lot of that is done in a simulator on the computer, which usually builds very quick once you get the environment and simulation scripts written.
The full build to a bit file that can be loaded into hardware is an NP-hard optimization problem, so as your design approaches the limits of either the desired clock speed or the amount of space in the chip, it can become very slow.
I've heard that long warm compilation times can be mitigated by breaking up code into separate modules so it doesn't recompile e.g. the actor system every time you adjust a layout. Basically caching works best on the module boundary. Is this something you've explored?
Yes, I factored out quite a bit of generic parts of the engine into libraries and took some steps to cut down on number of generics being instanced (which was one of the main drivers of compile time). Now I'm left with pretty much the game core, which is highly interdependent and thus nearly impossible to break up into crates (they can't mutually depend on each other). And it's still kinda slow.
I've splitted a 20k+LOC Rust project into multiple crates and compilation time improved a lot (still slow compared to other languages) but it's now manageable.
