Hacker News Reader

Comment by jstx1 | Hacker News Reader

As a beginner (having finished the book and not much more) the example in the top comment is very difficult to parse and hold in my head. At a glance I have no idea what we're doing and why.

View on HN

More concretely, it's a pain to have to implement the same functions over and over for slightly different types, even when you're basically doing the same thing every time. Specifically, `Option` and `Result`, for example, both have `map` implemented for them (that's one lot of duplication), but also the consumers of the data structures need to know whether they've got an `Option` or a `Result` (and that's another lot of duplication if you want to allow consumers to use either an `Option` or a `Result` depending on what happens to be locally convenient to them). Sometimes you really do want to do different things depending on whether you've got an `Option` or a `Result`, but much of the time you don't care; you're only using it to signal errors, and you have no particular opinion on how you do so.

The example in the top comment allows you to implement what it means for a type to "have a `map` function". So it doesn't get rid of the duplicated effort on the "supply side" - we still have to implement the `Mappable` trait for each of `Result` and `Option` individually - but it allows the consumer to not care whether it's got an `Option` or a `Result`, by using only the `Mappable` trait instead. That is newly possible because the GAT feature allows the definition of a `Mappable` trait which contains fresh generics, and `map` is inherently a generic function.

Result and Option both implement Try, so if you actually just want to know whether to keep going or give up, the Try trait will give you a ControlFlow which says exactly that regardless of whether your input is an Option or a Result

Basically, before this you couldn't have generic types in traits, like this:

    trait X {
        type Y<Z>;
    }

You couldn't express "a thing that contains another thing" in one of those type expressions before, and also use the contained type. It's needed for Mappable, because it's an abstraction over the concept of modifying a value inside a container.

IMO the implementation that they have is a bit obtuse, but I don't know if you can fit something better in this language.

I really wonder about the usefulness of implementing a language feature to reduce the need to copy paste in an editor.

Generics are a language feature to reduce the need to copy and paste in an editor. For that matter, functions are a language feature to reduce the need to copy and paste in an editor.

Really? You don't see the problem with trying to maintain code that's been copy-pasted everywhere with slight differences? Doesn't it seem easier to maintain one implementation of something than N implementations?

Isn't that basically all language features? I could also write

    print("Hello")

    print("Hello2")

    print("Hello3")

    print("Hello4")

    print("Hello5")

(which I partially copy-pasted above) but I use a for-loop instead.

As a library maintainer, you can't copy-paste a line for a type that isn't written yet.

As a library user, you can't copy-paste a line for a type you just created in a library you don't maintain.

Being able to do what you describe lets a maintainer create an interface for all the future types that satisfy given requirements.

It is totally ok to not understand stuff, and it's totally ok to not want to learn it as long as you don't need it.

Rust is a language with plenty of things to learn, some of which take some time to get used to. And often, having a concrete need for something makes it easier to learn the associated technique.

As a non-beginner, I feel the same way. I'm not too worried about it at the moment, but it's early in the day (and week) and DST happened yesterday, sooo...

Reply on news.ycombinator.com