Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Rust runtime turned on. What next?

mail.mozilla.org

Post reply on HN
Print view View original

101–110 of 118 posts

Re: New Rust runtime turned on. What next?

#101

Post by jzelinskie »

kibwen wrote: post #97
jzelinskie wrote: post #94

Earlier quoted context omitted.

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://…

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?

Re: New Rust runtime turned on. What next?

#102

Post by masklinn »

jzelinskie wrote: post #101
kibwen wrote: post #97

Earlier quoted context omitted.

> 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://…

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?

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.

Re: New Rust runtime turned on. What next?

#103

Post by pcwalton »

jzelinskie wrote: post #101
kibwen wrote: post #97

Earlier quoted context omitted.

> 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://…

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?

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

Re: New Rust runtime turned on. What next?

#104

Post by reirob »

smosher wrote: post #34
usea wrote: post #13

Earlier quoted context omitted.

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.

I haven't looked at the others, but Minecraft stuttered very badly for me. I got the distinct impression that real performance wasn't considered.

Agree for Minecraft, it has definitely "lags" to an extent that there are a lot of forums discussing how to tweak the configuration to improve the performance. The lags are very disturbing and I think it has to do with memory management because it sets in after some time of playing.

Re: New Rust runtime turned on. What next?

#105

Post by NickPollard »

martijn_himself wrote: post #96
NickPollard wrote: post #92

Earlier quoted context omitted.

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

I wouldn't dive into Rust right now if you're trying to get into game development at the same time - leave that for when you're a bit more used to general game dev.

Using Lua inside a development environment/engine could be a good start - there's a couple of Lua-based development frameworks that might be worth checking out. Start with 2D games as they're much simpler to get going with and get used to how a game engine will look.

After that, it depends what you want to do. If you mostly want to create some interesting games and care more about the gameplay design side, using a pre-existing engine/framework is best. If you are interested in the development and high-performance side of things as I am, then learn C (not C++) and OpenGL. This is not as hard as it might seem. The best OpenGL tutorial I have found is http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Cha... - this will get you writing graphics code from scratch and starting to understand what is going on. You don't need to become a graphics expert, but actually understanding how this side of things works will be invaluable.

If you have questions, my email is in my profile and I can be reached there. Happy to answer individual queries. I'm not currently working in the Games Industry (day job is Scala in Finance) but my side project of the last 2 years is a cross platform engine + game written in C and Lua.

Re: New Rust runtime turned on. What next?

#106

Post by kibwen »

jzelinskie wrote: post #101
kibwen wrote: post #97

Earlier quoted context omitted.

> 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://…

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

Re: New Rust runtime turned on. What next?

#107

Post by smosher »

reirob wrote: post #104
smosher wrote: post #34

Earlier quoted context omitted.

I haven't looked at the others, but Minecraft stuttered very badly for me. I got the distinct impression that real performance wasn't considered.

Agree for Minecraft, it has definitely "lags" to an extent that there are a lot of forums discussing how to tweak the configuration to improve the performance. The lags are very disturbing and I think it has to do with memory management because it sets in after some time of playing.

It certainly fits the profile of GC stutter. I'm told it makes some bad decisions about handling objects, triggering pathological behaviour in the collector but that's second-hand info at best.

Re: New Rust runtime turned on. What next?

#108

Post by Locke1689 »

lucian1900 wrote: post #88
Locke1689 wrote: post #46

Earlier quoted context omitted.

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…

It can be possible to write the runtime for a language that requires one in the language itself, as long as the runtime is only necessary for part of the language. Then, the runtime would merely have restrict itself to the parts that don't require a runtime.

Of course, but my emphasis on "requires" was meant to deal with those cases, as it can be argued that that would constitute two languages -- one managed and one native.

Re: New Rust runtime turned on. What next?

#109

Post by j_s »

dkhenry wrote: post #95
Locke1689 wrote: post #46

Earlier quoted context omitted.

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

  > actually those things exist , but they don't
Not sure what you were trying to say here; one "Java in hardware": http://en.wikipedia.org/wiki/PicoJava

Re: New Rust runtime turned on. What next?

#110

Post by fzzzy »

kaeso wrote: post #71
fzzzy wrote: post #35

Earlier quoted context omitted.

What do you mean add threading support? Last time I used libev (I thought libuv was just libev plus Windows) it allowed creating multiple loops for use in multiple threads just fine. Do you mean adding the ability to move file descriptors across threads into another loop?

As a sidenote, libuv is not using libev anymore https://github.com/joyent/libuv/issues/485

Interesting, thanks!
Post reply on HN