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

241–250 of 295 posts

Re: Rust's language ergonomics initiative

#241

Post by vertex-four »

kazagistar wrote: post #193
ww520 wrote: post #156

Earlier quoted context omitted.

I really hope one day I can build a macro for ternary operator with ? and :.

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.

Much agreed - I quite regularly write code like that, and it's very clear on reading the first thing after the `=` that you're doing something conditional. You can also embed complex expressions in there without confusion. The ternary syntax requires you to read the entire statement before you even know what kinds of expressions it contains, then backtrack to figure it out.

Re: Rust's language ergonomics initiative

#242

Post by pjmlp »

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?

If I recall correctly Microsoft did some regarding VB.

Re: Rust's language ergonomics initiative

#243

Post by jnordwick »

yarper wrote: post #125

After writing Rust in production for a while, the biggest bugbear I have is the naming/file structure. I end up a lot with this; src/main.rs src/combobulator/mod.rs src/combobulator/tests.rs src/tests.rs src/somethingelse/tests.rs src/somethingelse/mod.rs Because I find tests in the same file a bit confusing. It's really easy with maven-style layouts to know that "only things in main/java or main/scala get compiled a…

I have no tips to fix. When cargo went gold long ago I complained about this and I was told I'd get used to it. I never have. The test layout is painful and I really hope it gets changed or at least added. I want all my tests for a module in one place. I hope this stops being a problem.

Re: Rust's language ergonomics initiative

#244

Post by jnordwick »

JoshTriplett wrote: post #146
yarper wrote: post #125

After writing Rust in production for a while, the biggest bugbear I have is the naming/file structure. I end up a lot with this; src/main.rs src/combobulator/mod.rs src/combobulator/tests.rs src/tests.rs src/somethingelse/tests.rs src/somethingelse/mod.rs Because I find tests in the same file a bit confusing. It's really easy with maven-style layouts to know that "only things in main/java or main/scala get compiled a…

I prefer to keep tests in a `mod tests { ... }` block at the end of the source file, which provides comparable benefits and separation. I also prefer to use `combobulator.rs` rather than `combobulator/mod.rs`, for multiple reasons including filename ambiguity. In this case, you'd have: src/main.rs src/combobulator.rs src/somethingelse.rs

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.

Re: Rust's language ergonomics initiative

#245

Post by zzzcpan »

killercup wrote: post #62
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…

> It ignores all of the important things that make usability good Can you give some examples? To me the approach presented here is not just about coming up with an initial design (where I agree there are more aspects to be considered), but iterating on existing design aspects (in this case language syntax and semantics) to make them more useable. Seeing the first dimension the author mentions is 'Applicability' it se…

Basics for good design is to satisfy all: simplicity, flexibility, consistency, universality, familiarity. So users won't have to neither learn a lot to do something simple nor learn a lot for a lot of different cases, but intuitively reuse what they already learnt across all similar cases.

So, what can be made implicit is irrelevant, the proper question would be what can be done to improve user experience. And it's a lot, but the design by committee kind of process is going to work against it.

Re: Rust's language ergonomics initiative

#246

Post by pjmlp »

throwawayish wrote: post #218
CalChris wrote: post #17

As I've said/posted this elsewhere, the Rust macro package is close to unusable. It makes easy stuff difficult and it doesn't exactly help with difficult stuff. It would be interesting to compare the number of macros defined in the crates corpus divided by total line count and compare that with other languages. I do not think that I am alone in not using it. Yes, I use macros; I just don't program macros. Obviously,…

> Obviously, Java has shown that you can survive without a macro pre-processor. That was even a point Gosling+Co made in a white paper I read way back in the day. But I do believe that if you are going to have a macro processor, it should be an expedient. Rust's macro processor is not expedient. It is its own impediment. Annotation Processors (iirc Java 1.5) are clearly a form of a pre-processor. It's not macros / te…

Another thing that has helped Java was the decision to use a JIT.

Most Java JITs are able to remove code if it is proven unreachable, which allows to use pure Java code for what would be #ifdef in C, with the caveat that all branches must compile.

Re: Rust's language ergonomics initiative

#247

Post by pjmlp »

raverbashing wrote: post #216
the_common_man wrote: post #186

Earlier quoted context omitted.

What does hard have to do with compiled or not? Visual Basic was actually compiled and it was and still one of the easiest languages to learn ever.

VB compiled to a VM that was embedded in the .exe file

PCode was only up to version 6.

Version 6 introduced an actual AOT compiler to native code.

Also its older brother, QuickBasic, compiled to native code.

Incidently VB is now again being AOT compiled to native code, via .NET Native and CoreRT.

Re: Rust's language ergonomics initiative

#248

Post by ww520 »

bvinc wrote: post #214
ww520 wrote: post #141

Speaking of removing friction, there are three areas that have caused me grief when I wrote Rust code: 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 err…

> Support for Result would be helpful. Or may be support for easily converting one type of error to another. It sounds like you want to create a new error type that's an enum of Error1, Error2, Error3 and then just implement the From traits. Then you can use ? with no boilerplate error handling. I'm sure you've already considered this though. Why wouldn't that work for you?

Lots of typing and mental overload. Since we are talking about ergonomics and reducing friction, it would be good to make Result handling easier.

Re: Rust's language ergonomics initiative

#249

Post by falcolas »

hackuser wrote: post #87
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,…

> 10 minutes watching new users code in Rust will give you better ideas than 10 weeks thinking about the problem in your head. I'd add: Do you want to focus on new or experienced users? For example, when implementing systems that will be used 8 hrs/day by its users, we look only at efficiency for experienced users (unless the political situation requires placating the noobs). They will be noobs for a day or maybe a c…

I think that you should focus on both groups. The new users for adoption, the advanced users for retention.

Even if no actual language changes come out of the new users group, just documentation updates, it would be a win for the entire ecosystem.

Post reply on HN