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

61–70 of 295 posts

Re: Rust's language ergonomics initiative

#61

Post by fnord123 »

pjungwir wrote: post #7

A challenge I've had with Rust lately is factoring initialization code into separate functions. Because of stack-based allocation it has to stay in the main function. For example: pub fn do_many(iter: &mut Iterator ) { let mut job_id = None; let job_id_env = env::var("MYAPP_JOB_ID"); let mut log = if let Ok(val) = job_id_env { write_pid_file(&val); job_id = Some(val.clone()); let home = env::var("HOME").expect("HOME…

It sounds like you're coming from the land of GC. Rust helps a lot with managing memory but the pattern you're talking about is creating garbage which the GC would then have to collect.

Manually collect the things you need to hold onto and put them into a struct and return that from open_log(); Do the same with prepare_db(). Then give the structs some methods for getting to the actual db object.

Alternatively use log4rs and rust-postgres. Or inspect their code to see how they handle it.

Re: Rust's language ergonomics initiative

#62

Post by killercup »

zzzcpan wrote: post #27
killercup wrote: post #2

I especially like this approach: > Often, the heart of the matter is the question of what to make implicit. In the rest of this post, I’ll present a basic framework for thinking about this question, and then apply that framework to three areas of Rust […] What's proposed here is a universally good way to think about what to make implicit. The proposed changes to Rust are just some applications of this.

"What's proposed here is a universally good way to think about what to make implicit." I had a completely opposite reaction. It ignores all of the important things that make usability good and instead focuses on the approach that essentially promotes inconsistencies in design. "The basic thesis of this post is that implicit features should balance these three dimensions. If a feature is large in one of the dimensions…

> It ignores all of the important things that make usability good

Can you give some examples?

To me the approach presented here is not just about coming up with an initial design (where I agree there are more aspects to be considered), but iterating on existing design aspects (in this case language syntax and semantics) to make them more useable. Seeing the first dimension the author mentions is 'Applicability' it seems they pay attention to consistency, but I can see it is not explicitly mentioned.

Re: Rust's language ergonomics initiative

#63

Post by paulddraper »

kzrdude wrote: post #53
antiquark wrote: post #25

They should take on a huge project, like say, converting the linux source code into Rust. The sheer bulk of the code will effectively "force" them to make Rust ergonomic. They might even end up with annoying things, like different sized ints on different CPUs, or... (horror of horrors)... running Rust through a pre-processor as part of its compilation.

Has the linux kernel made C ergonomic though? I guess there are some gcc extensions that can be the showcase for that.

The Linux authors don't write the C standard.

Re: Rust's language ergonomics initiative

#64

Post by steveklabnik »

IanCal wrote: post #57
steveklabnik wrote: post #43

Earlier quoted context omitted.

We have discussed doing this in the past, actually. Opt-in (oops, had "out" here initially) is very important here! I am not sure if it's something that ever landed or not...

Opt-in tracking, I really hope you mean. I know the concerns with getting unrepresentative samples but sending what I'm working on to a third party is something that would immediately stop me using an entire language for any form of my work.

gah! Yes, I mean "we would never consider tracking you without your express given consent." That's opt in not opt out.

Re: Rust's language ergonomics initiative

#65

Post by IanCal »

steveklabnik wrote: post #38
modeless wrote: post #30

Earlier quoted context omitted.

Informal is fine. The important thing is to do user testing in an ongoing way, not just once. Without a feedback loop it's quite surprising how quickly development priorities diverge from what's really important.

We are always constantly trying to listen to people and get feedback; for example, it's one of the reasons I pay such close attention to these threads! There's always room for improvement, but iterating in this way is defintely a core value.

Depending on what group you're trying to attract or improve the experience with, you could potentially setup contracts with the level of person you would like to deal with and pay them to implement something in rust while you monitor their progress & with full access to their work and what they're doing.

Re: Rust's language ergonomics initiative

#66

Post by kibwen »

paulddraper wrote: post #63
kzrdude wrote: post #53

Earlier quoted context omitted.

Has the linux kernel made C ergonomic though? I guess there are some gcc extensions that can be the showcase for that.

The Linux authors don't write the C standard.

I suppose the question then is, did writing Unix make C ergonomic? :)

Re: Rust's language ergonomics initiative

#67

Post by bsaul »

zzzcpan wrote: post #41
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,…

"If you're developing software for unsophisticated users it's obvious that you should be doing user testing" Compilers actually have a unique opportunity to introduce some form of opt-out tracking of all of the compilation errors with sources, etc. This could really help to understand the users.

Was about to post the same idea. This should most definitely be the number 1 step for the whole "simplification" project. Take all the advice on how to build a start up by focusing on data points, and apply it to a programming language.

Re: Rust's language ergonomics initiative

#68

Post by steveklabnik »

CalChris wrote: post #48
steveklabnik wrote: post #33

Earlier quoted context omitted.

I don't understand what this means. You'd use const in Rust for this, not a macro.

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.

> 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 :)

Re: Rust's language ergonomics initiative

#69

Post by kbenson »

tedmielczarek wrote: post #34
alfiedotwtf wrote: post #29

From moving from Perl to Rust, the only thing that I miss is the postfix "if": return true if number > 2; VS: if number > 2 { return true } I find that one-liners like these are really ergonomic.

I have found using conditionals as expressions super useful, like: ``` fn foo(number: u32) -> bool { if number > 2 { true } else { false } } ``` I mean obviously in this situation you could just have the body of the function be `number > 2` but I write a lot of Rust code that does similar things now.

In Perl, it's fairly idiomatic to use a postfix condition on a return like that when doing early return. Some of that is obviated by Rust being typed, some is not. e.g.

    sub compute_interest( $amount, $interest ) {
        return $amount if $interest == 0; # Quick return
        die "We don't allow computation of negative interest rates" if $interest
Edit: Also, it's worth noting that Perl enforces some behavior on this by only allowing postfix conditionals to follow a single statement, not blocks, so it's not just a regular conditional with the order reversed.

Re: Rust's language ergonomics initiative

#70

Post by arjie »

steveklabnik wrote: post #43
zzzcpan wrote: post #41

Earlier quoted context omitted.

"If you're developing software for unsophisticated users it's obvious that you should be doing user testing" Compilers actually have a unique opportunity to introduce some form of opt-out tracking of all of the compilation errors with sources, etc. This could really help to understand the users.

We have discussed doing this in the past, actually. Opt-in (oops, had "out" here initially) is very important here! I am not sure if it's something that ever landed or not...

Is there a mailing list I can subscribe to that will tell me when I can turn this on? I'm hoping not to have to listen to rust-dev for the trigger phrase.
Post reply on HN