Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: “Explain GATs Like I'm 5 Years Old”

old.reddit.com

Post reply on HN
Print view View original

91–100 of 193 posts

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#91

Post by lucasyvas »

stonemetal12 wrote: post #88
lucasyvas wrote: post #72

The top Reddit example is tremendous. I'm passed being a Rust beginner, but I have a note to the Rust community: Your official examples are overcomplicated and bad and you should also feel a little bad. Stick to things like apple, orange, pear and you'll see much easier adoption than if you go with something like LendingIterator! Through the GAT process all I have seen is the same hyper-specific example used that con…

>Stick to things like apple, orange, pear While I am no pedagogical psychologist, I have witnessed mutiple times, how poor unrealistic examples give people a bad understanding of the thing they are trying to learn. Going with Apple, Orange, Pear would give people an idea of what the keywords did, but no understanding of when it was a good idea to apply the technique. I think that is one of the primary reasons OO suck…

The solution to this is to have two examples: Beginner and Practical/Advanced

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#93

Post by stephc_int13 »

There is a simple but fundamental observation that many experienced software engineers discover sooner or later: Reading/understanding code is much more difficult than writing it.

Because of that, programming languages should be designed to make the reading part as easy as possible.

What is the point of those high-level abstract features if they make reading/understanding the code too difficult?

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#94

Post by agentbellnorm »

leetrout wrote: post #8

GAT is Generic Associated Types https://blog.rust-lang.org/2022/10/28/gats-stabilization.htm...

I’ve seen this concept being talked about for a couple of days now. I even read the Reddit thread this morning.

But until now I didn’t know what the letters stand for. Thank you.

Death to abbreviations!

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#96

Post by gpderetta »

Nullabillity wrote: post #74
KallDrexx wrote: post #51

Earlier quoted context omitted.

I've yet to figure out why to use associated types instead of generic parameters, and every time I've seen an explanation I nod my head in confusion and carry on.

You can view generic parameters as "inputs", they are controlled by the consumer of the type/trait (you construct a `Vec ` because you want to store a bunch of `String` values). Associated types are "outputs", they are controlled by the impl (` as IntoIterator>::into_iter()` will always return a `std::vec::IntoIter `, because that is how the trait is implemented for `Vec `). You can often use generic parameters for "…

You can generalize this:

A: type level functions from types to (associated) types (i.e. normal generics)

B: type level functions from types to type level functions (either As or Bs) (GAT).

with generic parameters (i.e. higher kinded types, or template template parameters in C++) you could have type level functions that map type functions to (types or type functions), but once you have GATs you can fake them by passing to first order functions a type that has an associated type.

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#97

Post by GolDDranks »

wisnoskij wrote: post #45

I feel like they are making languages too complicated. Most projects should just be garbage collected, most don't need to deal with pointers or anything advanced. We need variables, functions, conditionals, loops, exception handling, struts, and a library with a bunch of standard utilities (including simple I/O and string managment). Everything else should be optional and kept out of sight unless you are looking for…

I think that if you feel like that, you might be looking into the wrong language. Go sounds like an exact match of what you want.

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#98

Post by orblivion »

brap wrote: post #52
nicoburns wrote: post #34

Earlier quoted context omitted.

I think the easiest way to understand it is this: Suppose you have a concrete type like Vec Regular generics enable you to make the contained type generic, so you have: Vec where T can be i32, u32, String, etc. GATs allow you to make the container generic. So you can have: T where T might be Vec, Option, Box, etc.

Thanks, this was much easier to understand than the original article. What will I use this for? Usually for the “T” to be useful it needs to have some interface. In Java I’d just use Collection or something more abstract.

I forget what exactly a GADT is (even though I've used Haskell a bit before). But just going by the linked example from Reddit, you could make a generic `map` function that worked on any container type. You'd have to implement the map function separately for each type. But then you could make a bunch of utility functions that you'd implement once that use the generic `map` under the hood, and all of those container types would be able to use those utility functions.

Not a Rust guy but I think that's the idea.

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#99

Post by dathinab »

lucasyvas wrote: post #72

The top Reddit example is tremendous. I'm passed being a Rust beginner, but I have a note to the Rust community: Your official examples are overcomplicated and bad and you should also feel a little bad. Stick to things like apple, orange, pear and you'll see much easier adoption than if you go with something like LendingIterator! Through the GAT process all I have seen is the same hyper-specific example used that con…

GATs are fundamentally a higher-level abstraction similar to higher-kinded types (you could see them as a very small subset of HKT).

This means:

- they are not trivial no matter how much you bend it

- you should rarely use them in your day to day work (use as in "create traits with GATs")

- they allow you to abstract over certain things in a much nicer way. This thinks matter a lot for certain kinds of libraries. Which is why we do include them even through they are not simple (i.e. once some of the current limitations are lifted I expect there is a high chance for them to be used in the next major version of all of actix-web, axume, tower and a bunch of async libraries).

Through I agree that the example on the blog announcement and on reddit aren't grate. If GATs would just be for the problems described there adding them to the language wouldn't be worth it. (I mean adding a different more complicated and harder to use iterator trait which only matters for a small handful of use-cases really isn't enough reason to add such complicated language feature, on the other hand being able to abstract over async functions properly is a major boon).

Another problem is that some of the "better" examples currently can't be implemented in a straight forward way to the limitations which GATs still have for now.

Re: Rust: “Explain GATs Like I'm 5 Years Old”

#100

Post by kibwen »

bsaul wrote: post #18
josephcsible wrote: post #14

Earlier quoted context omitted.

Rust getting more of Haskell's type system features is a good thing. The stronger your type system is, the more mistakes you can discover as compiler errors instead of runtime bugs.

If a typesystem has any impact on the popularity of a language, then i assume rust doesn’t want to copy too much of haskell and needs to know where to stop..

The whole design of GATs is predicated on the notion that Rust doesn't want to go as far as Haskell does here. See boats' comment: https://news.ycombinator.com/item?id=33506540
Post reply on HN