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

141–150 of 193 posts

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

#141

Post by idontpost »

gunapologist99 wrote: post #59
philzook wrote: post #50

Earlier quoted context omitted.

What you're describing sounds to me like higher kinded types, which are of some relationship to GATs (GATs enable a better encoding of higher kinded types as I understand it), but are not GATs. https://docs.rs/higher/latest/higher/

> as I understand it You could be 100% right (I have no idea, but it sounds reasonable), but this entire question really hits home that Rust has tons of basically incomprehensible design features. The worst part about features like this are that a few smart people will actually use them (whether because they're powerful features, or just because they feel powerful when using them), and then render their code incompre…

> The worst part about features like this are that a few smart people will actually use them (whether because they're powerful features, or just because they feel powerful when using them), and then render their code incomprehensible to the mere mortals who have to support their code in the future.

I really don't understand what motivates this kind of petty hostility.

It could have been written about any of a thousand language features that didn't exist in assembly and now exist in higher level languages, and it would be just as sad.

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

#142

Post by tialaramex »

agentbellnorm wrote: post #94
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!

It's no different in everyday life. This was an appropriate title for the Rust thread, but is too terse for Hacker News.

If I say to my mother "Hannah told me she'd be away for Christmas" we both understand who is meant, my sister. If I say that to my friend Dave it's unclear. Which Hannah? We have a mutual friend called Hannah, I have a sister named Hannah, or maybe I mean the Hannah he works with. So I should be more specific in that context.

Being obliged to be fully specific all the time is no problem for a machine but it's tiresome for humans, so no, I do not agree with "death to abbreviations". Maybe HN rules should encourage people to expand abbreviations when citing material from elsewhere that could be unfamiliar to most readers. As it is, hey, free Internet points for whoever first expands the abbreviation in a comment.

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

#143

Post by Twirrim »

withoutboats2 wrote: post #134
flippinburgers wrote: post #104

Earlier quoted context omitted.

Not trying to make you feel like you have failed, but whenever I encounter language features on this level - aka not comprehensible for a mortal like myself - I do tend to want to shamefully turn away from this profession entirely. The good news is that I am most likely a total dunce. I wish I could become reasonable with rust because I do like the concepts that I think I grasp.

You're begging the question when you say that GATs are "not comprehensible for a mortal like myself." My entire point is that they were designed not to be incomprehensible. What is "not comprehensible for a mortal" in this situation is why adding a generic to an associated type is a long-anticipated feature that took years of development to support. This is related to the "incomprehensible" discussion that occurs aro…

> My entire point is that they were designed not to be incomprehensible.

It's frustrating that the documentation / announcement always seems to go for the most complicated way to explain just about everything, in what I assume is an attempt to ensure it's the most comprehensive explanation, in the smallest number of lines. It's fine to provide different levels of explanation/examples.

Numerous times I read stuff and think "Nope. Absolutely no idea why I'd use that, and I'm not entirely sure I have even half a clue what it's trying to do" until much much later when I see more simplistic practical applications of it and comprehension slowly dawns about what was being explained.

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

#144

Post by pjmlp »

Rusky wrote: post #122
pjmlp wrote: post #80

Earlier quoted context omitted.

Might be a bit of job deformation, knowing C++ since 1993, and I still need to get myself used to those patterns. Maybe I should delve again into GADTs in OCaml, before having a second look.

GATs are completely unrelated to GADTs.

From my point of view they look quite similar from language type theory point of view, plus the machinery for affine types.

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

#146

Post by Rusky »

pjmlp wrote: post #144
Rusky wrote: post #122

Earlier quoted context omitted.

GATs are completely unrelated to GADTs.

From my point of view they look quite similar from language type theory point of view, plus the machinery for affine types.

The only thing similar about them is the acronym:

GATs are generic type aliases which are defined inside traits.

GADTs are generic sum types with extra constraints on which variants may be used with which type arguments.

There is no reasonable way in which they are "quite similar," nor do either of them have anything at all to do with affine types.

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

#147

Post by dllthomas »

nicoburns wrote: post #34
the__alchemist wrote: post #28

I'm filing this one along with Monads and Haskell as programming concepts that I'll never understand. Rust is my favorite language, but that explanation, lauded directly below it as This is personally the easiest to understand example I've seen of GATs. , was incomprehensible.

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.

The ability to just use T for Vec, Box, etc, anywhere you might want to is "higher kinded types" - GATs only allow it specifically for "associated types" on a trait.

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

#148

Post by karmakaze »

celeritascelery wrote: post #132
karmakaze wrote: post #84

Earlier quoted context omitted.

I've not heard this called sub- or pattern types before. Perhaps the rfc syntax is complicating the discussion. We have struct and tuple in Rust where tuple is an ad-hoc/anonymous struct where only the number and order of member types matter. We have enum which are nominal types. We don't have the ad-hoc/anonymous version of them where only the set of possible types matter. In TypeScript, F#/OCaml they would be like…

I first heard about this feature in OCaml. I got the name subtype or pattern type from this thread: https://internals.rust-lang.org/t/thoughts-on-pattern-types-...

Thanks for the reference. I can see how values of type A could be considered as a subset of values of type A|B, but I think the 'any value of type A' subset of type A|B is more related to types and less about restricting the range/set of values for a type.

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

#149

Post by nrc »

josephcsible wrote: post #140
nrc wrote: post #40

Earlier quoted context omitted.

No, they're not. GATs are used internally in the compiler to implement async methods, but there is absolutely no need for them to be in the language for that (just like generators are used to implement await but are not part of the (stable) language). GATs may or may not be useful, but IMO the actual real-world use cases are pretty weak.

Even if the use cases outside the standard library were weak, given that the work needs to be done anyway for the standard library, why wouldn't you expose them?

To be clear, there are not use cases in the std lib. The use case is as an intermediate representation for the compiler, and that is no motivation for inclusion in the language (in the same way that we don't have vtables or register allocation in the surface syntax)

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

#150

Post by jstimpfle »

kibwen wrote: post #117
stephc_int13 wrote: post #93

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?

But this feature makes reading code easier? It allows library authors to absorb the complexity into themselves, allowing them to present easier and more convenient APIs for the users of those libraries. Because programs that consume libraries outnumber the libraries themselves, that results in a net reduction in complexity.

I disagree that this makes reading code easier. It is tremendously more complex to understand a generic API precisely because it is generic - it must cater to a huge variety of use cases, and consequently has more nuts and bolts, and knobs to turn.

Now this can be the right choice in many situations, when the higher cost in understanding the API is amortized over a larger number of uses. But in general I much prefer simple and specialized APIs and don't see much of a need for genericity. This includes error handling and resource allocation.

Post reply on HN