[beefsack]

It will be interesting if any major game engines pop up using Rust as the core language, or even Go. C++ has been the king of highly optimised game engines for so long, I can't help but feel it has become so entrenched in the industry that it will take something monumental to disrupt it.

[kibwen]

There already exists a subcommunity devoted to exploring Rust's applicability to game development and computer graphics. The most active person in this department is probably Brendan Zabarauskas: http://voyager3.tumblr.com/post/82419271783/i-found-this-anc...

I also know of a few game development studios with R&D departments who have had an eye on Rust in the past, though I bet it will be a long time before a major studio is willing to make the risk that writing an engine in Rust would entail.

[forrestthewoods]

Can Rust code be compiled and debugged on PC, OS X, Linux, iOS, Android, PS4, and XB1? If the answer to any of those platforms is no then the answer to your question is no.

[steveklabnik]

iOS, PS4, and XB1 are missing.

I know it's not your point, just providing some answers in case someone is wondering.

[forrestthewoods]

I was making a point and asking a real question because I didn't know. I checked wikipedia and couldn't get a clear answer. So thanks!

Sticking with C/C++ also means you'll be able to more easily port your game to any platform of the future. It's just a safe bet that any future platform (either hardware or software) will support C/C++. Especially for games. Anything else is a dice roll. Sometimes a roll worth taking, but still a roll.

[bjz_]

I think it will most likely be smaller devs and indies who use Rust for game dev initially. Once demand grows, hopefully there will be better cross platform support in the future. Thankfully Rust emits LLVM IR, so that will make expanding to more platforms like iOS, PS4 and Enscripten much easier. XB1 would still be an issue though... not much you can do about that though.

For me, Mac/Win/Linux/Android/iOS support is more than enough, and I think it will be enough to bootstrap the language into some level of industry acceptance. It depends on the project really, and how much the developer values console support over the benefits that a modern systems language like Rust provides.

[lobster_johnson]

I have high hopes for Nimrod [1] in that regard. Unlike Rust and Go, Nimrod is able to be almost as fast as C/C++ without sacrificing syntax; Nimrod's syntax often looks entirely like Python. For example, here's the example from the Nimrod home page:

    # compute average line length
    var count = 0
    var sum = 0

    for line in stdin.lines:
      count += 1
      sum += line.len

    echo "Average line length: ",
      if count > 0: sum / count else: 0

Type inference ensures that this uses efficient types internally, and is compiled to something very close to the efficiency of C. Here [2] is the generated C code, minus line tracing and stack trace frame generation. (Nimrod does things like bounds checking and overflow checking; without them, the program obviously becomes faster; the AddInt() function, for example, is replaced with a simple "+=".)

[1] http://nimrod-lang.org

[2] https://gist.github.com/atombender/f50e47c573f865d000ec

[bjz_]

Nimrod is a great language, but it has different goals to Rust. You get better expressiveness, and cleaner code, but you don't get the huge benefits of Rust's static type system. It depends on which you value more - I think there is a place for them both though.

[lobster_johnson]

Nimrod's static type system looks comparable to Rust's; are you referring to Rust's safety guarantees?

If so, I believe Nimrod's support for immutability gets you pretty far, but I have not looked very deeply at it. For example, implements an explicit "IO taint" mechanism reminiscent of Haskell.

[Narishma]

I don't think it will happen with Rust until it becomes more stable with no breaking changes between releases.

As for Go, it's not very well suited to this domain. Or at least no better suited than Java or C#.

[bjz_]

> I don't think it will happen with Rust until it becomes more stable

Indeed. Most of the trail blazing work is being done by professional game devs in their spare time, hobbyists, indies and students who are willing to endure the pains of early adoption for the incredible gains that Rust gives them. It will only be post 1.0 however that the bigger players will be able to even consider using Rust. It's too risky to bet an entire company on – and that's coming from somebody who is willing to bet their indie project on it. ;)

[bjz_]

I don't foresee big, established C++ code bases like the Unreal Engine being re-written from scratch, but once Rust reaches 1.0 it will definitely be a very compelling choice for new projects. It will start with the side-projects and indie projects, and gradually work its way up to larger and larger projects as the language proves itself. It's not a something that will happen overnight.

