Live data from Hacker News

New Rust runtime turned on. What next?

mail.mozilla.org

91–100 of 118 posts

Re: New Rust runtime turned on. What next?

#91
post #3

Earlier quoted context omitted.

Yes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.

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.

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=BMRlY9dFVLg

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.

Re: New Rust runtime turned on. What next?

#92
post #2

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 validate Rust in the domains it's > aiming for: concurrent and systems programming. Even in the task > scheduler, where there's quite a bit of unsafe code, the shared-nothing > nature of unique types forces you to consciously break the type system > to share memory, and…

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?

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++.

Re: New Rust runtime turned on. What next?

#93
post #3

Earlier quoted context omitted.

Yes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.

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.

Just avoid producing too much garbage then?

Re: New Rust runtime turned on. What next?

#94

Earlier quoted context omitted.

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…

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 tr…

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.

Re: New Rust runtime turned on. What next?

#95
post #15

Earlier quoted context omitted.

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

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 Interm…

We can imagine something that runs the CLR in hardware, and we can imagine something that runs the JVM in hardware ( actually those things exist , but they don't and both the CLR and JVM are incapable of creating programs that _can_ run on hardware without C shims.

Rust is in almost the same boat since they are using the LLVM, but the LLVM differs from the JVM and CLR since it can generate stuff to run on hardware without a shim.

Re: New Rust runtime turned on. What next?

#96

Earlier quoted context omitted.

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?

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…

This is a great answer, thank you. I have a day job as a .NET developer but I am bored and looking into developing (indie) games (I envy your 5 years AAA experience!). I have tried Lua and Go and like both. They seem both simple enough to be productive in but with some very powerful features at the same time (e.g. concurrency in Go, tables and coroutines in Lua). I have tried Clojure (as a language, not for game development), but the 'mental overhead' for me is just too much. Rust seems to be a bit more heavy on syntax and features, but I will have to look into it a bit more to find out if that is justified.

I have tried Unity (especially since I could leverage my C# experience) but as a developer I like the 'code-first' approach rather than being tied down in a graphical tool with scripting capabilities (especially for 2D games?).

Re: New Rust runtime turned on. What next?

#97

Earlier quoted context omitted.

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 tr…

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 bi…

  > 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.

Re: New Rust runtime turned on. What next?

#98

Earlier quoted context omitted.

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?

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…

> sometimes with a small embedded scripting language, mainly Lua, which uses GC

Note that Lua 5.1 and later use an incremental GC, which is friendlier for latency-sensitive workloads.

Re: New Rust runtime turned on. What next?

#99
post #64
post #61

Earlier quoted context omitted.

What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.

Look at https://github.com/pcwalton/zero.rs . It's not very far yet, but it proves that it is viable to run Rust without a runtime.

I actually don't think we even need zero.rs anymore. Its purpose was to provide noop implementations for all the "lang items" that the compiler expects to find in the stdlib. However, post-0.7 the compiler no longer requires a lang item to be provided unless you actually use a feature that requires it.

For an example, see the code at https://github.com/doublec/rust-from-c-example , which is fully runtimeless.

Re: New Rust runtime turned on. What next?

#100
post #54

Earlier quoted context omitted.

I'm feeling the same way, Rust looks fantastic. There are a few things in the language I'm not huge fan of, I don't like overly subtle things in a language. For example, some of the functionality around semi colons seem like they will be a common source of stupid programmer bugs that are difficult to track down. Perhaps the compiler will catch that stuff. Go kinda ruined other languages for me with multiple return va…

Go is not the only language with multiple return values. Lua for example had them before Go. In Lua it would look like: addsub = function(a, b) return a + b, a - b end a, b = addsub(32, 44) And if you run that code with LuaJIT it compiles down to a few machine code instructions, no object creation at all, no function call. In contrast I think at least in Python the tuple based solution would be horribly inefficient b…

  > I don't now if the Rust compiler is smart enough to 
  > optimize the tuple creation away
I'm sure it can. LLVM is a really, really good backend.
Post reply on HN