On Rust goals in 2018 and beyond


I’m adding my 2 cents mainly as a gamedev guy who works with C/C++ but that has also got a broad experience with other languages and industry, but my main focus for Rust is definitely gamedev.

One of the changes I would like to see is being able to perform post-build steps in build.rs

Next on my radar would be better documentation and some focus from Rust experts on developing pieces of gamedev technology as the current available examples and libraries all seem to make heavy use of RefCell and other tricks to “make the borrow checker happy” as manual lifetime management is still damn hard for Rust newcomers (me being one of them).


I did not realize that. Fantastic if true.


I suppose you’re thinking about entity-component systems, because that’s the only kind of gamedev-related libraries that I have seen use lots of RefCells/Mutexes.

If you ask a C/C++ developer how they handle race conditions in their entity-component system, they will probably answer you that they don’t, or rather that they do by organizing their code so that each system only touches one component each at a time.

If you try to do the same with Rust you’ll have problems with the borrow checker. Rust does care about these things and doesn’t trust the developer to just make things work.

For me entity component systems are just a hack that exists specifically because OOP languages don’t protect you against race conditions. In Rust I simply don’t use one.


Another example of Rc and RefCells to “make the borrow checker happy” and somehow home to what tanis is complaining about is GUI programming.

Currently due to the way callbacks and closures interact, is quite hard to have struct being mapped into widgets with instance data, forcing the use of static methods with Rc/RefCell parameters to what should actually be borrows to struct internal data.

What is a breeze in other languages regarding native GUI event handlers, turns into the same scenario of “make the borrow checker happy”.


I’m not explicitly talking about ECS, but that’s something that definitely would require a lot of those tricks to coordinate components. But as you said, that kind of design pattern doesn’t fit well in Rust.
For the time being I’ve abandoned that even though I’m still trying to figure out a good data-driven pattern to adopt.

I’m also talking about simple systems with loops and fields mutability, that’s another painful argument as I’m always having a hard time figuring out the correct way to do it.

As @pjmlp pointed out, GUI event handling is another good use case where tricking the borrow checker is an usual approach.


Not sure if this is derailing, but isn’t the other driver of ECSs cache locality and improving opportunities for parallelism?

You might find the libraries featured in ecs_bench interesting to look at - specs in particular, along with the engine project that is using it, amethyst. Lots of exciting work from the community there!


The way I see it is that if you want to achieve good cache locality and parallelism, you have to organize your data in a non-intuitive way. That organization can then confuse programmers, which can make mistakes which lead to race conditions and other problems.

Using an ECS is a solution that makes it possible to achieve cache locality and parallelism while keeping your code intuitive.

But if you’re coding in Rust, you’re protected against this. Therefore ECSes are less relevant.