Rust: “Explain GATs Like I'm 5 Years Old” • Hacker News Board

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

#151

Post by nrc » Mon, Nov 07, 2022, 6:36 PM UTC

kibwen wrote: post #43

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.

Yes, I've read the stabilization thread and I'm aware of your stance. :P Whether or not it's exposed, the mechanism still needs to exist in the compiler, and enough library authors are clamoring to use it that I think the argument in favor of exposing them is stronger than you're giving it credit for. You mention generators, but a lot of people are clamoring for those as well, and I fully expect them to be exposed to…

My point is that there or may or may not be reasonable justification for adding GATs, reasonable people can disagree on that. But async methods are not part of that justification. Similarly, generators may or may not be good for the language (IMO they would be good to add, if they can be made to work etc.) but they didn't need to be part of the language to add await.

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

#152

Post by insanitybit » Mon, Nov 07, 2022, 6:41 PM UTC

Jweb_Guru wrote: post #135

insanitybit wrote: post #125

Earlier quoted context omitted.

I think 90% of the reason why people have a hard time with GAT is because there aren't a ton of use cases. From what I can tell, GAT is quite simple - it is just like all other Rust generics except that now the generic can be in a new place. Rust has made it years without needing this (granted, a few things have been less than ideal because of it) because, for the most part, people have not needed to reach for this t…

It's needed for a lot of features people desperately want. Async functions in traits, closures that return futures where you need to run the future in a loop, and array indexing that doesn't necessarily return a reference, are three examples of things that essentially need GATs in order to be implemented without allocating. You may not feel like you missed it but not having that leads to a ton of ugly workarounds in…

The vast majority of users do not desperately want async functions in traits, they just use async_trait and go "it'll be cool when GATs are done". Besides, no one is going to use GAT for async traits, that will be done for them by the compiler.

Obviously there are use cases for GAT, what I'm saying is that they're going to be in very generic library code, which I don't think most users are writing.

