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

101–110 of 295 posts

Re: Rust's language ergonomics initiative

#101

Post by okbake »

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.

You can do something similiar in rust. 'if' is an expression, so it can appear on the right hand side of an assignment.

  let x = if number > 2 { "yes" } else { "no" };
It's not quite the same, and I'm not sure what the failure case would be if the 'else' statement was ommitted, but it comes close.

After experimenting with Rust and Elixir I've really come to like the 'everything is an expression' approach. That and pattern matching can make some things really expressive.

Re: Rust's language ergonomics initiative

#102

Post by no_protocol »

apendleton wrote: post #84
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…

> why do I need to declare hyper as a dependency when iron is already using it? Without commenting on the particulars of the iron API (I haven't used it), it makes sense for library authors to be able to make an explicit decision as to whether or not their dependencies are going to be a part of their backwards compatibility contract or not. You could imagine a circumstance where a library A that you used depended on…

> it makes sense for library authors to be able to make an explicit decision as to whether or not their dependencies are going to be a part of their backwards compatibility contract or not

Absolutely. But as soon as those are required in order to use your library, shouldn't they be included?

> If library A had exposed library B to its consumers as part of a public interface, that would be a breaking change, but it wouldn't be if they hadn't.

Maybe I should have refined my original post. I guess it was way too long.

The hyper crate exposes `hyper::header::Vary`. To create a `Vary::Items` in my program, I also need to `use unicase::UniCase`. See the short example at [0].

It felt odd to me that I was required to have my own dependency on unicase when it seems like an internal issue for how Hyper represents the Vary header.

I have little experience with these dependency management systems. This seems like an irrelevant detail (they look just like strings to me! why doesn't it just take strings!) requiring me to explicitly include an unrelated package. I may have no other need for the unicase package.

Is this a normal thing, though? Since unicase is required in order to use this feature of hyper, shouldn't it just come along with it? Or the Vary item could just use Strings on its public interface so the user doesn't have to go through this extra work?

[0]: https://hyper.rs/hyper/v0.8.1/hyper/header/enum.Vary.html#ex...

Re: Rust's language ergonomics initiative

#103

Post by oconnor663 »

kbenson wrote: post #51
zzzcpan wrote: post #27

Earlier quoted context omitted.

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

Based on the actual examples, I'm not sure it promotes inconsistency in design, as long as it's not the sole deciding criteria. As a tool to do first pass exclusion of ideas I think it has a lot of promise. The major problem I see is that it's fairly subjective at the moment in what you consider when thinking about those criteria. For example, in the section about eliminating the need for mod (which was admittedly pr…

I think the idea is that `foo::something()` without a module declaration either implies the existence of `foo.rs`, or fails to compile. I'd agree that it would be bad if creating `foo.rs` changed the behavior of code that was previously doing something else (other than breaking the build).

What would happen, I think, is that adding a `mod foo { ... }` definition would change the behavior of code that previously implicitly referenced a `foo.rs` file. But that seems less crazy to me, since you've got a change in one file affecting something else in that same file. Or it might make sense for that to be a "conflicting module definitions" error.

Re: Rust's language ergonomics initiative

#104

Post by pklausler »

cardiffspaceman wrote: post #89
kinghajj wrote: post #36

Earlier quoted context omitted.

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

What machine can represent all those decimal digits so precisely that the ending decimal digits ...0288 are exactly right and not ...0287 ? I'll accept without looking it up that the statement is correct syntax in some language (it doesn't look like C++ to me).

See above. The constant is (a) not pi, and (b) not an exact decimal representation of any binary floating-point number.

Re: Rust's language ergonomics initiative

#105

Post by lobster_johnson »

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.

A "macro" in C is not the same thing as a "macro" in Rust. By your logic, Erlang processes aren't processes because they aren't kernel processes, or Go packages aren't packages because they don't use the Java package naming convention. Nobody owns the exclusive right to define the words we use.

Re: Rust's language ergonomics initiative

#106

Post by alfiedotwtf »

okbake wrote: post #101
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.

You can do something similiar in rust. 'if' is an expression, so it can appear on the right hand side of an assignment. let x = if number > 2 { "yes" } else { "no" }; It's not quite the same, and I'm not sure what the failure case would be if the 'else' statement was ommitted, but it comes close. After experimenting with Rust and Elixir I've really come to like the 'everything is an expression' approach. That and pat…

Ah yes... ternaries. Actually, it's two things I miss :)

Re: Rust's language ergonomics initiative

#107

Post by alfiedotwtf »

kibwen wrote: post #98
alfiedotwtf wrote: post #90

Earlier quoted context omitted.

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

Yeah, I totally understand why not. Just my comments from the peanut gallery :)

Re: Rust's language ergonomics initiative

#108

Post by d33 »

glangdale wrote: post #44
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,…

This would be really great. I constantly see excuses for why no-one should bother doing user studies of programming languages because its really hard . So let's not do it at all and instead focus on approach #2 that you lay out ("10 weeks thinking about the problem in your head"). That being said, this is really hard . Observing a (necessarily small) sample of heterogeneous programmers dealing with (necessarily small…

You wouldn't really need to have people install a new text editor. Just plugging this in to the Rust Playground would probably do [0].

[0]: https://play.rust-lang.org/

Re: Rust's language ergonomics initiative

#109

Post by lobster_johnson »

robohamburger wrote: post #5

"Idea: implied bounds" sounds like a very interesting idea. It is a pain copying the bounds as author mentions. I also have worked with library code that does not consistently use trait bounds and it can lead to very confusing errors. The thing that keeps getting me now is there are so many types moving around with generics and traits. It would be nice if it were easier for something to be object safe and/or Any was…

I was surprised that Rust actually did it the way it is now (i.e. no implicit bounds). Article says accessing the map arg's methods will fail, but isn't the entire argument itself invalid by definition? You can't instantiate the hash map without validating that K and V do implement those traits.

Re: Rust's language ergonomics initiative

#110

Post by akiselev »

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

Trait specialization is Rust's answer to several of the abstractions provided in most OOP languages and the initial implementation (with conservative type resolution) has been in nightly for a while. I believe there is still a bit of work to do before stabilization but the feature is under active development. One of the primary challenges is the soundness and predictability of the algorithm that selects the right implementation for each type.

With specialization, instead of inheriting classes, traits can provide blanket and default implementations for types that depend on the traits implemented by that type. So, for example, you can provide several different "impl ExTrait for T" with different trait bounds like "T: Clone", "T: Clone + Send", and "T: Clone + Send + Future". Once the conservative inference algorithm is improved, this will be a much more powerful way to compose functionality than OOP but it will require a different approach to abstraction.

I think the plan is to eventually add trait objects that implement multiple traits which will cover more complex cases of dynamic dispatch like those in virtual inheritance.

Post reply on HN