Bringing Rust to iGaming

Peter Mares
Nov 7, 2022
6 min read

I have been architecting and building technology for the iGaming industry for almost 20 years. In that time, I have worked with and witnessed an ever-growing landscape of languages and technologies used to create each new generation of platforms and products.

In this opinion piece, I’m going to share my thoughts on why I think the Rust language is incredibly important for the iGaming industry and, therefore, I will expose you to some potentially controversial opinions.

I do so unapologetically.

My own journey started with C and C++, meandered through the garbage collected halls of Java and C#. My adventures have even taken me through the wild lands of Javascript, building in-browser clients and server solutions on the NodeJS runtime, only to be eventually replaced by Typescript, promising more safety from the rubber bullets that Javascript provided.

I’m sure that some of my experiences are shared among a few industry technologists, and while I did not have the opportunity (nor desire) to build anything in Go, Python, Haskel, Erlang or any of the other many languages that have been successfully used, I have been studying the Rust language since 2015.

Initially, the aspects of Rust that caught my attention were its promises of catching and preventing subtle (and not so subtle) disastrous memory defects one normally experiences with C/C++ code, without the overhead of a garbage collector and all this, at native, bare metal speeds. It also claims to give developers “fearless concurrency”: the ability to write parallelised and concurrent logic without the burden of needing to deploy a plethora of dark arts and wizardry just to keep pointers and memory in check.

Having spent many years building C/C++ code at both server and client level, this sounded like nirvana but I was skeptical… however this was not the end of what Rust was offering. Rust offers zero runtime cost abstractions through its compile-time black magic.

“Sure, lots of promises, but can they deliver?” I thought to myself initially.

Over the past 3 years though, as I have invested more and more time into learning Rust and building products with the language, I have come to see that the aforementioned promises have been met and I now use Rust for almost all of my projects. (I will explain why I don’t use it for absolutely everything a bit later). I will admit that the learning curve was one of the steepest I’ve ever been through and I have been forced to re-think some of the data structures and traditionally used memory management techniques since they are incredibly difficult to implement “safely” in Rust.

For anyone who loves their linked lists… prepare for an incredibly difficult divorce (while it is possible to implement a fully functional linked list, it is difficult I have provided a link to an article on this topic at the end).. The good news is that all of this upfront pain translates into code that you can “trust” to be safe, sound and free of 99% of the traditional security and memory-related issues that come with production code that we as an industry deploy into our production environments.

Now that I’ve mentioned the only real pain points of Rust, I thought I should focus on why I believe Rust should be employed in more of the industry’s production code. Since I am a mildly lazy author, I will provide the most relevant points (in my opinion) in precise form:

Rust is truly cross-platform. Windows, Linux, Mac, embedded… It covers everything. You can even target Android, iOS and Apple M1/M2 processors.
Rust is not opinionated. It provides an elegant middle-ground between OO and procedural approaches.
Rust has an incredibly vibrant, healthy and helpful community.
Rust has been accepted as the second official language for the Linux operating system.
Rust is fast. In fact, the generally accepted rule for optimizing Rust code is to not optimize Rust code. Always looks for all external reasons that your code may not be performing before you try and optimize your code… how many languages are capable of that kind of best practice?
Rust prefers zero runtime dependencies but still provides FFI interop.
Rust plays well with containers. In most industries, including iGaming, container solutions such as Docker, containerd, LXD (and so on) are commonplace.
You learn that, apart from logic errors, once your code compiles, you’re almost ready to go to production. Not kidding!

In terms of being able to recruit developers that can support and write Rust code, this is a challenge that curiously has many solutions. Admittedly, Rust is a young language and the developer pool may seem quite small at first blush. However, the language design and structure is such that any developer with a C, C++, C#, Java or similar background will be able to adopt a Rust codebase in a (relatively) short period of time. I personally consider 2-3 months a short period of time of adopting a code base and learning a new language at the same time.

The reason for this “rapid” upskilling is due to Rust’s similarities to a number of procedural, OO and functional languages. When used idiomatically, Rust is an incredibly expressive language which translates into a steep, but productive transition for most backend developers. I admit that moving from a duck-typed language like Javascript may provide for additional challenges to developers, but those hills are not much steeper than moving from Javascript to Typescript in my opinion.

At this point, I want to discuss why I believe Rust is important for the gaming industry.

For anyone with more than 12 months of experience of building and supporting iGaming technology outside of single-thread NodeJS services, we have all come to loathe the thread (pun intended) of sophisticated hacking and exploitation of our systems. C and C++ suffer from ridiculously challenging memory problems when dealing with heavily multithreaded and concurrent code. Java, C#, Go (and the list of GC languages continues) suffer from unexpected (and unhandled) “time warp” glitches when an attack causes the garbage collector to over-perform, or when attacks expose a vulnerability in an underlying core library (remember the last 2021 issue of log4js?). While Rust definitely isn’t absolved of all security issues, their occurences are definitely dramatically reduced.

It is probably common knowledge that most gaming providers and operators make use of CloudFlare for their CDN, API gateways and general frontend security needs. What you may not be aware of is that Cloudflare, AWS, GCP, Microsoft, The Linux Foundation and many other notable organisations are all investing in new technologies built in Rust. Most cloud providers already support serverless computing for the Rust language while Cloudflare and its competitors are all building edge-technologies in Rust due to its inherent safety, speed and portability.

Most (if not all) of these companies are using the following base crates (‘crate’ is Rust’s terminology for a library):

Tokio or Async-std (for concurrency via green threads)
Parking_lot (for optimized synchronization primitives)
Actix, Axum, Tide or one of many other crates for web services
Tonic (Tokio specific) for gRPC

By exploring these “base line” frameworks, you will discover a broad and diverse ecosystem of ready-for-production technologies that make building production-grade technologies in Rust easier. However, for those of us that prefer to build everything from the ground up (aka those of us that believe that “if it wasn’t built here, it’s not worth it”), you can leverage Rust’s standard library’s functionality to develop and deliver your own bespoke technologies to meet your production needs.

Prior to concluding this piece, I wanted to address why I said in my opening that I use Rust for “almost” all of my projects. The reality is that the current state of WASM (Web Assembly) interop does suffer from some slight performance impacts in all the browsers. Personally I use React for all of my frontend projects (due to my familiarity and trust with and of the technology). I am, however, very much looking forward to using crates like Yew to produce highly optimised frontend solutions. I firmly believe that most if not all industry game clients in the future should be developed using WASM.

If it wasn’t clear up to now, I am a firm believer that Rust is the future for technology for multiple industries, and in my personal view, most notable the iGaming industry where we live day-to-day in fear of the next security vulnerability, increasing infrastructure costs as well as maintaining developer happiness. This is the reason that sci:ent develops all of its technology using Rust.

If you’ve made it this far, thank you for taking the time to read this article. I hope that I have managed to entice you to at least explore the resources I’ve linked at the end of this article and to consider Rust for your upcoming projects.

For those that have similar backgrounds to me, I have found the following resources incredibly valuable in my Rust education:

The Rust Book
Rust By Example
Rustlings
Codingame

In case you’re interested in following the work that my company is doing in the iGaming space, I encourage you to follow the updates from myself and sci:ent on LinkedIn.

If you have any questions or comments, please drop them in the comments section.