[hardwaresofton]

As a person who started writing rust this last week, I think I might have picked the best possible time to get in on it.

The community is amazing, and I actually understand all these features that were released I've run into about half of the issues they fix already.

Rust is coming along very very nicely.

[MuffinFlavored]

what else would you say it is missing?

[hardwaresofton]

Unfortunately I don't have a good full response to this (otherwise I could contribute it and actually help), but off-head I was surprised by the lack of a `cargo install` (https://github.com/rust-lang/cargo/issues/2179). A few minutes later though I was used to googling for the package i wanted, and getting the version I wanted to use and adding it to Cargo.toml, and that's arguably a better way to do things to start with.

I haven't used it enough to have much more to say -- I've found everything pretty ergonomic so far (especially for a C/C++-tier language), I was most frequently confused when thinking of the most idiomatic way of doing something, but that's remedied by reading more (the rust book first/second edition, the rust cookbook). This should change over the coming weeks.

This isn't a particularly useful comment, but I chose Rust over Common Lisp recently for this new project, and I've found the std library's google-ability to be excellent for rust -- very few pages about steel have come up so far ("result rust" in DDG brings up rustlang related links). When I explored CL, I did not find that to be the case, but maybe I just didn't know where to look -- hyperspec is close but it is a terrible document to navigate through, and the 90s graphics didn't help (though they were nostalgic). Rust documentation is very often concise, well structured, and passably beautiful. I was also pleased with the Abstract Data Type solution in rust -- tagged unions. Some code:

    #[derive(Debug)]
    pub enum ConfigLoadError {
        EmptyFilePath,
        IO(IOError),
        TomlParse(TomlError)
    }

The abstraction enabled here is just right for me, super similar to code that I'd write in Haskell, and helps me abstract over errors thrown by utility libraries (in this case `toml-rs`).

[red75prime]

You may want to see the failure crate. In my practice most errors cannot be handled by a program and the only sensible thing to do is to pass an error description to a user or a programmer. Such fine-grained error type information as in your example is rarely useful. The failure crate provides a way to create detailed error descriptions (see `Context`) and fixes shortcomings of the standard Error trait.

[Rotareti]

Not essential but keyword arguments / named parameters / default arguments. I love those in Python and OCaml/ReasonML.

[Lev1a]

You can make functions with default arguments right now (a little easier thanks to Impl Trait):

http://play.rust-lang.org/?gist=4f74d3dcee0031e99cb99bb54da5...

Concerning keyword args as I remember them from Python you would probably have to hack something together with an Into<Option<HashMap<some_type_for_arg_names, some_enum_with_variants_containing_acceptable_types>>>

Concerning "named paramters" I think you would have to apply some of the same trickery in order to be able when calling the fn to leave out args or give them in a different order than specified in the fn header.

Or what I've sometimes seen written was (e.g. for configuration passing) structs created with Option<some_type> that were then passed to one or more functions which in turn get the values (named params/default args if you will) from that "object", being able to pick and choose the appropriate values to get in a given function/method.