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

Rust's language ergonomics initiative

blog.rust-lang.org

Post reply on HN
Print view View original

141–150 of 295 posts

Re: Rust's language ergonomics initiative

#141

Post by ww520 »

Speaking of removing friction, there are three areas that have caused me grief when I wrote Rust code:

1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with error conversion. Error chaining would be nice, too.

2. Lack of stack trace when an error occurs. Now that stacktrace starts when panic!() is called, which is kind of late.

3. Better support for conversion between &str and String. Dealing with strings is so prevalent in programming that making it easier to work with the two types would be a huge boost to productivity.

Edit: another item

4. Support of partially applied function , i.e. bind a subset of arguments to the function pointer. Currently there's no way to bind the self argument to the Option/Result chaining calls. Basically the Option/Result chain (.and_then, .map, etc) only carries forward the value of Option/Result and nothing else. It would be nice put partially applied function in the chain. e.g. result.and_then(self.func1) where func1 has the self argument bounded. Or in more general form, result.and_then(func1("param1", param2, _)) where func1's first and second parameters have been bounded up front and the value of result will be passed in as the 3rd parameter.

Re: Rust's language ergonomics initiative

#142

Post by steveklabnik »

dogamak wrote: post #138
yarper wrote: post #125

After writing Rust in production for a while, the biggest bugbear I have is the naming/file structure. I end up a lot with this; src/main.rs src/combobulator/mod.rs src/combobulator/tests.rs src/tests.rs src/somethingelse/tests.rs src/somethingelse/mod.rs Because I find tests in the same file a bit confusing. It's really easy with maven-style layouts to know that "only things in main/java or main/scala get compiled a…

Additionally tests in "tests/" are compiled to independent binaries on which the test suite is run on separately, which results into verbose and redundant output when ran. Also if you keep your tests under "src/", you can't just stick them wherever you want; you need to have #[cfg(tests)] on every module declaration leading to the test function, otherwise the test is ignored silently. From time to time I find old tes…

Hm, cfg(tests) should only control if they're included in non-test builds; it shouldn't ignore them entirely.

Re: Rust's language ergonomics initiative

#143

Post by steveklabnik »

saosebastiao wrote: post #129
Manishearth wrote: post #116

Earlier quoted context omitted.

Traits are closer to interfaces than abstract classes, iirc abstract classes can have fields.

I've noticed this and while I don't use it much it has caught me off guard once or twice. And while it wasn't the end of the world, I wasn't too fond of the solutions I came up with. Is there a reason why they can't have fields? Why wouldn't they just be an "extension" to a struct/enum, modifying their memory representation?

> Is there a reason why they can't have fields?

The design isn't done yet: https://github.com/rust-lang/rfcs/pull/1546

Re: Rust's language ergonomics initiative

#144

Post by yarper »

ww520 wrote: post #141

Speaking of removing friction, there are three areas that have caused me grief when I wrote Rust code: 1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with err…

for 1. there's map_err(..) which accepts a closure

e.g.

`try!(foo().map_err(|e| format!("{}", e.thing)));`

Re: Rust's language ergonomics initiative

#145

Post by robohamburger »

tatterdemalion wrote: post #133
lobster_johnson wrote: post #109

Earlier quoted context omitted.

I was surprised that Rust actually did it the way it is now (i.e. no implicit bounds). Article says accessing the map arg's methods will fail, but isn't the entire argument itself invalid by definition? You can't instantiate the hash map without validating that K and V do implement those traits.

In the standard library today, there's no bounds on `K` on the definition of HashMap, only on the impl block containing its methods. This sort of makes HashMap a bad example for this code block; you're right that if the bounds were on the definition instead of the impl, the argument itself would be invalid.

I think it becomes useful only if whatever struct expects some extra level of behavior from the types. Basically any time a struct or a trait is coupled with another trait or needs a particular marker/lifetime to function I find myself repeating the bounds over and over.

For example in gfx-rs it might be repeating the gfx::Resources or gfx::Factory trait bounds.

Re: Rust's language ergonomics initiative

#146

Post by JoshTriplett »

yarper wrote: post #125

After writing Rust in production for a while, the biggest bugbear I have is the naming/file structure. I end up a lot with this; src/main.rs src/combobulator/mod.rs src/combobulator/tests.rs src/tests.rs src/somethingelse/tests.rs src/somethingelse/mod.rs Because I find tests in the same file a bit confusing. It's really easy with maven-style layouts to know that "only things in main/java or main/scala get compiled a…

I prefer to keep tests in a `mod tests { ... }` block at the end of the source file, which provides comparable benefits and separation. I also prefer to use `combobulator.rs` rather than `combobulator/mod.rs`, for multiple reasons including filename ambiguity. In this case, you'd have:

    src/main.rs
    src/combobulator.rs
    src/somethingelse.rs

Re: Rust's language ergonomics initiative

#147

Post by JoshTriplett »

ww520 wrote: post #141

Speaking of removing friction, there are three areas that have caused me grief when I wrote Rust code: 1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with err…

> 1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with error conversion. Error chaining would be nice, too.

There are a couple of crates that support this; personally, I recommend the "error-chain" crate. However, I do wish that Rust promoted the most capable of those to the standard library.

> 2. Lack of stack trace when an error occurs. Now that stacktrace starts when panic!() is called, which is kind of late.

error-chain provides that.

> 3. Better support for conversion between &str and String. Dealing with strings is so prevalent in programming that making it easier to work with the two types would be a huge boost to productivity.

Can you give some specific examples of cases you've found cumbersome?

String has a Deref instance for &str, so taking a reference to a String automatically works as a &str. You can also call .as_str().

Going in the other direction, you can call .to_string() to make a copy of a &str as a new String.

Re: Rust's language ergonomics initiative

#148

Post by pekk »

AsyncAwait wrote: post #128
modeless wrote: post #15

Are there plans to do user studies? 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I feel like there's a real lack of user testing in software development tools land. If you're developing software for unsophisticated users it's obvious that you should be doing user testing, but it's an often ignored fact that developers are users too! APIs,…

> 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I am not sure whether 10 minutes of Rust would give you actionable info, I mean it certainly takes longer to get familiar with the basics in almost any language, even if the 10 minutes just stands for a short amount of time .

Things happen even in the first 10 minutes.

It's not appropriate to limit user studies only to people who are already experts.

Re: Rust's language ergonomics initiative

#149

Post by ww520 »

yarper wrote: post #144
ww520 wrote: post #141

Speaking of removing friction, there are three areas that have caused me grief when I wrote Rust code: 1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with err…

for 1. there's map_err(..) which accepts a closure e.g. `try!(foo().map_err(|e| format!("{}", e.thing)));`

That's what I'm doing right now all over the place and I hate the boiler plate.
Post reply on HN