Despite being in such an immature state, Rust has an encouragingly large community of game development enthusiasts (107 users in the #rust-gamedev IRC channel as we speak). I'm very excited to see engines like this emerge from community efforts!
To be fair, Rust may be the first modern language seemingly designed around the same set of problems that we encounter in Game Development. I'm actually pretty surprised that it's as little known in GameDev as it is. That is perhaps due to it's immaturity.
The AAA game developers we've talked to are universally in agreement that the lack of garbage collection and the fine-grained control over memory that Rust provides are extremely important for game development.
For sure that'd be useful for AAA dev, but unless the console manufacturers are willing to incorporate it into the official toolchains it's dead in the water.
You'd be very surprised at how resourceful game-developers are at using the tools they prefer. Either way, console manufacturers will add support where there is demand. Certainly you're more likely to see it used first in more limited capacities and on single platform games.
IMO, a much larger stalling block will be Windows platform support. Game Development is one industry where not only is Windows a major platform for games, but the sole, primary development platform of nearly all modern games. All modern console toolchains run exclusively on Windows afaict.
That's great, but honestly, can it link against MSVC++ generated libs? I've meant to try it out, but kept trying to build rust from scratch, which may be a mistake.
> I am not a Windows expert, but generally, it's very hard to link against C++ code. It might need to expose a C interface instead of a C++ one.
I never said C++ code. I specified the compiler was MSVC++
> I am pretty sure that it's still using mingw rather than VS as well, though eventually, VS support will be important.
That's fundamentally the essence of my question, can MinGW binaries link against MSVC++ generated binaries? If not, then the Windows platform is not really supported well enough to use Rust to seriously develop games with.
Actually, linkage is the same, it's name mangling that's the problem. Regardless, libs using extern "C" are still build using MSVC++, and that is the question I was asking about.
Console games frequently use alternate languages, for example UnrealScript, Lua, and JavaScript. Of course, these are interpreted instead of compiled, but I'm told that AOT compilation is not a deal-breaker.
I suspect that any integration would be gradual, with some parts written in C++ and some written in Rust. This is the path we're following with Servo, after all.
Which parts of what? Modern game engines? Nearly all of it, minus often gameplay scripting.
In the hypothetical C++/Rust fusion engine? Whatever hasn't been rewritten yet in Rust, and specifically things that interop with other C++ libraries will remain in C++ for longer times.
Edit: Ohh Servo? Similarly, things that haven't been rewritten yet, specifically javascript interpertation/compiliation. AFAIK Servo is focusing on rewriting layout.
Rust and the PS4 toolchain are both LLVM. So I can see some possibility there. Rust currently runs on it's own patchset now, but the intention is to be fully working with mainline LLVM.
Well, it's designed to facilitate a systems language with a powerful type system, but it makes sense that there are some shared concerns with game development.
Absolutely love this rusty community. It's refreshing being surrounded by so many people consistently passionate about the language and its potential. Really looking forward to what this turns into!
Like type information, attributes are generally boiled away during the build in order to save space in the executable. So you can't reflect on them at runtime.
However, you can make custom attributes expand to arbitrary generated code via the macro system, allowing something similar. This is how we do fast JSON serialization, for instance: the #[deriving(Encodable)] attribute expands to optimized, type-specialized code at compile time, avoiding costly reflection at runtime. (Note that this is an experimental feature, so it may change post 1.0.)
It is somewhat supported at the moment, but it's experimental and we may remove the support for it. Reflection always carries an overhead in terms of binary size and as a result many of us feel that it's inappropriate for a low-level systems language like Rust.
In theory, given the attribute, and macro system, it should be possible to implement this as a library in the language, correct? I think that is vastly preferred over a constant runtime always hanging around.
Runtime reflection is rarely a good idea—it’s just that most languages don’t support any forms of compile-time reflection. Rust does have those tools, and has the power to replace the vast majority of cases where runtime reflection is used with compile-time behaviour.
If you are unaware, the base-language of Rust lacks a runtime. This limits what can easily be done in terms of reflection, when compared to languages like C# and Java.
