How it started

            Originally, a big part of the chessboard infrastructure, including the finite state machine, was written in Rust. This was done for several reasons: Firstly, the chess engine we were planning to use was written in Rust and so it would simplify the integration. Secondly, Rust had several very well made, well documented and easy to use packages for chess implementation. With the addition of it also being a fast programming language with the added benefit of memory safety, it seemed like an apt choice.

Rust was not ideal

            After changing some parts of our system, most notably the switch from Raspberry Pi and an Arduino Mega to a single ESP32, as well as the introduction of platform.io in our project, that choice was no longer ideal. Rust is still an emerging language and so it posed some challenges when trying to integrate it with systems that are primarily suited for C++. As such, we decided to rewrite all of our code in C++. The biggest benefits of that was the easy integration with embedded systems infrastructure, as well as no more need to manage communication with the Rust and C++ parts through unnecessarily complex I/O algorithms.

Tit for tat

            As with every decision however, there were also some drawbacks. First of all, we needed to spend more time on a problem that’s already been solved (FSM). One could argue that this switch would safe time in the long run since it would make us avoid many potential integration bugs in the future, but I digress. Secondly, the chess libraries were not nearly as easy to use. The library we settled on in the end, Nibble Chess, is very basic and I had to write a lot of the functionality that I took for granted with the Rust libraries myself. Finally using C++, an old and complex language, caused some difficulties by itself, but that is a story for another time.

            Overall, the switch was successful, and we expect it to not only to make integration between individual components easier, but also improve latency and make the board more responsive thanks to lack of I/O communication between the FSM and the motor control.