Why I’m Building a Simulation Engine in Rust

Python is the default tool for data science. We use it for exploration, modeling, and even production workloads. But that doesn’t mean it’s the right choice for everything.

Discrete-event simulation is where Python starts to show its limits. SimPy and similar libraries are great for prototyping:

Easy to learn
Let you express complex logic quickly
Open-source and flexible

But once you begin to scale, the cracks appear. Running millions of events across thousands of scenarios exposes Python’s overhead. What feels instant in a prototype becomes painfully slow at production scale.

So I’m exploring a different path by building a simulation engine from the ground up—in Rust.

Where Python + SimPy Hit Their Limits

The problem isn’t SimPy’s API or Python’s syntax. It’s the foundation they sit on.

When your simulation loop runs millions of events, micro-inefficiencies compound and run-time explodes.

Interpreter overhead: Every operation goes through layers of dynamism. Great for exploration, terrible for tight loops.
Garbage collection stalls: Large DES workloads create huge amounts of short-lived objects. Eventually the garbage collector stops everything to clean up, and performance nosedives.
The GIL: True parallelism is off the table. Multiprocessing adds enough overhead to erase most gains.
Cache-unfriendly memory: Python stores tiny objects across the heap. Your CPU spends as much time waiting as it does computing.

You don’t feel these pain points in toy examples. Run real large-scale simulations for supply-chain, logistics, healthcare, or call-center models, and Python becomes the bottleneck.

Why Not Just Use Proprietary Simulation Software?

The easy alternative is, “Just use Arena, AnyLogic, Simio, FlexSim.”

They’re capable tools, but there are may drawbacks:

Licensing costs are prohibitive.
GUI-driven modeling limits version control, code review, and automation.
Proprietary languages and DSLs lock you into one vendor’s worldview.
Closed internals: no visibility into why a simulation is slow.

These platforms serve a specific purpose, but they don't solve the issues that matter most to me: transparency, extensibility, real performance, and the ability to treat simulation models like software—not ad-hoc analysis trapped inside a GUI.

What Rust Brings to the Table

I needed high compute performance without low-level computing expertise.

Rust delivers exactly that:

Memory safety without garbage collection: No surprise pauses or jitter. Execution is deterministic and predictable.
Zero-cost abstractions: High-level Rust compiles down to the kind of instructions you could hand-write in C.
Real multithreading: The compiler enforces thread safety, so you actually get to use all your cores.
Control over memory layout: Critical for fast queues, object pools, and state machines that stay cache-friendly.

A simulation engine lives or dies by performance. Rust gives me the precision and efficiency I need to build something that doesn't slow down as models scale up.

Early benchmarks already show significant speedups over Python on common queueing models—and the design isn’t even fully optimized yet.

So Why Build My Own Engine?

Performance was the starting point, but it’s not the whole story.

I’m building this engine because I want:

A transparent, flexible core I can evolve without fighting the language.
A real software architecture, not a GUI that hides critical details.
True parallelism and predictable scaling.
A deeper understanding of DES internals—down to the queues, schedulers, and event semantics.

And yes, part of the motivation is the building something of my own. Rebuilding these fundamentals with modern tools is genuinely rewarding.

I hope this turns into something others use and rely on, but even the journey alone is growing my skills and knowledge.

What’s Next

I’m building the entire stack in the open—architecture decisions, benchmarks, demos, Python bindings, everything.

More posts, examples, and performance deep-dives coming soon.