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

21–30 of 118 posts

Re: New Rust runtime turned on. What next?

#21

Post by usea »

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.

Sorry, I misread your post as saying GC in general is wholly unsuited for game development. My mistake.

Re: New Rust runtime turned on. What next?

#22

Post by tyleregeto »

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 values, its something I miss when working in every other language now. And reading through the docs I keep hoping I would stumble across that, though that would create a lot of problems when interfacing with C. Type inference is a huge win, standard libraries looks solid, love the potential around marking variables as mutable, and any language that has no null values makes me happy.

Overall, I wish I had more time too.

Re: New Rust runtime turned on. What next?

#23

Post by usea »

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…

I have limited experience with Rust, but the semicolon stuff you're describing has been one of the most surprisingly positive aspects about it for me. I thought it sounded kind of like a dumb gimmick that just adds subtlety (read: removes simplicity) to something for no reason. However, in practice I've found is really great for making the intent of your code more visible (less cluttered). I miss it when I'm doing C#.

Also, I've never come across a situation with too few/extra semicolons causing any kind of logic errors. The compiler will complain at you if you get it wrong.

Re: New Rust runtime turned on. What next?

#24

Post by charliesome »

usea wrote: post #21
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.

Sorry, I misread your post as saying GC in general is wholly unsuited for game development. My mistake.

I've updated my post, sorry for the confusion!

Re: New Rust runtime turned on. What next?

#26

Post by pitterpatter »

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…

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

Re: New Rust runtime turned on. What next?

#27

Post by kibwen »

btipling wrote: post #25

I tried to give Rust a try to build some stuff but my project required HTTP and there's no easy SSL solution in place right now. Hope it comes along. I don't have time to contribute much otherwise I would.

To quote Brian Anderson (the OP), one of the next steps in the I/O rewrite is "Implementing a new HTTP client on top of rt::io, possibly using Chris Morgan's HTTP code, for use in Servo". So hopefully within the year we'll see the beginnings of a robust HTTP lib that's worthy of a Mozilla-brand browser engine.

Re: New Rust runtime turned on. What next?

#28

Post by jzwinck »

pcwalton wrote: post #19
dkhenry wrote: post #16

I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your language when the kernel will do this for you. I think it would make more sense to provide a better interface to existing kernel structures then leverage a third party library and then re implement kernel functions around it ( I am mainly thinking about the par…

Three reasons. First, we don't control the kernel and we don't want to make assumptions about thread spawning being cheap on every OS. Second, it lets us implement work stealing, which is a proven method for dynamic parallelism. Third, it lets us do some operations such as RPC from task to task entirely in userspace with no trip through the scheduler or OS kernel.

Good points. A counterpoint for #3 is that you could do kernel bypass RPC by installing a driver, but Rust developers probably don't want to write all those drivers, and Rust users wouldn't want to install them.

Work (task) stealing is very compelling, and a little paradigm shift is no bad thing. If Rust or any new systems language stands a chance, it should aim high and not too close to the past.

Re: New Rust runtime turned on. What next?

#29

Post by kibwen »

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

Indeed, the behavior described here is just a consequence of allowing pattern-matching when assigning variables. Say you wanted to do the Python trick of swapping two values:

    let a = 1;
    let b = 9;
    let (b, a) = (a, b);
    printf!("a: %i, b: %i", a, b);  // a: 9, b: 1
...or say you just wanted to grab a single item out of a tuple:

    let x = (1, 2);
    let (_, y) = x;  // the underscore is the pattern for "ignore this"
    printf!("y: %i", y);  // y: 2

Re: New Rust runtime turned on. What next?

#30

Post by btipling »

kibwen wrote: post #27
btipling wrote: post #25

I tried to give Rust a try to build some stuff but my project required HTTP and there's no easy SSL solution in place right now. Hope it comes along. I don't have time to contribute much otherwise I would.

To quote Brian Anderson (the OP), one of the next steps in the I/O rewrite is "Implementing a new HTTP client on top of rt::io, possibly using Chris Morgan's HTTP code, for use in Servo". So hopefully within the year we'll see the beginnings of a robust HTTP lib that's worthy of a Mozilla-brand browser engine.

That's awesome!
Post reply on HN