Rust's language ergonomics initiative • Hacker News Board

Re: Rust's language ergonomics initiative

#151

Post by ww520 » Sat, Mar 04, 2017, 1:05 AM UTC

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…

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 should be done by the runtime instead of forcing the developers to add code to handle it.

Also, error handling is so prevalent in Rust. If error chain is the way to go, make it as built-in. As right now, everyone has to hit a brick wall with Result, and then hunt around for the same solution.

3. It's the other way around &str to String, having to call .to_string() everywhere. Make it implicit and automatic if the type expects a String while a &str is passed in.

Re: Rust's language ergonomics initiative

#152

Post by Manishearth » Sat, Mar 04, 2017, 1:10 AM UTC

steveklabnik wrote: post #143

saosebastiao wrote: post #129

Earlier quoted context omitted.

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

Note that this is different from what's being asked, what's being asked is why they can't have fields like abstract classes that get appended to the original struct. That would make traits more like mixins.

That RFC lets you declare fields that the trait implementor is supposed to provide; implementing a trait will not automatically add a field, instead, you will be forced to add such a field yourself (unless one already exists) and link it to the trait field.

It's a more rusty way of addressing many of the same use cases, but it's not the same thing. It's basically sugar for declaring a getter and setter as trait/interface methods.

Re: Rust's language ergonomics initiative

#153

Post by int_19h » Sat, Mar 04, 2017, 1:15 AM UTC

kibwen wrote: post #60

CalChris wrote: post #48

Earlier quoted context omitted.

That was just a trivial example. Yes, you could use a const which would be difficult to share across files. Moreover, if you wanted to do something equally textual #define PASS_VERBOSE if (flag_verbose && first_pass) printf you just might be able to but only with a completely different tool. A macro processor is not of the language; it is above the language.

> A macro processor is not of the language; it is above the language. Then feel free to use the C preprocessor with Rust, it works just as well. :P Just like it does with Python, and Java, and...

Better yet, use m4.

Re: Rust's language ergonomics initiative

#154

Post by saosebastiao » Sat, Mar 04, 2017, 1:17 AM UTC

Manishearth wrote: post #152

steveklabnik wrote: post #143

Earlier quoted context omitted.

> Is there a reason why they can't have fields? The design isn't done yet: https://github.com/rust-lang/rfcs/pull/1546

Note that this is different from what's being asked, what's being asked is why they can't have fields like abstract classes that get appended to the original struct. That would make traits more like mixins. That RFC lets you declare fields that the trait implementor is supposed to provide; implementing a trait will not automatically add a field, instead, you will be forced to add such a field yourself (unless one alr…

While it's not what I asked, I actually like the answer as long as I can provide overrideable default methods in the that use the lvalues. I can't think of any of my own use cases that couldn't adequately be covered by it.

Re: Rust's language ergonomics initiative

#155

Post by JoshTriplett » Sat, Mar 04, 2017, 1:18 AM UTC

ww520 wrote: post #151

JoshTriplett wrote: post #147

Earlier quoted context omitted.

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

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 owned type like String without making a copy, and Rust doesn't do implicit copies (among many other reasons, because doing so would make it harder to notice code patterns that will lead to poor performance). So you'll always have to have some explicit indication that you want to make a copy.

In general, most functions should accept &str parameters rather than String, for exactly that reason; you should rarely run into functions that want a String. You can also use the "Cow" type if you want to support both owned and borrowed strings in the same structure.

Re: Rust's language ergonomics initiative

#156

Post by ww520 » Sat, Mar 04, 2017, 1:18 AM UTC

CalChris wrote: post #17

As I've said/posted this elsewhere, the Rust macro package is close to unusable. It makes easy stuff difficult and it doesn't exactly help with difficult stuff. It would be interesting to compare the number of macros defined in the crates corpus divided by total line count and compare that with other languages. I do not think that I am alone in not using it. Yes, I use macros; I just don't program macros. Obviously,…

I really hope one day I can build a macro for ternary operator with ? and :.

Re: Rust's language ergonomics initiative

#157

Post by int_19h » Sat, Mar 04, 2017, 1:18 AM UTC

CalChris wrote: post #82

steveklabnik wrote: post #68

Earlier quoted context omitted.

> which would be difficult to share across files. It's path::to::wherever::PI. That's it. Just like any other item. If you want to use only PI in your code, you'd use 'use', like any other name. Your second example is something better suited to a macro, it's true. I _think_ what you're getting at here is that you only want text substitution? I think we will have to agree to disagree if that's true :)

Well, given that you have only written two macros in your years of Rust, I would strongly encourage you or the language ergonomics initiative to openly question why this is so. Clearly, Rust has a clever approach but I'm questioning whether it is in fact a usable approach. Too much solution for not enough problem. Yes, I do like textual substitution. Guilty. This is a common old school low level paradigm. Still, the…

If you want textual substitution, you are not limited by anything that Rust offers. You can incorporate any existing text preprocessor - of which there's a multitude, and at least cpp and m4 are in pretty much any Unix system - into your compile pilelines. By the very definition of textual substitution, it is completely orthogonal to the meaning of the output (in this case, Rust code).

The kind of macros Rust implements, on the other hand, are the kind that have to be language-specific, because they deal with the syntax tree of that particular language. They also enable many things that are outright impossible with text substitution, such as hygienic macros.

Re: Rust's language ergonomics initiative

#158

Post by ww520 » Sat, Mar 04, 2017, 1:26 AM UTC

DiegoRamirez wrote: post #78

I forgot, what's Rust's opinion on OO? I would hope it's non-traditional. We need to get away from tradition OO and concentrate on what really matters - dispatch!.

Rust has flat level class: Struct and its implementation methods. No inheritance here. Struct method can be called as struct_obj.func1().

Rust also has Trait, which is like interface, with a set of method function signatures. A Trait is implemented for a Struct to have concrete method implementation. Trait supports inheritance.

Re: Rust's language ergonomics initiative

#159

Post by dllthomas » Sat, Mar 04, 2017, 1:30 AM UTC

glangdale wrote: post #44

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

This would be really great. I constantly see excuses for why no-one should bother doing user studies of programming languages because its really hard . So let's not do it at all and instead focus on approach #2 that you lay out ("10 weeks thinking about the problem in your head"). That being said, this is really hard . Observing a (necessarily small) sample of heterogeneous programmers dealing with (necessarily small…

> user studies of programming languages

I feel like a lot of what I see is people want to establish that language X is much better than language Y, and I think that kind of study almost doesn't make sense with all of the relevant but poorly defined and difficult to control variables. A study around ergonomics of a few options in otherwise the same language is comparatively trivial.

Re: Rust's language ergonomics initiative

#160

Post by ww520 » Sat, Mar 04, 2017, 1:30 AM UTC

k__ wrote: post #119

Animats wrote: post #88

Earlier quoted context omitted.

Rust calls them "structs". They're like classes, but different. Rust also has "traits". They're like abstract classes, but different.

Structs are for data and traits are for methods?

Struct is for data and Struct's implementation is for methods. Trait is like interface, just a set of function signatures.