The Rust programming language is an ideal fit for implementing the mission-critical core of the platform and systems. This is because Rust will ensure that it is free of memory errors and data race conditions, being ‘correct by construction’ through its formal specification of types, ownership and lifetimes at compile time.
Also, because of the lack of a built-in runtime and garbage collector, and because the language itself can access the lowest level primitives, we can expect the eventual implementations to be highly performant. This combination of correctness and performance is highly valued for a HFT platform.
Python Binding ¶
Interoperating from Python calling Rust can be achieved by binding a Rust C-ABI compatible interface generated using
Cython. This approach is to aid a smooth transition to greater amounts
of Rust in the codebase, and reducing amounts of Cython (which will eventually be eliminated).
We want to avoid a need for Rust to call Python using the FFI. In the future
will be used.
Unsafe Rust ¶
It will be necessary to write
Rust code to be able to achieve the value
of interoperating between Python and Rust. The ability to step outside the boundaries of safe Rust is what makes it possible to
implement many of the most fundamental features of the Rust language itself, just as C and C++ are used to implement
their own standard libraries.
Great care will be taken with the use of Rusts
facility - which just enables a small set of additional language features, thereby changing
the contract between the interface and caller, shifting some responsibility for guaranteeing correctness
from the Rust compiler, and onto us. The goal is to realize the advantages of the
facility, whilst avoiding
The definition for what the Rust language designers consider undefined behaviour can be found in the
Safety Policy ¶
To maintain the high standards of correctness the project strives for, it’s necessary to specify a reasonable policy
to adhere to when implementing
If a function is
unsafeto call, there must be a
Safetysection in the documentation explaining why the function is
unsafeand covering the invariants which the function expects the callers to uphold, and how to meet their obligations in that contract.
unsafecode blocks must be completely covered by unit tests within the same source file.