For libraries like Hyper, which prioritize being extremely generic (it's split into a ton of reusable crates), which aims to serve as a very low level set of generic primitives for HTTP, yes it will come up.

Hyper is a great example of a use case that 99.99% of developers are not going to be able to relate to because they aren't building a set of completely generic http primitives. It's an important use case, it's just not relatable.

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

#153

Post by wisnoskij » Mon, Nov 07, 2022, 6:49 PM UTC

Smaug123 wrote: post #63

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…

`&` and `'` do mean something: `&` indicates something that's borrowed, and `'` indicates a lifetime. (`static` is a specifically blessed identifier given to a certain lifetime.) This is explained in https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#... , and the static lifetime is explained in https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#... .

It looks like I will just have to bite the bullet and actually read the rust book back to front. I find static particularly confusing because of the seemingly contradictory meanings that are all jumbled up in my head. The English meaning of immutable, the Java meaning of instance agnostic, and this Rust meaning of immortal lifetime.

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

#154

Post by insanitybit » Mon, Nov 07, 2022, 6:54 PM UTC

atemerev wrote: post #65

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 can program in Scala and Haskell relatively easily. I still struggle with Rust's lifetime abstractions and things like this: impl LendingIterator for Map where I: LendingIterator, F: for Mapper >::Item>, { type Item = dyn for GivesItem >::Item>>::Output, >; fn next(&mut self) -> Option >::Item> { self.iter.next().map(&mut self.mapper) } } Haskell is so much easier.

I feel you, this is some particularly rough Rust code, combining quite a lot of stuff that I don't think I directly interacted with for my first few years.

You have `for`, which I believe is probably the most complicated part of the language. That's a Higher Ranked Trait Bound, https://doc.rust-lang.org/nomicon/hrtb.html

It just means "for all possible lifetimes 'a" as opposed to a single specific instance of a lifetime. Honestly, my brain kinda knows when to use it and I've never bothered to push past that point and into "and I understand why it knows when to use it".

You have nested types, which always makes things a bit messy, but then you have the "I have a type, it implements a trait, and I want to refer to the associated type for that trait's implementation for that type".

ie: ::Associated

Oof. But once you know what it is it's quite clear and explicit. You wouldn't want to do `MyType::Associated` because what if MyType implements multiple traits that have associated values named Associated? Rust prefers explicit.

I actually use this all the time now because it makes refactoring so easy to only refer to types through generic paths. If I change "Associated" I don't have to update anything at all.

When you nest these it gets extra messy, but it's just the same thing. Mapper's second generic parameter is just the associated type of some other thingy. I wonder if some type Aliasing would help, idk.

Then there's `'_`, which I've never bothered to use because I learned rust before it was a thing and so I just don't really care. The irony is that `'_` exists to make things clearer - it's just an annotation that says "there's a lifetime here that we don't actually have to write down, but I'm writing it so that you know what it is and that it's not some other lifetime".

https://dev-doc.rust-lang.org/beta/edition-guide/rust-2018/o...

So yeah, I get it. Rust is very explicit, and when you have a lot of nested stuff like this that explicitness can look a bit overwhelming. But I'll say that, knowing all of this, I can look at that code and trivially parse it because there's no ambiguity whatsoever.

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

#155

Post by oxff » Mon, Nov 07, 2022, 6:55 PM UTC

celeritascelery wrote: post #61

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 will agree with you that most languages should just be gc. Rust is niche; targeted at applications where you need control over memory and layout. It is not a good general purpose language. That being said, most of things you pointed out as “no reason to be this complex” do have good reasons. String and &str could be renamed to StringBuf and StringSlice. The String type lets you manipulate the string value, but it i…

> without really adding complexity

Pretty sure many relevant contributors have said it is the most complex language feature since async ..

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

#156

Post by wisnoskij » Mon, Nov 07, 2022, 6:59 PM UTC

kibwen wrote: post #86

Smaug123 wrote: post #63

Earlier quoted context omitted.

`&` and `'` do mean something: `&` indicates something that's borrowed, and `'` indicates a lifetime. (`static` is a specifically blessed identifier given to a certain lifetime.) This is explained in https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#... , and the static lifetime is explained in https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#... .

It's also possible to have `&str`s with smaller lifetimes than `'static`, in which case you will have a different lifetime specifier there.

Ah, so this probably tells the compiler where to insert the free? If I gave it a local lifetime it would free the memory on function return for example, even if I tried to return a reference to it? Basically Rust just forces you to code in the memory freeing at the definition state of variable creation?

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

#157

Post by insanitybit » Mon, Nov 07, 2022, 7:03 PM UTC

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…

Garbage Collection is extremely complicated. It is a whole other program running to manage your memory using extremely complex, hyper optimized algorithms that have lots of best and worst case scenarios depending on which one you use.

GC implementations can very easily make code confusing. Consider `finalize` in Java - a destructor that gets called at a completely indeterminate period of time, making it a very confusing tool for resource management.

I find Rust trivial by comparison. But isn't that interesting, how we all view simplicity so differently?

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

#158

Post by pjmlp » Mon, Nov 07, 2022, 7:07 PM UTC

Rusky wrote: post #146

pjmlp wrote: post #144

Earlier quoted context omitted.

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.

Where is the type theory for Rust's GATs for us to educate ourselves?

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

#159

Post by wisnoskij » Mon, Nov 07, 2022, 7:14 PM UTC

insanitybit wrote: post #157

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…

Garbage Collection is extremely complicated. It is a whole other program running to manage your memory using extremely complex, hyper optimized algorithms that have lots of best and worst case scenarios depending on which one you use. GC implementations can very easily make code confusing. Consider `finalize` in Java - a destructor that gets called at a completely indeterminate period of time, making it a very confus…

I did want to say Rust was complicated, I meant to say it was complicated to learn. You never need to learn the Java syntax finalize, it is invisible until you have a problem where that is the solution. Similar to Java templates or overloading they dont exist until they are the solution to a problem you are having.

My critique is that Rust appears (and I am probably wrong) to have a problem where syntax for complicated language features appear in the simplest code that even a day 1 grade 8 student needs to memorize, even if they wont understand it until the second year of university.

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

#160

Post by Macha » Mon, Nov 07, 2022, 7:22 PM UTC

gpderetta wrote: post #128

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…

The example is indeed very good, but I think it is more about faking HKT with GAT and I'm not sure that was the primary motivation for GAT in rust.

I thought that was pretty much the motivation. HKTs are hard - hard to implement with Rust's low overhead goals, and hard to teach to newbies. My understanding is that GATs came about as some simpler lower hanging fruit to try first.