The State of Rust 0.9 | Hacker News Reader

The State of Rust 0.9

cmr.github.io

33 pointschrismorgan10 comments

I've been working on a NES emulator in rust and so far I really like the language.

Other than managing lifetimes, which can be difficult, the only thing that really bugs me is the lack of safe type promotion. for example, if I have:

fn add(a: u8) -> u16 { a + 7 }

the compiler should not complain that the expression is of type u8 and not u16 - it is safe to widen the type!

Other minor nits:

- it would be nice if enums were scoped. I think putting names in the outer namespace repeats a poor design in C. Enums should look like MyEnum.MyValue. I know the ADT nature of rust enums might throw a wrench in this

- I really dislike the word "mut". it looks like mutt to me. I don't really know how to fix this, though. Perhaps reuse the @ sigil once it goes away?

- Once macros are mature, it would be nice not to require them to be suffixed with !. I'm a lisp guy at heart in this respect... macros should be full power and macro use should feel just like that feature was built into the language

- JSON style literals for hash maps would be nice

- Ternary operator pls

Other than those small complaints, I have to say that rust has been a joy!

About scoped enums: https://github.com/mozilla/rust/issues/10090

> the compiler should not complain that the expression is of type u8 and not u16 - it is safe to widen the type!

I'm actually glad it does because it often means there's an error. An explicit type cast is the way to go IMO.

I agree; it was probably an error to mix those types (though one that will probably raise errors elsewhere should it genuinely be problematic) and it makes everything clearer if it must be explicit.

Incidentally, are you aware of SprocketNES? https://github.com/pcwalton/sprocketnes

Thanks for the link! I'll refrain from "peeking" at this until I can run Super Mario Bros :)

    fn add(a: u8) -> u16 { 
            let u15 t: a+7 
    }

I admit it looks more wordy, but I think this is a good thing. It might be nice to allow it but issue a warning about widening types.

As for the others, I kinda disagree. Enums allow for some nice syntax with match. Compare:

    match error_option { 
         Ok(Some(a)) => {},
         Ok(None(a)) => {},
         Err=> {}
    }

with

    match error_option { 
         Error.Ok(Option.Some(a)) => {},
         Error.Ok(Option.None(a)) => {},
         Error.Err=> {}
    }

See? It would get tedious fast with match pattern.

I had never had problems with mut. The syntax is clear and unambiguous. It's fine as is really. I actually like knowing which pointers are mutable, by keyword instead of typing arcane stuff like @~ptr, @&ptr. Seeing how @ was a sigil for pointers this would make most people do a double somersault in fear of the GC pointer returning.

I like macros with ! It tells you magic happens here beware. Not having those you'd have serious problem understanding where errors are once macro expands :?

Ternary operator? Wth? You can just use if as a superio ternary (endless chaining) operator.

    let ter_demo = if a.is_none() then 3 else 2;

Your ternary demo needs to be written thus for it to work:

    let ter_demo = if a.is_none() { 3 } else { 2 };

You can also often use pattern matching:

    let ter_demo = match a { None => 3, _ => 2 };

Yeah, I wrote the example out of my head, so no surprises there. Thanks, though.

  > JSON style literals for hash maps would be nice

I believe that we plan to use a macro to achieve this. After our planned enhancements to macro invocation syntax, it might look something like this:

  let foo = map! {
      bar => "hello",
      qux => "world"
  };

Reply on news.ycombinator.com