Hacker News Reader

Comment by krichman | Hacker News Reader

I, too, think Rust is going to be revolutionary in the video game industry. Were I a game programmer I would start learning now. In two years at least 51% of all new video game code will be in Rust.

View on HN

I think you may be overestimating the pace of change. C++ is quite entrenched for industrial-strength game projects. The network effect is strong, the tooling is mature, and the projects are largely driven by C++ experts. Even if we see Rust 1.0 by the end of the year, it will take a lot of time for that kind of change to occur in the industry, if it ever does.

I think you're much more likely to see 51% of new game code written in C# for Unity. I think the median game budget is shrinking. More and more games are being made as small projects by small teams. Steam greenlight, kickstarter, humble bundle, and other avenues are enabling curation and funding of smaller games. Unity is far more suited for this kind of development than C++. If you look at smaller studios' job listings, a lot of them prefer experience with Unity. The trend is in full swing at this point.

I have no sources to site for the above information. Take it with a grain of salt.

In addition to your point, I'd like to stress that it is the game engines that are C++. Many engines provide a higher level interface for developers actually make games. You probably won't hook the game developers on Rust. If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun. Not to mention, you'll also be battling against the traction of their current codebase, which they'll probably hesitant to rewrite in a new language. From a business perspective, I don't think management in some of the larger companies would let that decision fly, either.

All good points but there is one strong argument in favor of Rust: memory safety. It seems to be the norm for games these days to CTD (crash to desktop) sooner or later. I find that unacceptable to the point that it makes me angry.

C++ makes it way too easy to corrupt random sections of memory.. which leads to random CTDs. Rust was designed from the ground up to prevent these dreadful bugs.

AAA games are overwhelmingly written by relatively inexperienced, overworked cowboy coders on a tight schedule who are expected to write optimized code. Expecting C++ code without memory corruption bugs in that situation is simply unrealistic.

As a customer I truly hope the industry adopts Rust or another language where memory corruption is impossible or only possible if you explicitly ask for it. I am so sick of CTDs.

If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun.

I've never used static analysis tools for C++, but from what I've heard, the reason they need to be so advanced is because C++ is so difficult to analyse. Rust, on the other hand, with it's strong, static type system, may not even require extra static analysis tools to be used effectively.

This is a specific instance of a general argument that applies to all new languages: there is an existing infrastructure and people won't want to switch. Yet new languages are arriving at a pace faster than ever on the server side, despite massive investment in server stacks for existing languages.

If Rust succeeds as a language suitable for games and gains traction there (and that is of course an if), I think the truth will be in the middle: there will be a huge amount of code still written in C++, and that will continue to be maintained and work. But new code might be written in Rust. Rust is designed to integrate well with C and C++ code, so mixed projects are quite feasible: in fact, both rustc (because of LLVM) and Servo (because of SpiderMonkey) are such mixed projects.

Eventually something will indeed replace C++ for gaming. You can look at the emergence of all the new server side languages in two ways: either one will "come out on top" as something akin to what C/C++ is now or there will be much more specialization in what we now call "systems programming". If the future is the latter, engines might always be done in C/C++ simply because it gives them the ability to easily make bindings to the majority of languages (ie Rust). I believe this will be the middle ground of which you speak. It really would've been cooler if there was more incentive to build languages specially for games, especially since the domain has some interesting demands such as the close coordination with GPUs and memory allocation in general.

  > engines might always be done in C/C++ simply because it 
  > gives them the ability to easily make bindings to the 
  > majority of languages

Just like C++, it will be possible to expose a C-compatible interface to Rust code that will allow any language that can call into C to call into a library written in Rust. See http://brson.github.io/2013/03/10/embedding-rust-in-ruby/ for a rather dated proof-of-concept, or http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust... for something more recent.

Didn't realize Rust had support for this. At the end of your recent example, it pretty much says doing so sacrifices the runtime entirely. I know Go doesn't support calling from C for reasons similar to this. Where does further development on this functionality sit on the priorities list for Rust?

Indeed, being able to forgo the runtime entirely is what makes it possible to rewrite the Rust runtime in Rust (as per the OP). Wouldn't be very useful to have a runtime that itself required a separate runtime. :)

As for "further development", what would you like to see? Currently the most prominent capabilities of the runtime are the lightweight task system and garbage collection. It might be theoretically possible to allow uses of the task system to gracefully degrade to using system threads, and likewise it might be possible for uses of the GC to degrade to refcounting (without cycle collection).

Being able to run runtime-less and still use the language is quite high on the priorities, and I believe moving GC to pluggable library types and cleaning up the standard library feed into that.

You don't actually have to sacrifice the runtime entirely anymore; since the runtime is written in Rust you can just start it manually if you want. Making this smoother is a priority. (Brian mentions this in the email, regarding #[start].)

That's very cool. I definitely need to check out things out. Thanks everyone for the interesting discussion.

I think it may be about 2 years before the games industry even starts to pick up Rust (or possibly a post-Rust language instead), but I think it will happen eventually.

As someone else mentioned, C# is a big deal now and comes with a degree of safety over C++. I don't expect to see Rust in the pole position on the whole, but it could easily displace C++ at Id Software since Carmack has been shopping for an alternative, and elsewhere (especially if he runs with it first.)

But I think C++'s share is losing ground, and Unity is an impressive platform. The asm.js buzz seems to whisper promises about ES and browsers becoming a serious AAA gaming platform. If FFOS gets anywhere it may supply the necessary voltage. So the lay of the land is anyone's guess, but all the variables eat into C++'s % share even if only by expanding the market around it.

You forget a few points:

* Games require portability. Not many platforms will have a rust compiler (Not to mention that current C++ compilers are very mature and highly optimizing).

* Current C++ libraries. They are probably heavily templates-based and will be difficult to port.

> * Games require portability. Not many platforms will have a rust compiler (Not to mention that current C++ compilers are very mature and highly optimizing).

Rust uses LLVM as the backend, so any platform that Clang supports, Rust can too. (And also, it has the optimisations built in.)

In fact, there's already support in the compiler for x86, x86-64, arm, and mips. (I'm not sure if mips actually works, but arm definitely does.)

Really the portability that matters in this case (games) is probably Windows, which llvm and clang do not target very well at this point.

We've been focused on first class Windows support since day one. The only major issue for LLVM itself that I'm aware of is the lack of PDB debug info, which is less of a problem for Rust because the system debuggers don't debug Rust in the first place. Most of the clang problems for Windows that I'm aware of relate to all the MSVC extensions in windows.h, which is not a problem for Rust as it doesn't use system header files.

I don't know if you'll see this, but I've been wanting to contribute to Rust for a while now. I've checked through the Github issues, but it's not really clear to me what I should do if there's one I think I can do. How should I approach it?

Thanks! There are "E-easy" and "A-an-interesting-project" tags on GitHub that you can check out if you're interested.

I would think the harder platforms are the consoles: they often come with their own compilers that only support C and C++.

Wasn't that in part due to PPC or custom silicon? The 360 and PS4 are now on x86-64, it should be possible for them to use a more sensible toolchain.

also, even before that there were people using "non-standard" toochains e.g. http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

The PS3 and Xbox360 won't go away in the next 5 years. The issue is not so much PPC (which should get support anyway), but various other silly things, like needing to rely on certain interactions between the compiler and runtime library. This is not a huge issue, but any extra bump will deter people from trying.

And indeed it's possible to have an alternate toolchain, but lots of work that is best avoided most of the time.

Reply on news.ycombinator.com