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 no

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.