I second this as a recent learner.

I have been learning Rust by writing some toy code over the weekends, and 9 out of 10 times when I hit a roadblock and went to my local Rust Users Group, the answer was "just wait for GAT". Turns out these patterns occur organically out of fairly mundane needs of abstraction (e.g. the now-infamous `LendingIterator`), and especially for me as a C++17/20 daily driver, _arbitrary_ limitations on expressivity.

Don't get me wrong --- Rust feels a lot more expressive than C++17/20 in the vast majority of areas, but for the rest maybe 10%, it's pothole land for stable Rust. Eliminating some of these potholes is a big win for Rust's adoption story.

Generics being a form of a compiler only dependently typed lambda axis is still infinitely more complex than chaining product & coproduct (sum) data types.

Please elaborate? Keep in mind that Rust isn't about making the simplest or most expressive language possible. Rather, it's about pushing the envelope on what sort of expressiveness we can soundly get away with while still benefiting from mechanical sympathy given the current state-of-the-art of optimizing compilers (and, also, while not being so foreign as to cause C-style language programmers to run away screaming).

It's labeled "stable", but this seems to require a bit more understanding by implementers than simple composition to safely use, specifically the part about "where clauses [being] required when those bounds can be proven in the methods that construct the GAT or other associated types that use the GAT in the trait".

> Conceptually it's "just" the ability to take one existing concept, X, and apply it to another existing concept, Y.

Yes, precisely. This is the literally what parent was talking about, "programming language abstractions [...] stacking on top of each other"

As opposed to creating completely different ways of doing things from the existing patterns?

The parent was echoing the common complaint (exclusively from people who don't actually use rust, in my experience) that rust is getting "too many features."

But as others in this thread has pointed out, features like GATs actually make the language simpler, because they're removing weird (and to a new user, unexpected) restrictions on existing features. This will then unblock removing other surprising restrictions, like the inability to use async functions in traits.

Rust takes the philosophy that it's better to do hard work in the compiler in order to make the language simpler and easier for users. That's what's happening here.

I thought it was doing hard work in the compiler to make the binary safe for processors.

Try thinking of it less as a new abstraction and more of removing a restriction from a previous abstraction. It is pretty easy to run into a situation where you want them without even knowing what the concept of a GAT is.

Rust gets a lot of unfair criticism of "adding new stuff" when a lot of what is "added" is actually removing restrictions and making it where a developer has less to learn.