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

221–230 of 295 posts

Re: Rust's language ergonomics initiative

#221

Post by paavohtl »

steveklabnik wrote: post #19
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,…

Macros are being largely re-done, see http://words.steveklabnik.com/an-overview-of-macros-in-rust for an overview. Honestly, I very rarely use macros and have written two in my years of Rust. You almost never need them, or at least, that's my experience.

I guess it depends on what you work on. Both of my primary Rust projects (a .NET metadata parser & a Game Boy emulator) are heavily dependent on macro usage, and they implement multiple new macros. Both do lots of binary parsing, so I use bitflags, enum_primitive and bitfield all the time. For instance, I use this [1] two-macro monstrosity to parse tagged unions from the CLR metadata.

[1] https://github.com/paavohuhtala/clri/blob/b8a9057397ef95c0de...

Re: Rust's language ergonomics initiative

#222

Post by progval »

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?

Declaring the new enum and implementing it are the boilerplate.

Re: Rust's language ergonomics initiative

#223

Post by paavohtl »

k__ wrote: post #217
ww520 wrote: post #160

Earlier quoted context omitted.

Struct is for data and Struct's implementation is for methods. Trait is like interface, just a set of function signatures.

Why isn't it called interface then?

Because they are traits [1], not interfaces, and they also have some features from type classes [2].

When you create a class in an OOP language, you have do declare all interfaces it supports, and provide implementations for them (or mark the class as abstract). In Rust's case, you declare the data separately as a struct declaration, and then implement the traits you want in impl declarations. You can also implement traits for other traits, or for types from other modules, including the standard library.

Finally, compared to traditional OOP interfaces Rust's traits can require static functions in addition to instance methods and they can also implement methods with an overridable default implementation.

[1] https://en.wikipedia.org/wiki/Trait_(computer_programming) [2] https://en.wikipedia.org/wiki/Type_class

Re: Rust's language ergonomics initiative

#224

Post by fnord123 »

flogic wrote: post #185
fnord123 wrote: post #80

Earlier quoted context omitted.

ProTip: In both languages you can do the following: return number > 2;

Not really the same thing. The Perl version is generally used as an early abort either from a subroutine or a loop. return if($number > 2); Is equivalent to: if($number > 2){ return; }

I didn't know that. Thanks for explaining it.

Re: Rust's language ergonomics initiative

#225

Post by coldtea »

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…

>unless the political situation requires placating the noobs

If something is a pain point for the noobs it's usually a badly designed part of the language that the "veterans" have just learned by rote to step around.

Re: Rust's language ergonomics initiative

#226

Post by pornel »

ww520 wrote: post #151
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…

1. Some of the 3rd party error chain libraries help somehow but they don't help to remove the boiler plate when dealing with different types of error. I just want to be able to do: fn func1() -> Result { let foo = foo()?; // which can return Error1 let bar = bar()?; // which can return Error2 ... } 2. Error chain only shows the stack where I explicitly add it to the chain. Anything underneath is not shown. All these…

    -> Result>
accepts almost any type of error (via dynamic dispatch of things that implement std::error::Error trait).

Re: Rust's language ergonomics initiative

#227

Post by ice109 »

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…

I don't understand there are no stack traces unless you use a library?

Re: Rust's language ergonomics initiative

#228

Post by sirclueless »

pklausler wrote: post #59
CalChris wrote: post #24

Earlier quoted context omitted.

#define M_PI 3.14159265358979323846264338327950288

3.141592653589793115997963468544185161590576171875 is the exact decimal representation for the 64-bit IEEE-754 number that's closest to pi (viz. 0x400921FB54442D18). Any time you see a decimal floating-point constant with a nonzero fractional part that doesn't end in '5', you're looking at a bug. EDIT: As long as this grizzled old Fortran programmer is giving out free advice, I'll add two more items every programmer…

There's an argument to be made the other way too. If you're using an unusual default rounding direction and you care which direction your PI constant is rounded, you might prefer it if PI rounded in the same rounding direction as the rest of your floating point math. In that case you'd want a constant that is equivalent to PI under all rounding modes.

Re: Rust's language ergonomics initiative

#229

Post by [deleted] »

spraak wrote: post #126

> Right now, such a signature would be accepted, but if you tried to use any of map’s methods, you’d get an error that K needs to be Hash and Eq, and have to go back and add those bounds. That’s an example of the compiler being pedantic in a way that can interrupt your flow, and doesn’t really add anything; the fact that we’re using K as a hashmap key essentially forces some additional assumptions about the type. But…

[deleted]

Re: Rust's language ergonomics initiative

#230

Post by kzrdude »

killercup wrote: post #2

I especially like this approach: > Often, the heart of the matter is the question of what to make implicit. In the rest of this post, I’ll present a basic framework for thinking about this question, and then apply that framework to three areas of Rust […] What's proposed here is a universally good way to think about what to make implicit. The proposed changes to Rust are just some applications of this.

> What's proposed here is a universally good way to think about what to make implicit.

You might want to vary your kool aid a bit!

Post reply on HN