I seriously doubt a 5 year old can understand this explanation.
I mean, a GAT is just a monoid in the category of endofunctors, after all.
GATs don't actually let you go full monad, so not quite. :P
Rust: “Explain GATs Like I'm 5 Years Old”
31–40 of 193 posts
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#32I'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.
Same here. I presume that one day I will have to write something using a GAT, and then the understanding will click with me, even if I don't speak the terminology.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#33I'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.
Yeah. I'd like to meet the 5-year-old that understood that.
edit: the "What are GATs" paragraph in the link posted by @leetrout is much more usable.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#34I'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
Vec
T
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#35I'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.
You mention that you use Rust. In that case, you're almost certainly familiar with generics, and you're likely familiar with associated types. If you've ever found yourself struggling to write an associated type that needed a generic parameter, this feature is for you. And if you haven't ever needed to do such a thing, that's totally fine, and you can happily ignore it and content yourself with benefiting from libraries that are now able to expose simpler and more powerful APIs by leveraging this feature under the hood.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#36I'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.
Same here. I presume that one day I will have to write something using a GAT, and then the understanding will click with me, even if I don't speak the terminology.
Both generics and traits are mostly for library authors trying to make expressive APIs. If you're not creating libraries but instead consuming libraries, then it may be natural for you to never need to reach for this feature.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#37Earlier 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.
> The stronger your type system is... I used to think a stronger and stronger type system was a universal good, then I got experience with code written by architecture astronauts[1] armed with such type systems. Knowing exactly which kinds of things to make impossible at compile time and which not is absolutely an art form. Unfortunately, such type systems seem to result in so many nightmares. https://www.joelonsoftw…
The linked article talks about abstraction, and that you could abstract so much that the concrete problem doesn't fit in your abstraction. I.e., your abstraction is broken.
I think that is precisely why OOP started to disappoint (tbh: I also think many people did not understand OOP really well). Haskell pushes you to compose types instead of building inheritance hierarchies. Multiple inheritance turned out to be a bad idea too, so yeah, OOP program do typically not have the best models of the problem domain they were intended to model.
At the other end of the spectrum you see people just give up: everything is a kind of dict or a string, or wo knows, null? Looking at you php, python, javascript..
All the improvements you see in todays OOP languages are ideas stolen from functional languages like Haskell. What Haskell could have done better is be strict instead of lazy by default.
To model the real world and make assumptions explicit, a type system, as Haskell gives you, is so nice.
I agree that you can make types also really abstract like some people indeed do. It's fine if you do that as a library author, but you should offer a facade with some simpler type aliases. If you stick to Haskell98 and possibly enable GADT support you already get an immensely powerful language.
Also, I have not used Haskell for a while, but I heard the compiler error messages have become way more human friendly these days, so that helps with complex types.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#38I'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.
You mention that you use Rust. In that case, you're almost certainly familiar with generics, and you're likely familiar with associated types. If you've ever found yourself struggling to write an associated type that needed a generic parameter, this feature is for you. And if you haven't ever needed to do such a thing, that's totally fine, and you can happily ignore it and content yourself with benefiting from librar…
I appreciate the explanation. I've been more of a firmware or application developer in Rust than library developer, so will keep this in the hip pocket.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#39I'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.
Same here. I presume that one day I will have to write something using a GAT, and then the understanding will click with me, even if I don't speak the terminology.
Many C++ developers have walked that path, never to be seen again.
Re: Rust: “Explain GATs Like I'm 5 Years Old”
#40Rust 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).
GATs are an essential part of Rust's long-term async/await story. It's not language-wankery, this is driven by actual real-world use cases. Rust's own stdlib would have benefited from this in many places had this feature existed years ago.
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.