8 ms·

Excerpt from Graydon's (BDFL) reply: > Despite all these caveats I have a very strong sense that writing the > runtime in Rust will go a long way to valida

• zhemao 13y ago
  Yes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.
  • charliesome 13y ago
    Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.
    • TylerE 13y ago
      When latency matters, just use pool allocation, which makes the GC irrelevant.
      • pcwalton 13y ago
        Pools are still traced.
        • spullara 13y ago
          If you pool everything, the GC never runs and tracing is irrelevant. However, getting to there is very difficult. Better is to just make sure you throw almost everything away before the next GC, have a small permanent runtime set of objects and accept 10-20ms stop the world young gen collections.
          • deleted 13y ago
            [deleted]
          • klausa 13y ago
            Targeting 30fps, you have 33ms to render whole frame. Losing 20 ms of that to GC would make things… challenging. And if you're targeting 60fps, that's 16ms. Stop the world for 20ms, and you've missed 1 and 1/4 of a frame.
            • spullara 13y ago
              There are concurrent collectors that do not stop the world (e.g. Azul's) that you might want to look at for game development.
      • fhd2 13y ago
        That's how people manage to make games despite GC, but I always thought it's a huge hack, having been there. If all you do with your GC is fight it, is it actually a good idea to have it? One thing that makes me excited about Rust is that GC is optional.
    • usea 13y ago
      I don't completely disagree with your point, and I would not be a person to advocate Go for game development, but "wholly unsuitable" isn't true. A large number of successful games are released that depend on runtimes with similar garbage collectors. Most notably games running on the JVM and CLI. These are "real games" with real performance considerations. See: Minecraft, Terraria, Magicka, AI War, and many more.
      • charliesome 13y ago
        The JVM and CLR both have generational garbage collectors, which reduces the impact of most GC pauses quite significantly. Go's GC on the other hand is non-generational, which means every GC pause must perform a full scan of all objects in the system.
        • usea 13y ago
          Sorry, I misread your post as saying GC in general is wholly unsuited for game development. My mistake.
          • charliesome 13y ago
            I've updated my post, sorry for the confusion!
        • seanmcdirmid 13y ago
          Is there a reason why future work on Go's runtime couldn't fix this problem?
          • AndreasFrom 13y ago
            Not at all, it just takes work.
          • sanxiyn 13y ago
            I wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so. Quoting from http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article (emphasis mine): "To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the address of this inner field, for instance to pass it to an I/O routine. In Java, as in many garbage-collected languages, it is not possible to construct an interior pointer like this, but in Go it is idiomatic. This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector."
    • gillianseed 13y ago
      I disagree with your 'wholly unsuitable', I came across this game engine (Garage engine) written in Go which certainly doesn't jitter due to the garbage collector. http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=BMRlY9dFVLg http://www.youtube.com/watch?v=BMRlY9dFVLg https://github.com/vova616/GarageEngine https://github.com/vova616/GarageEngine So I say your statement is exagerrated, certainly stop-the-world garbage collectors isn't ideal for games, but it's not 'wholly unsuitable' as long as the gc sweeps aren't costly enough to impact consistent framerate. Had they been 'wholly unsuitable' then the XNA platform would have been dead upon arrival.
    • Tichy 13y ago
      Just avoid producing too much garbage then?
  • hamstergene 13y ago
    Why is it everytime people talk about replacing C++, someone always comes in and sticks Go into discussion? What does Go have to do with C++?
    • masklinn 13y ago
      One of the original description/assertion of Go was as a "systems language done right". Many have not been able to move on from that to the effective "a somewhat better java".
• agumonkey 13y ago
  > dogfooding-via-self-bootstrap Very rare thing. Ok maybe not in language design. But rare otherwise.
  • dkhenry 13y ago
    I think its much less common in language design then we might give it credit for. Many languages run on a VM that is written in C including the likes of Java, Javascript, C#, Ruby and Python ( even PyPy compiles down to C ). I am sure there are others besides C that are self sustaining, but they are _very_ rare
    • plorkyeran 13y ago
      Writing the runtime for a language in that language is fairly unusual, but writing compilers in the language they compile is a similar idea and has always been a popular activity.
    • Locke1689 13y ago
      I think you have a somewhat inaccurate mental model of how things are done. For one, it doesn't really make sense to talk about the CLR when you talk about bootstrapping C#. My project (the Roslyn C# compiler) is a 100% C# implementation of the C# compiler. One thing to keep in mind is that we don't target the CLR. The C# compiler is not a compiler from C# to the CLR, it's a compiler from C# to the CIL (Common Intermediate Language). It's completely reasonable to imagine a machine which runs CIL in hardware instead of in a VM. In this case the answer to the question of whether or not the C# compiler is bootstrapped is, "Yes. Completely." Moreover, it wouldn't make sense to ask whether or not the CLR is self-hosted -- it's called the "Common Language Runtime" for a reason. It's a language-independent virtual machine. In this sense, implementing it in C++ makes just as much sense as implementing it in machine code. Now, my argument here was meant to be without loss of generality. To ask whether or not a language is bootstrapped shouldn't really depend on a runtime, since any language which requires a runtime cannot, by definition, have the runtime written in said language. In this sense, we should only ask whether or not the compiler is bootstrapped, not the entire environment.
• krichman 13y ago
  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.
  • usea 13y ago
    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.
    • jzelinskie 13y ago
      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.
      • copx 13y ago
        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.
• martijn_himself 13y ago
  I am intrigued by this. Could you (or anyone) give me a 'explain this to me like I'm a 5 year old' synopsis why you think this is going to revolutionise video game development?
  • NickPollard 13y ago
    Video game development has several constraints that aren't commonly found in other development such as web development. In particular, for real-time games running at 30 or 60fps (frames-per-second), you have only 33 or 16ms respectively to process an entire frame of updates. Most game development targets fixed hardware such as consoles (PlayStation, Xbox) or mobiles (iPhone, Android), so if your code is slow, you can't just put a bigger processor in or distribute the code over an array of servers. These are other requirements mean that most high level AAA games have to be written to be very highly performant, and in particular, to have reliably consistent latencies. Traditional Garbage Collected languages (Java, C#), whilst achieving high throughput, often struggle with predictable latencies as when GC kicks in, particularly in Stop-The-World collectors, you can get a 10-20ms pause which means you will drop a frame or two. This leads to stuttering which is undesirable. Even modern generational collectors still struggle not to have occasional bad pauses. If something like Azul's continuously compacting collector becomes viable for games, this might be solved, but until it does it is hard (but not impossible) to write high performance (soft) real time games in a GCed language. The result is that most games are written in C++ (sometimes with a small embedded scripting language, mainly Lua, which uses GC) where memory management can be controlled. The downside of this is developer time - it takes large teams of developers lots of time to write games, because the code is largely written at a low level. Rust is higher level than C++ and allows many useful and safe idioms, including a more functional style and better use of immutability. In general, like other higher level languages, Rust would allow a developer to be more productive than in C++, allowing games to be developed more quickly, with fewer developers. It does this whilst still allowing manual control over memory - some parts can be handed over to GC, whilst others can be carefully allocated to the stack or heap and managed manually. This allows predictable allocation and cleanup overhead, and therefore more deterministic frame times. As a games developer, I am extremely interested in Rust as a potential game development language. Disclaimer: I haven't actually written any Rust yet, only looked at code and thought about the potential. I've spent 5 years doing AAA console development in C++.