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

251–260 of 295 posts

Re: Rust's language ergonomics initiative

#251

Post by ww520 »

pornel wrote: post #226
ww520 wrote: post #151

Earlier quoted context omitted.

1. Some of the 3rd party error chain libraries help somehow but they don't help to remove the boiler plate when dealing with different types of error. I just want to be able to do: fn func1() -> Result { let foo = foo()?; // which can return Error1 let bar = bar()?; // which can return Error2 ... } 2. Error chain only shows the stack where I explicitly add it to the chain. Anything underneath is not shown. All these…

-> Result > accepts almost any type of error (via dynamic dispatch of things that implement std::error::Error trait).

That's a good idea. It's the shotgun approach.

Re: Rust's language ergonomics initiative

#252

Post by lomnakkus »

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,…

Although I think I agree that many current languages do not pay enough attention to ergonomics (hello, Scala!), I think your line of reasoning could be quite dangerous.

I don't think there's any empirical support for the idea that a shallow learning curve translates into a powerful/expressive language. EDIT: I'd love to be proved wrong, so if there's anything in the way of evidence, please link me!

Re: Rust's language ergonomics initiative

#253

Post by JelteF »

ww520 wrote: post #248
bvinc wrote: post #214

Earlier quoted context omitted.

> Support for Result would be helpful. Or may be support for easily converting one type of error to another. It sounds like you want to create a new error type that's an enum of Error1, Error2, Error3 and then just implement the From traits. Then you can use ? with no boilerplate error handling. I'm sure you've already considered this though. Why wouldn't that work for you?

Lots of typing and mental overload. Since we are talking about ergonomics and reducing friction, it would be good to make Result handling easier.

The From trait can be derived using my derive_more crate. That would at least decrease the boilerplate a bit.

http://jeltef.github.io/derive_more/derive_more/

Re: Rust's language ergonomics initiative

#254

Post by vertex-four »

no_protocol wrote: post #102
apendleton wrote: post #84

Earlier quoted context omitted.

> why do I need to declare hyper as a dependency when iron is already using it? Without commenting on the particulars of the iron API (I haven't used it), it makes sense for library authors to be able to make an explicit decision as to whether or not their dependencies are going to be a part of their backwards compatibility contract or not. You could imagine a circumstance where a library A that you used depended on…

> it makes sense for library authors to be able to make an explicit decision as to whether or not their dependencies are going to be a part of their backwards compatibility contract or not Absolutely. But as soon as those are required in order to use your library, shouldn't they be included? > If library A had exposed library B to its consumers as part of a public interface, that would be a breaking change, but it wo…

I believe what hyper should do there is `pub use ::unicase` in the hyper crate root, allowing you to use unicase directly through hyper - since it's a hyper dependency and you need to ensure you're using the same versions as it.

Re: Rust's language ergonomics initiative

#255

Post by steveklabnik »

zengid wrote: post #250

A bit of inspiration can be gleaned from the work of Dr Stefik on Evidence-based language design [1][2]. [1] https://www.youtube.com/watch?v=uEFrE6cgVNY [2] http://dl.acm.org/citation.cfm?id=2534973

Thank you for this link! I'd been trying to find this again...

Re: Rust's language ergonomics initiative

#256

Post by acjohnson55 »

lomnakkus wrote: post #252
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,…

Although I think I agree that many current languages do not pay enough attention to ergonomics (hello, Scala!), I think your line of reasoning could be quite dangerous. I don't think there's any empirical support for the idea that a shallow learning curve translates into a powerful/expressive language. EDIT: I'd love to be proved wrong, so if there's anything in the way of evidence, please link me!

As a Scala dev, I'm amused to see the Scala call-out :)

Undoubtedly, it's a language that is a little tricky to get fully fluent, but I'm curious what things pop out to you as bad ergonomics? I think it actually doesn't suffer in many of the ways identified for Rust in this article.

Re: Rust's language ergonomics initiative

#257

Post by dbaupp »

ww520 wrote: post #168
JoshTriplett wrote: post #155

Earlier quoted context omitted.

I completely agree that Rust ought to build in support for the error-chaining pattern. I think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type. > 3. It's the other way around &str to String, having to call .to_string() everywhere. Make it implicit if the type expects a String while a &str is passed in. You can't turn a reference like &str into an ow…

> I think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type. Having ad-hoc error union Result per function make it lightweight, and less friction in writing code. I would go one step further, let the compiler build the error union automatically. fn func1() -> Result { let foo = foo()?; // might return Error1 let bar = bar()?; // might return Error2 ..…

I believe inferring sum types like that would make the inference system far more sensitive and complicated and possibly even slower. For one, it would likely mean mistakes like, say, assigning two different types to a variable may result in weird error messages, and may also limit how often coercions trigger.

Re: Rust's language ergonomics initiative

#258

Post by rspeer »

JoshTriplett wrote: post #147
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; per…

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

As a beginner in Rust myself, I would like to observe that &str vs. String problems come up all the time for me. Every one of them is quickly resolved by knowing where to add an & or a method call, it seems, and experts know when to do this, and they stop noticing the problem because it's only the beginners who are doing it wrong.

But when every beginner is doing it wrong and every expert isn't, there is an ergonomics problem.

Re: Rust's language ergonomics initiative

#259

Post by rspeer »

JoshTriplett wrote: post #155
ww520 wrote: post #151

Earlier quoted context omitted.

1. Some of the 3rd party error chain libraries help somehow but they don't help to remove the boiler plate when dealing with different types of error. I just want to be able to do: fn func1() -> Result { let foo = foo()?; // which can return Error1 let bar = bar()?; // which can return Error2 ... } 2. Error chain only shows the stack where I explicitly add it to the chain. Anything underneath is not shown. All these…

I completely agree that Rust ought to build in support for the error-chaining pattern. I think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type. > 3. It's the other way around &str to String, having to call .to_string() everywhere. Make it implicit if the type expects a String while a &str is passed in. You can't turn a reference like &str into an ow…

I seem to run into functions that require String instead of &str all the time, most recently the "assert_eq!" macro which -- maybe I'm not understanding it correctly -- refuses to compare a &str to a String.

Can you tell me how I would remove the excessive uses of ".to_string()" from the tests in this module? https://github.com/rspeer/rust-nlp-tools/blob/master/languag...

Re: Rust's language ergonomics initiative

#260

Post by CalChris »

pjmlp wrote: post #246
throwawayish wrote: post #218

Earlier quoted context omitted.

> Obviously, Java has shown that you can survive without a macro pre-processor. That was even a point Gosling+Co made in a white paper I read way back in the day. But I do believe that if you are going to have a macro processor, it should be an expedient. Rust's macro processor is not expedient. It is its own impediment. Annotation Processors (iirc Java 1.5) are clearly a form of a pre-processor. It's not macros / te…

Another thing that has helped Java was the decision to use a JIT. Most Java JITs are able to remove code if it is proven unreachable, which allows to use pure Java code for what would be #ifdef in C, with the caveat that all branches must compile.

You would think that AOT would be the right time to remove dead code.
Post reply on HN