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

31–40 of 118 posts

Re: New Rust runtime turned on. What next?

#31

Post by seanmcdirmid »

charliesome wrote: post #18
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.

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.

Is there a reason why future work on Go's runtime couldn't fix this problem?

Re: New Rust runtime turned on. What next?

#32

Post by AndreasFrom »

seanmcdirmid wrote: post #31
charliesome wrote: post #18

Earlier quoted context omitted.

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.

Is there a reason why future work on Go's runtime couldn't fix this problem?

Not at all, it just takes work.

Re: New Rust runtime turned on. What next?

#33

Post by tyleregeto »

pitterpatter wrote: post #26
tyleregeto wrote: post #22

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…

Multiple return values is possible with n-tuples. fn addsub(a: int, b: int) -> (int, int) { (a + b, a - b) } ... let (a, b) = addsub(32, 44);

Ah, very interesting. Thanks for posting that. Looks like I have one more reason to dig into Rust.

Re: New Rust runtime turned on. What next?

#34

Post by smosher »

usea wrote: post #13
charliesome wrote: post #9

Earlier quoted context omitted.

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

Re: New Rust runtime turned on. What next?

#35

Post by fzzzy »

pcwalton wrote: post #6
batgaijin wrote: post #5

So they are still using libuv after the rewrite?

Yes (as the Windows IOCP support is invaluable). But we will probably need to add threading support to it.

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?

Re: New Rust runtime turned on. What next?

#36

Post by sanxiyn »

seanmcdirmid wrote: post #31
charliesome wrote: post #18

Earlier quoted context omitted.

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.

Is there a reason why future work on Go's runtime couldn't fix this problem?

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

Re: New Rust runtime turned on. What next?

#37

Post by pekk »

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.

Sounds like a driver issue. Minecraft works quite well for many people.

Re: New Rust runtime turned on. What next?

#38

Post by pcwalton »

fzzzy wrote: post #35
pcwalton wrote: post #6

Earlier quoted context omitted.

Yes (as the Windows IOCP support is invaluable). But we will probably need to add threading support to it.

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?

Yeah, that's what I mean.

Re: New Rust runtime turned on. What next?

#39

Post by PommeDeTerre »

tyleregeto wrote: post #22
andrewflnr wrote: post #17

I really wish I had space in my TODO list to start a project in Rust. I don't think there's another dev tool I'm more excited about.

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…

Rust does have a lot of potential, but don't underestimate how much change it has undergone lately, and will likely be undergoing in the future.

The large amount and rapidity of change makes it difficult to use it seriously. It's nowhere near as stable as other newer languages like Go and Scala are, for instance.

Some experimental programs I wrote a mere 8 months ago are now basically unusable with recent versions of Rust due to language, syntax and standard library changes.

Unless you can constantly track Rust's development on a daily basis, and update your code accordingly, I'd be very hesitant to suggest using it for anything but throw-away code at this point.

Re: New Rust runtime turned on. What next?

#40

Post by krichman »

pshc wrote: 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, 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.
Post reply on HN