[mattgreenrocks]

What's the appeal of Rust for gamedev?

[bjz_]

- Fine grained control over allocation whilst maintaining memory safety (stack, heap, RC, GC, or roll your own)

- No null pointers (with an Option type that compiles down to a nullable pointer)

- Data race free concurrency

- Zero cost abstractions

- RAII and destructors

- No exceptions

- A modern, highly expressive type system

- Generics that throw type errors at the call site, not deep in a template expansion

- True immutability (not `const`)

- An excellent C FFI

- Compiles to native code

- You don't pay for what you don't use

- Safe by default, but you can circumvent the safety checks if you know what you are doing, and those places are clearly marked and easy to audit. Inline assembly is supported.

- Most safety is enforced statically, so you don't pay for it at run time.

[mattgreenrocks]

I was being a bit flippant when I posted, but I'm really impressed with the list. I need to look into seeing where I can help on the compiler or runtime.

No exceptions is my only objection, but I know they're dubious for a systems language.

[bjz_]

No worries, it was a good question! I would highly recommend hopping on the IRC if you'd like some more information or have a chat. The community is very active and friendly. You can see the list of channels here: http://static.rust-lang.org/doc/master/index.html#external-r...

Regarding exceptions: whilst they can be be very useful, unfortunately a significant number of large, performance sensitive C++ projects outlaw them due to overhead and safety concerns (the semantics can become quite hairy when mixed with destructors). The Rust developers felt that it was easier to forgo them entirely.

[deathanatos]

> due to overhead

My understanding is that the old exception code called "SJLJ" (short for setjmp, longjmp, which is what it was) was slow. I think each try/catch required hooks, and yes, it was.

The newer compilers generate something called "DWARF"; resources on it are unfortunately scarce, but my understanding is that you don't pay anything in speed for an exception until you throw one. (You do however pay a bit of disk/memory for data about where try/catch handlers are, I think.)

> safety concerns (the semantics can become quite hairy when mixed with destructors)

I'm assuming that you shouldn't throw in a destructor.¹

This argument, to me, always needs more information attached to it, because by itself it's meaningless. Assuming the alternative is returning either the result, or an error code, you run into exactly the same semantic issues, you're just handling them manually now. Is that better, and how?

In the manual case. If I assume I have some code that returns to me an error code that I can't handle, I need to propagate that error up to a stack frame that can. Thus, I begin to manually unwind the stack, during which, I destruct things. If we're assuming destructors can throw², then I can potentially run into the problem of having two errors: now what do I do?

C++ isn't the only language here: C#, Python, and Java share the problem of "What do you do in the face of multiple exceptions requiring propagation up the stack?", though I think C++ is the only one that solves it by terminating the program. I believe C# and Python just drop the original exception, and I have no idea what Java does. Honestly, if things are that effed up, terminate doesn't sound that bad to me. In practice in C++, most destructors can't/don't throw. (Files are about the hairiest thing, since flushing a file to disk on close can fail: C++'s file classes will ignore failures there, which doesn't exactly sit well with me. You can always flush it manually before closing, but of course, if you do this during exception propagation and throw on failure, you risk termination due to two exceptions.)

Even C has this, in that if you're propagating an integer error code up the stack, and something goes wrong in a cleanup, you've got this problem. In C, you're forced to choose, of course, including the choice of "ignore the problem entirely".

That said, I'll add the answer for Rust here. (I've never used Rust, so correct me if I'm wrong. I'm going abstract away the Rust-specific types, however.) Rust, for a function returning T but that might fail, returns either Optional<T> or a Result<T>-ish object, which is basically (T or ErrorObject). Rust has strong typing, so if there's an error, you can't ignore it directly, because you can't get at the result. And if you try, it terminates the "task". Strong typing is the winner here. (This reminds me why I need to look into Rust.)

¹It's not illegal to do so, but since destructors get called while an exception unwinds the stack, you can potentially run into an exception causing an exception. Two exceptions in C++ result in a termination of the program.

²If we're not, then exceptions are perfectly safe.

[bjz_]

Yeah, I will admit I am not an expert in exceptions, so I might have been incorrect in my response. I'm sure there would be better people to talk to on the #rust. Alternatively you could ask on the mailing list or /r/rust.

