Rust's language ergonomics initiative • Hacker News Board

Re: Rust's language ergonomics initiative

#111

Post by rossng » Fri, Mar 03, 2017, 11:06 PM UTC

zzzcpan wrote: post #76

IanCal wrote: post #57

Earlier quoted context omitted.

Opt-in tracking, I really hope you mean. I know the concerns with getting unrepresentative samples but sending what I'm working on to a third party is something that would immediately stop me using an entire language for any form of my work.

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.

Re: Rust's language ergonomics initiative

#112

Post by Tarean » Fri, Mar 03, 2017, 11:08 PM UTC

The implied bound one reminded me of a very similar thing in haskell https://prime.haskell.org/wiki/NoDatatypeContexts . Basically

    data Hashable a => Set a = ...

is completely useless. It only forces you to add constraints to functions that, if necessary, would be required anyway.

Not to be confused with existential quantification

    data ExistentialSet a = forall a . Hashable a => ...

which carries a reference to the hash function in the instances, similar to trait objects in rust.

Re: Rust's language ergonomics initiative

#113

Post by k__ » Fri, Mar 03, 2017, 11:17 PM UTC

Python and Nim are good examples to learn from ;)

Re: Rust's language ergonomics initiative

#114

Post by Rusky » Fri, Mar 03, 2017, 11:19 PM UTC

Animats wrote: post #91

dogamak wrote: post #56

Earlier quoted context omitted.

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.

What else is that a response to? Macros have had this planned since before 1.0, with the current system specifically designed as a temporary workaround until it that happens.

Re: Rust's language ergonomics initiative

#115

Post by jeffdavis » Fri, Mar 03, 2017, 11:22 PM UTC

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?

Re: Rust's language ergonomics initiative

#116

Post by Manishearth » Fri, Mar 03, 2017, 11:24 PM UTC

Animats wrote: post #88

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 calls them "structs". They're like classes, but different. Rust also has "traits". They're like abstract classes, but different.

Traits are closer to interfaces than abstract classes, iirc abstract classes can have fields.

Re: Rust's language ergonomics initiative

#117

Post by spenrose » Fri, Mar 03, 2017, 11:27 PM UTC

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?

Python. It was lauded for usability and became a 30 year success: http://python-history.blogspot.com/2009/02/early-language-de...

Re: Rust's language ergonomics initiative

#118

Post by Manishearth » Fri, Mar 03, 2017, 11:27 PM UTC

Animats wrote: post #91

dogamak wrote: post #56

Earlier quoted context omitted.

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.

There are only two cases where that's been a thing. Macros, and nonlexical lifetimes.

The major rewrite for macros has already brought fruit with Macros 1.1, solving some of the more pressing issues.

The other one, nonlexical lifetimes, needed a complete overhaul of compiler internals. The main part of that work happened with MIR, but there's still work to be done. It's ongoing. This was work that was going to take a long time, and it did.

Re: Rust's language ergonomics initiative

#119

Post by k__ » Fri, Mar 03, 2017, 11:31 PM UTC

Animats wrote: post #88

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 calls them "structs". They're like classes, but different. Rust also has "traits". They're like abstract classes, but different.

Structs are for data and traits are for methods?

Re: Rust's language ergonomics initiative

#120

Post by shepmaster » Fri, Mar 03, 2017, 11:32 PM UTC

d33 wrote: post #108

glangdale wrote: post #44

Earlier quoted context omitted.

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/

This is an interesting idea! In the alternate playground [1], the frontend is React / Redux and so we already track every edit to the code as well as the build results. "All" that would be needed would to save that data somewhere and allow people to opt-in/out.

[1]: http://play.integer32.com/