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

21–30 of 295 posts

Re: Rust's language ergonomics initiative

#21

Post by stymaar »

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…

> I wish rust were smart enough to make the functions put the values directly in the caller's stack frame.

That's one reason why macros exist.

> I thought maybe macros would help here, since there is no new stack frame, but they still introduce a new scope that limits the lifetime of the temporary variables.

Why can't you just "return" the variables you need later on ?

Re: Rust's language ergonomics initiative

#22

Post by joseraul »

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

They may not do user studies like this, but for sure they adapt to user feedback.

https://thefeedbackloop.xyz/stroustrups-rule-and-layering-ov...

Re: Rust's language ergonomics initiative

#23

Post by tatterdemalion »

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

When we're trying to balance a trade off, I often wish we could just do A/B testing on it, but that's not realistic for languages.

Re: Rust's language ergonomics initiative

#24

Post by CalChris »

steveklabnik wrote: post #19
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,…

Macros are being largely re-done, see http://words.steveklabnik.com/an-overview-of-macros-in-rust for an overview. Honestly, I very rarely use macros and have written two in my years of Rust. You almost never need them, or at least, that's my experience.

  #define M_PI        3.14159265358979323846264338327950288

Re: Rust's language ergonomics initiative

#25

Post by antiquark »

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.

Re: Rust's language ergonomics initiative

#26

Post by JoshTriplett »

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…

> Alternately, I wish rust would let me say that all those temporary values should live as long as the returned thing (log and db), so it can keep them around even if I don't have variables for them.

Possibly I've missed something critical about your example, but I think you may want to create a struct Log, turn open_log() into Log::new(), and put the things the log needs (such as the log file) inside Log, owned by Log.

Re: Rust's language ergonomics initiative

#27

Post by zzzcpan »

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’s best to strongly limit it in the other two."

Re: Rust's language ergonomics initiative

#28

Post by kosinus »

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.

There's Servo: https://servo.org/

Re: Rust's language ergonomics initiative

#30

Post by modeless »

steveklabnik wrote: post #18
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,…

We have done informal ones and may or may not do more formal ones, we'll see.

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.
Post reply on HN