Rust's language ergonomics initiative • Hacker News Board

Re: Rust's language ergonomics initiative

#91

Post by Animats » Fri, Mar 03, 2017, 10:42 PM UTC

dogamak wrote: post #56

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…

Macros and the importing and scoping of them is a mess in rust right now and major rewrite of the macro system is underway. Currently crates have no way to re-export macros from other crates and #[use_macros] brings all macros in the imported crate to the local crate's namespace as-is (no way to prevent possible naming conflicts)

major rewrite of the ... is underway.

That's a common response to criticisms of Rust. At this late date, that's a problem.

Re: Rust's language ergonomics initiative

#92

Post by steveklabnik » Fri, Mar 03, 2017, 10:42 PM UTC

pjungwir wrote: post #37

steveklabnik wrote: post #13

Earlier quoted context omitted.

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

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

(We can continue this there)

Re: Rust's language ergonomics initiative

#93

Post by steveklabnik » Fri, Mar 03, 2017, 10:43 PM UTC

deegles wrote: post #83

steveklabnik wrote: post #73

Earlier quoted context omitted.

I don't know off the top of my head because it's been a while since we talked about it and I haven't paid super close attention to rustup's development. I am assuming that we would make an announcement on the blog because we'd want to be very clear about what's going on, and of course, try to convince people to opt in :)

How about opt-out on nightly builds and opt-in on production?

I don't personally think opt-out is ever acceptable for this kind of thing.

Re: Rust's language ergonomics initiative

#94

Post by kibwen » Fri, Mar 03, 2017, 10:43 PM 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 doesn't have classes or inheritance. Instead of classes you just have data, and you can give those data types methods via traits, which gives you composition.

Re: Rust's language ergonomics initiative

#95

Post by antiquark » Fri, Mar 03, 2017, 10:43 PM UTC

kibwen wrote: post #66

paulddraper wrote: post #63

Earlier quoted context omitted.

The Linux authors don't write the C standard.

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

I think C is fairly ergonomic.

Also, Dennis Ritchie developed Unix while simultaneously developing C, so it's not hard to imagine that he added features to the language to simplify his Unix code. At one point he added 100,000 lines to Unix within a year, so he had reasons to make the language ergonomic.

Re: Rust's language ergonomics initiative

#96

Post by steveklabnik » Fri, Mar 03, 2017, 10:44 PM UTC

lohengramm wrote: post #58

the_mitsuhiko wrote: post #10

My biggest and probably only real frustrating with Rust is that modules and crates live in the same namespace. That makes stuff incredibly confusing to teach and read. I can otherwise live with the explicit extern/mod if needed.

I also had problems understanding this whole crate system when I was playing with Rust.

This is extremely common, and is one of the reasons why it's such a big part of this post.

Re: Rust's language ergonomics initiative

#97

Post by steveklabnik » Fri, Mar 03, 2017, 10:45 PM 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…

What I'm saying is, I personally find Rust expressive enough to never need macros, and so their ease of use, to me personally, is not an issue either way. (Well, other than the import bit, I do care about that.)

Those who do use and write them heavily are the ones actually involved in the macros 2.0 effort. There are certainly flaws.

Re: Rust's language ergonomics initiative

#98

Post by kibwen » Fri, Mar 03, 2017, 10:45 PM UTC

alfiedotwtf wrote: post #90

kzrdude wrote: post #81

Earlier quoted context omitted.

But that's different. Perl's variant isn't that intuitive.

Also that was just an example. Another along the same line: x = 42 if y > 7; Rather than x = match y > 7 { true => 42, false => 0 }; Or even: foo() if bar(); Rather than: if bar() { foo() }

Given how crucially important scopes are to Rust, this would be a uniquely poor fit. :P

Re: Rust's language ergonomics initiative

#99

Post by mattyb » Fri, Mar 03, 2017, 10:46 PM UTC

nostrademons wrote: post #49

tatterdemalion wrote: post #23

Earlier quoted context omitted.

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.

What you can do is run over a large corpus of programs (crates.io? GitHub?) to identify the places where the different alternatives would impact code, collect metrics on them, and pull some sample programs to investigate the impact on them of the different alternatives. Is anything like that being done? The HTML5 spec was developed in this way, and some of the code-health folks at Google were just starting to operate…

Russ Cox did this when figuring out how to seamlessly add monotonic elapsed time measurements to Go:

https://github.com/golang/proposal/blob/master/design/12914-...

Re: Rust's language ergonomics initiative

#100

Post by twic » Fri, Mar 03, 2017, 10:46 PM UTC

staticassertion wrote: post #50

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.

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.