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

281–290 of 295 posts

Re: Rust's language ergonomics initiative

#281

Post by vertex-four »

ww520 wrote: post #274
kazagistar wrote: post #193

Earlier quoted context omitted.

Is using the if statement as a ternary that much worse? let x = if a { b } else { c }; Sure, it costs a few characters, but I appreciate the consistency and clarity.

Verbose.

The thing is, Rust's Option type means the primary use of the ternary in other languages - `foo ? foo : somedefault` - is entirely unnecessary in Rust. Other uses of it tend to benefit significantly from being more obvious about what's happening.

I think a ternary operator would be the first construct in Rust that prevents reading a statement from left to right.

Re: Rust's language ergonomics initiative

#282

Post by zzzcpan »

rossng wrote: post #111
zzzcpan wrote: post #76

Earlier quoted context omitted.

It doesn't have to be strictly opt-in or opt-out. There could be two versions released, a version without tracking could live on the same release page, just a bit lower and not in a bold font or something like that, pushing new users towards the version with opt-out tracking.

This is a dark pattern. Why would you want the default to be a compiler that essentially spies on your code? I can think of no better way to make developers (not to mention businesses!) uncomfortable with the idea of adopting Rust. Thankfully, Mozilla is one of the few entities left in the technology industry that seems to care about ethics. I don't believe the Rust team would ever do something like this.

No, it's not a dark pattern, you have a clear choice, just one being less advertised than the other one.

And Mozilla is the one with opt-out of all of the unethical features in Firefox. They have no ethics, looking like they care about those things is nothing more, but PR. After all, corporations are not people.

Re: Rust's language ergonomics initiative

#283

Post by zzzcpan »

jeffdavis wrote: post #115
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,…

What programming languages have been developed in this manner? What were the results?

None. Typical usability testing with watching people do things doesn't apply to programming languages, because of how much more complex and larger languages are in comparison. At best this approach can be used to test usability of tooling, IDEs, but that's it.

Re: Rust's language ergonomics initiative

#284

Post by mathw »

rspeer wrote: post #258
JoshTriplett wrote: post #147

Earlier quoted context omitted.

> 1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with error conversion. Error chaining would be nice, too. There are a couple of crates that support this; per…

> String has a Deref instance for &str, so taking a reference to a String automatically works as a &str. You can also call .as_str(). > > Going in the other direction, you can call .to_string() to make a copy of a &str as a new String. As a beginner in Rust myself, I would like to observe that &str vs. String problems come up all the time for me. Every one of them is quickly resolved by knowing where to add an & or a…

I think part of the problem might be that String and &str are not related in any intuitive way. My initial work in Rust was littered with what the heck is this, what's a str that there's a reference to, etc.

I understand now, but initially it made absolutely no sense that String is a heap-allocated owned string and &str is a reference to a chunk of string data of known length stored somewhere that I probably don't have to care about.

It may be a teaching thing, but I do wonder if they could have been named better. I just don't really know what else you'd call them without them becoming overly verbose.

Re: Rust's language ergonomics initiative

#285

Post by steveklabnik »

mathw wrote: post #284
rspeer wrote: post #258

Earlier quoted context omitted.

> String has a Deref instance for &str, so taking a reference to a String automatically works as a &str. You can also call .as_str(). > > Going in the other direction, you can call .to_string() to make a copy of a &str as a new String. As a beginner in Rust myself, I would like to observe that &str vs. String problems come up all the time for me. Every one of them is quickly resolved by knowing where to add an & or a…

I think part of the problem might be that String and &str are not related in any intuitive way. My initial work in Rust was littered with what the heck is this, what's a str that there's a reference to, etc. I understand now, but initially it made absolutely no sense that String is a heap-allocated owned string and &str is a reference to a chunk of string data of known length stored somewhere that I probably don't ha…

I often joke that String -> StrBuf is my #1 wishlist item for a theoretical Rust 2.0.

Re: Rust's language ergonomics initiative

#286

Post by no_protocol »

vertex-four wrote: post #254
no_protocol wrote: post #102

Earlier quoted context omitted.

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

I believe what hyper should do there is `pub use ::unicase` in the hyper crate root, allowing you to use unicase directly through hyper - since it's a hyper dependency and you need to ensure you're using the same versions as it.

Thank you! At least I'm not the only person who believes this would be the expected behavior. I'm still half expecting someone else to pop out and explain that I'm way wrong, though.

Re: Rust's language ergonomics initiative

#287

Post by girvo »

rattray wrote: post #79
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,…

On this note, I'm actively seeking JavaScript developers interested in doing some user studies of a compile-to-js language I'm working on. It emphasizes ergonomics, actually, as well as making functional best-practices (typed immutability, etc) more accessible. I'm in San Francisco but happy to conduct remotely. I'm targeting people familiar with ES6 and functional styles, but interested in folks of all experience le…

Replying to chase this up tomorrow when I'm not on my phone

Re: Rust's language ergonomics initiative

#288

Post by IanCal »

vertex-four wrote: post #240
IanCal wrote: post #65

Earlier quoted context omitted.

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.

The issue is, of course, that the more you focus on specific tasks the more your language becomes "designed for" those tasks, and the language becomes less general. The language already went through some of this with Servo - the DOM would be much easier to implement with an object-oriented language, but that wouldn't fit in well with the rest of Rust and would significantly raise complexity.

That is a concern but the other risk is by not doing this the language progresses in areas people happen to currently use it, which will be skewed by what it's already good at. You can then end up never improving for those cases it's weakest. This covers types of programs but also experience levels and histories of the programmers themselves.

You are right however that you need to carefully pick the tasks to fit with the original aims of the language.

Perhaps a good way of phrasing this is "why aren't X people using rust for Y?".

Re: Rust's language ergonomics initiative

#289

Post by the_mitsuhiko »

keeperofdakeys wrote: post #184
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.

They need to live in the same namespace, otherwise you'd practically need different syntax for importing something from a crate, or a module. You can use `extern crate foo as bar`, if you are having namespace issues.

You don't need different syntax. Just prefix all non carte imports with your own crate name.

Re: Rust's language ergonomics initiative

#290

Post by jnordwick »

erickt wrote: post #270
jnordwick wrote: post #244

Earlier quoted context omitted.

Too much code in one place. Makes it hard to read the file and difficult to see what is code and what are tests. `wc` can no longer give you a quick approximation of code size either.

In case you didn't see, I mentioned there is a way to do this right now: https://news.ycombinator.com/item?id=13791945

So I can keep a separate src/ and tests/ hierarchy? Why are the rust people so insistent on this even though most seen to want to could their test and src trees.
Post reply on HN