[gnuvince]

A safer language with higher-level, low-cost abstractions.

[zerooneinfinity]

Honestly, I've made over 15 games in my career and safety with C++ really just isn't an issue with decent developers. The line between what's a programmer for games and what's a designer is narrowing, most designers are competent programmers. Furthermore, there's some great tools out there to help prevent things like memory leaks. Combine that with good company practice, like code reviews, and it becomes a non-issue.

[gnuvince]

I guess, then, that you weren't part of the Battlefield 4 team [1]. I've discussed the issue of the "no decent programmer" fallacy in the past; yes, in theory if programmers were careful and alert, they could create flawless software, yet this never happens in practice because humans are prone to errors (i.e. not understanding a subtlety of the language or library, thinking that a validation is done at a different level of abstraction, failing to imagine what could be an error scenario and how it could occur, etc.). Languages like Rust offer the same capabilities as C or C++, while eliminating entire classes of bug sources.

[1] http://en.wikipedia.org/wiki/Battlefield_4#Technical_issues_...

[maccard]

If BF4 was written in Csharp, or java (or rust or go?? I'm sure it would still have just as many bugs. One of peoples biggest complaint is the kill shots that you don't see, but that's a design choice (client side hit detection).

[steveklabnik]

Of course, it's impossible to speculate without seeing the codebase, but considering that Rust makes several classes of C++ bugs impossible at compile time, I'd be hard-pressed to imagine that a Rust version wouldn't be less buggy.

[pcwalton]

> Furthermore, there's some great tools out there to help prevent things like memory leaks. Combine that with good company practice, like code reviews, and it becomes a non-issue.

The security track record of applications written in C++ disagrees with you.

[zanny]

We are talking about new engines written in these languages, though, not multi-decade old codebases still using inline assembler, goto, and pointer arithmetic.

Modern C++ is really safe if you use the subset that involves automatic storage duration, well bounded arrays, etc and use all the warning flags of your compiler, run static analysis, have a robust test framework, etc.

[pcwalton]

No, modern C++ is not even close to memory safe. This is my favorite meme to destroy over and over on HN. :)

Consider iterator invalidation, null pointer dereference (which is undefined behavior, not a segfault -- and you can't get away from pointers because of "this" and move semantics), dangling references, destruction of the unique owner of the "this" pointer, use after move, etc. etc.

[angersock]

They're talking about games in C++, not random C++ apps. Oranges to apples.

[CamperBob2]

Selection bias much? The 500,000 C++ applications that have never blown up in somebody's face aren't discussed on Hacker News.

[dbaupp]

Maybe most C++ applications are low-value as attack targets, so no-one has bothered to find all the corner cases that make them blow up.

The fact that applications like browsers and operating systems (which are known to be high value targets) have a lot of effort & resources put into security but still have attack vectors makes the "C++ is secure" position fairly indefensible.

[bjz_]

pcwalton mainly works on web browser development (Servo), which whilst sharing some goals with game development, also differs in some respects. Although online security is more and more important in games these days, the real appeal of Rust in respect to game development is in providing an alternative to the 'death by a thousand cuts' that can plague large C++ projects.

I've posted a list of the things I consider the most relevant to game development: https://news.ycombinator.com/item?id=7587413 Any one or two of them alone wouldn't really be a compelling enough reason to switch, but put together they form a very compelling value proposition.

[zerooneinfinity]

It seems like it's hard to say if Rust really would have eliminated those bugs, the reports are vague and the ones that aren't, e.g. fixed framerate issues, would be an issue either way. My argument isn't solely get good developers and be done with it. It's a combination of things, and one of the most important things is getting good practices in place. I don't know if EA did this but having a good auto-test system in place probably would have caught those crash bugs and prevented the server issue, for example.

[bjz_]

> one of the most important things is getting good practices in place

That is really important, but still, wouldn't it be better if you could encode at least some of those good practices into the language itself, rather than relying on humans to be constantly on their game? I'm certainly not perfect, so I would rather my sloppiness be caught earlier rather than having it come back to bite me in the future. See: http://thecodelesscode.com/case/116