Rust: “Explain GATs Like I'm 5 Years Old”
old.reddit.com
Rust: “Explain GATs Like I'm 5 Years Old”
1–10 of 193 posts
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#2As 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.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#3No doubt they'll needlessly spread to code that doesn't require them - happened already with async and that is much, much simpler concept (than one of the most complex things, GATs).
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#4As 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.
Basically, before this you couldn't have generic types in traits, like this:
trait X {
type Y;
}
IMO the implementation that they have is a bit obtuse, but I don't know if you can fit something better in this language.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#5I seriously doubt a 5 year old can understand this explanation.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#6No doubt they'll needlessly spread to code that doesn't require them - happened already with async and that is much, much simpler concept (than one of the most complex things, GATs).
Personally, I consider GATs a lot easier to understand than async. It doesn't transform my code into something completely different than I'm seeing. It's just the ability to put a generic parameter in one more place, paradoxically reducing the number of traits.
It's something that you naturally try to write when you don't know it's not supported, rather than an additional thing to learn.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#7As 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.
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.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#8GAT is Generic Associated Types
https://blog.rust-lang.org/2022/10/28/gats-stabilization.htm...
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#9No doubt they'll needlessly spread to code that doesn't require them - happened already with async and that is much, much simpler concept (than one of the most complex things, GATs).
This is different though. Async colors functions, so once you’ve got something that has an async interface, you either go async too, or have to do shenigans to use it in a blocking way. GATs will just let library authors make more flexible interfaces.
If there’s anything to worry about then that may be compile times of complex codebases. I haven’t measured anything but just as a rule of thumb more generic code means longer compile times in Rust-land.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#10Rust better figure out quick how they can shut down the Haskell & C++ language artisans or it will be their downfall (in favor of something like Zig).