This is my response to the call for Rust community blog posts.
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:
- Produces executables you can run without having to install additional runtimes such as the JVM or the Python or Ruby virtual machines
- Integrates well with C (in both directions) for the libraries or system calls I end up having to do
- Is pretty fast
- 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-glyph (or any pure-rust font-handling)
- glutin / winit (I still don’t know how they differ, sorry!)
- 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.
Most of the stuff I wish for in Rust/Cargo already exists in some manner on nightly:
- non-lexical lifetimes
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.
- 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=1set in all my dev environments
- But this is an extra step and it’s harder to do on Windows iirc
- I always have
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.
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
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.
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
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.
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/