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

31–40 of 295 posts

Re: Rust's language ergonomics initiative

#31

Post by tedmielczarek »

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.

The Rust compiler is written in Rust, so rest assured the Rust core developers spend a lot of time dealing with the language itself. Additionally Mozilla is spending quite a bit of developer time on Servo, so we have quite a few people actively writing a lot of Rust code.

Re: Rust's language ergonomics initiative

#32

Post by tedmielczarek »

CalChris wrote: post #24
steveklabnik wrote: post #19

Earlier quoted context omitted.

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

const M_PI: f64 = 3.14159265358979323846264338327950288;

You wouldn't use a macro for something like that in Rust.

Re: Rust's language ergonomics initiative

#33

Post by steveklabnik »

CalChris wrote: post #24
steveklabnik wrote: post #19

Earlier quoted context omitted.

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

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

Re: Rust's language ergonomics initiative

#34

Post by tedmielczarek »

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.

Re: Rust's language ergonomics initiative

#36

Post by kinghajj »

CalChris wrote: post #24
steveklabnik wrote: post #19

Earlier quoted context omitted.

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

I thought that style was considered bad form in modern C/C++ (esp. the later, with `constexpr`). What's wrong with

    const PI: f64 = 3.14159265358979323846264338327950288;

?

Re: Rust's language ergonomics initiative

#37

Post by pjungwir »

steveklabnik wrote: post #13
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 is not totally clear to me why you can't have those functions, or rather, those functions with a little bit of change to their signature. If you have this somewhere as a compilable example, I'm happy to look at it, but it's tough when there's so much stuff here that I don't know the signatures of.

I will certainly take you up on your offer!:

https://github.com/pjungwir/rust-initialization-functions

Re: Rust's language ergonomics initiative

#38

Post by steveklabnik »

modeless wrote: post #30
steveklabnik wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: Rust's language ergonomics initiative

#40

Post by tedmielczarek »

no_protocol wrote: post #11

I am not sure if this directly applies to your post, but it came to mind when I read the section about `extern crate`. It seems like the Cargo system is relied upon by almost all Rust users, and I am not sure if the following is an ergonomics problem or a lack of understanding on my part. A couple months ago I was exploring Rust's web server capabilities after seeing the "Are we web yet?" page. I decided to try out t…

> I am not sure if this directly applies to your post, but it came to mind when I read the section about `extern crate`. It seems like the Cargo system is relied upon by almost all Rust users, and I am not sure if this is an ergonomics problem or a lack of understanding on my part.

This is definitely true, and I don't think it's negative. You can use Rust without Cargo and crates.io, but it feels very different. It's nice that that option exists, but I wouldn't want to work that way. Any sizeable project is likely to accumulate a large number of crates.io dependencies, but having written a lot of C++ code, the alternatives are "reimplement this thing myself" or "copy paste some code", neither of which are particularly good.

Post reply on HN