This is my response to the call for Rust community blog posts.

Background

I use Rust to write simple computer games as a hobby. I’m not a professional or even an experienced game developer. The reason I picked up Rust is because I wanted something that:

1. Produces executables you can run without having to install additional runtimes such as the JVM or the Python or Ruby virtual machines
2. Integrates well with C (in both directions) for the libraries or system calls I end up having to do
3. Is pretty fast
4. Isn’t C or C++

Rust has worked really well for me on all those counts.

My code has been generally really stable (no null pointer exceptions /, almost no segfaults) and fast (I didn’t have to think about optimizing my code yet).

In the last year, the language has been really stable as well. The libraries I ended up using less so.

Stable gamedev libs

So my main wish would be stabilization of the basic libraries for game development. Since that can mean different things for different people, in my particular case it’s:

• gfx
• gfx-glyph (or any pure-rust font-handling)
• glutin / winit (I still don’t know how they differ, sorry!)
• rand
• specs
• num
• some cross-platform terminal rendering library

Especially gfx and glutin upgrades tended to cause some friction.

I’m extremely happy that bitflags and serde both hit 1.0 this year, though!

For the record, I’m mostly interested in libraries written in pure Rust because it makes it easier to run and distribute the code.

As a bit of a pipe dream, I’d love to see a stable pure Rust ggez.

Language

Most of the stuff I wish for in Rust/Cargo already exists in some manner on nightly:

• impl Trait
• const fn
• non-lexical lifetimes
• ? in main

All of these solve a pain point I keep running into, but impl Trait disproportionately so. It’s the only reason I’m currently on nightly.

There’s a few additional proposed changes that I’m quite keen on, but they’re much of a lesser deal for me personally.

Those are:

• The modules proposals by withoutboats
  • Nice ergonomic improvements
  • But I’m familiar with the current system and I can live with it
• Implicit caller location
  • I always have RUST_BACKTRACE=1 set in all my dev environments
  • But this is an extra step and it’s harder to do on Windows iirc

WebAssembly

For me, this came out nowhere and has been amazing. I was able to run Dose Response in a web browser with a relative ease. And that web version was played and enjoyed by someone who would probably never download the binary.

WebAssembly lowers the barrier of entry to new players and that is something I am incredibly excited about. My initial desire for a language that compiled to native binaries and subsequently, using only pure-rust libs serves the same goal.

Anything that will make wasm nicer will be awesome, but honestly, I’m thrilled with what we’ve got. It feels absolutely insane that I can just compile this language that’s basically the opposite of JavaScript and it’s running in the browser.

That said, wasm being available on stable with better debugging (showing stacktraces or at least where in the code did a panic occur) would be top.

Give me a transparent println! → console.log and I’m dancing with joy.

Cross compilation between the major platforms

I wish I could do the same for Mac and Windows that I can with WebAssembly. That is, add a target via rustup and produce binaries that run on windows and mac (from linux).

I believe it is actually kind of sort of possible to do this, but it involves installing a ton of packages I don’t know and adding configuration I don’t understand.

I’m currently using trust along with Travis CI and AppVeyor to build the binaries, but I really wish I didn’t have to do that.

I wish we could just spit out windows, mac and linux binaries from any of windows, mac or linux.

Unknowable types

So this is coming out of my hazy memory from months ago and may in fact be working fine now.

Some of the libraries I use (mostly the graphics and windowing ones) sometimes use pretty hairy types where I can’t really figure out which type to write out when I have to.

E.g. I start writing something like this in main:

let mut resource = some_crate::generate_resource();

and then use it. But resource does not have a simple type like Vec<u8> but something involving a ton of wrapped structs, type parameters and lifetimes. Which is not a problem at all because of type inference.

Until you decide to wrap that into a struct at which point you have to explicitly name it and that’s where I got stuck more than once.

One would think that you could just copy & paste the type the compiler says it expects, but did not work for me.

So being able to either have a way to opt into a type inference for the struct fields or have a way of getting the exact string one needs to pass in to have things compile would be fantastic.

Like I said, maybe this works well already, been a while since I checked. And sorry for not showing a concrete example here, I can’t produce one right now.

Parting words

I’m really happy with the state Rust is in. As long as we keep the stability promise, I’m optimistic about the future. I keep being pleasantly surprised by the core team as well as the wider community.

Everything else here is just a cherry on top.

Thanks everyone! \o/

by Tomas Sedovic on 10th January, 2018