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

211–220 of 295 posts

Re: Rust's language ergonomics initiative

#211

Post by EugeneOZ »

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

absolutely agree and I think this issue is much bigger than everything together what is described in that article. Solving macros syntax issue would solve a lot of issues with verbosity.

Re: Rust's language ergonomics initiative

#212

Post by EugeneOZ »

raverbashing wrote: post #9

Great initiative By its very nature, Rust is harder (than let's say Python or JS). It is compiled, there's not much runtime magic to rely on and low level is hard. But thinking about this and trying to make it easier is important

If you are looking for easy magic, Ruby and JS will serve you better.

Re: Rust's language ergonomics initiative

#213

Post by [deleted] »

twic wrote: post #100
staticassertion wrote: post #50

Earlier quoted context omitted.

That would this in rust: if number { true } else { false } If it's the last expression it will implicitly return the values. Easily fits on one line.

My one puny objection to this is that rustfmt won't put the arms on a single line, but will always break and indent around the blocks. That makes Rust's expression-if considerably more verbose than what Perl has, or even the ternary operator.

[deleted]

Re: Rust's language ergonomics initiative

#214

Post by bvinc »

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…

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

Re: Rust's language ergonomics initiative

#215

Post by lemming »

hackuser wrote: post #87
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'd add: Do you want to focus on new or experienced users? For example, when implementing systems that will be used 8 hrs/day by its users, we look only at efficiency for experienced users (unless the political situation requires placating the noobs). They will be noobs for a day or maybe a c…

This is the reasoning that is used for Clojure - "Clojure is for experts". It's used to rationalise all sorts of design choices that make the language much harder to get started with than (IMO of course) it should be.

If you're implementing a system that users have to use for their job, they'll put up with whatever they have to while they're learning it. If you're implementing a programming language and you want to increase adoption and general user friendliness, I think this is a terrible choice.

I love Clojure now and I work with it every day, but it's still frustratingly hard for avoidable reasons even though I'm a pretty advanced user. I'm jealous of the attention that Rust, Elm and Elixir pay to this aspect of language design, and I'm very pleased to see languages taking it more seriously.

Re: Rust's language ergonomics initiative

#216

Post by raverbashing »

the_common_man wrote: post #186
raverbashing wrote: post #9

Great initiative By its very nature, Rust is harder (than let's say Python or JS). It is compiled, there's not much runtime magic to rely on and low level is hard. But thinking about this and trying to make it easier is important

What does hard have to do with compiled or not? Visual Basic was actually compiled and it was and still one of the easiest languages to learn ever.

VB compiled to a VM that was embedded in the .exe file

Re: Rust's language ergonomics initiative

#218

Post by throwawayish »

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

> 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 / textual expansion, though.

Similarly C++ mostly gets along without macros since it contains a capable meta-programming system -- and I think this is the more important point here; for many tasks meta-programming is just a handy thing to have. Dynamic languages don't have that problem, since their runtime is their meta-programming system as well.

Re: Rust's language ergonomics initiative

#219

Post by eddyb »

JoshTriplett wrote: post #177
ww520 wrote: post #168

Earlier quoted context omitted.

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

That kind of automatic sum-typing seems like an interesting idea. You might consider bringing it to the Rust internals forum, posting it as a pre-RFC, and discussing it as compared to some of the alternatives. That might lead to either a change in the direction you hope for, or the unearthing of other ergonomic approaches.

This idea has been waved around a bit, but in the form of `impl Error` where `_` is. That is, inside the function the `E1 | E2 | ...` type is being built, and if you have automatic dispatch for `Error`'s methods then it will work with `impl Error`.

Actual global inference has never been on the table and still isn't.

Re: Rust's language ergonomics initiative

#220

Post by masklinn »

JoshTriplett wrote: post #177
ww520 wrote: post #168

Earlier quoted context omitted.

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

That kind of automatic sum-typing seems like an interesting idea. You might consider bringing it to the Rust internals forum, posting it as a pre-RFC, and discussing it as compared to some of the alternatives. That might lead to either a change in the direction you hope for, or the unearthing of other ergonomic approaches.

I believe there are conversations of being able to promote enum variants to full-blown types, though I don't know if there's any project for lightweight enums of types.
Post reply on HN