ruci

Rust Universal Chess Interface.

This crate parses and creates UCI messages. It follows the UCI protocol and uses shakmaty for relevant types. The UCI protocol is the most widely used way for GUI's to communicate with engines and vice versa.

#![no_std] compatible, unless you enable the engine-connection feature.

See the examples for a demo on how to send and receive messages.

Comparison

There's two other crates that I'm aware of which serve a similar purpose. Keep in mind that this is a shallow comparison, I haven't looked extensively and I am not an expert.

• vampirc-uci:
  • Doesn't use shakmaty, which AFAIK is the go-to chess crate now.
  • Doesn't separate the two types of messages (engine, GUI) and specific messages. It just has one big enum which mostly uses enum fields for message data. This is really inconvenient because you can't represent specific messages, only the whole Message enum.
  • Doesn't provide IO communication with an engine.
  • More dependencies; pest and chrono. ruci only has shakmaty and two macros, which don't get included in the final binary.
  • Not #![no_std] compatible.
  • More tests, but I don't know about the coverage.
• shakmaty-uci: this library is based on/inspired by vampirc-uci, so all of the above bullet points apply, except:
  • Uses shakmaty.
  • Uses nom instead of pest and doesn't use chrono.
  • Is #![no_std] compatible.

ruci might also faster since it doesn't use a parsing library, but I'm not making any claims or showing results because I only have some toy benchmarks (but yes, they do technically favor ruci).

Feature flags

• engine-connection: enables a structs to manage the IO when it comes to working with a UCI engine. Note that this will add tokio as a dependency.
• serde: enables Serialize and Deserialize for most types. All the implementations are derived with no parameters.