Hacker News Reader

Comment by lucasyvas | Hacker News Reader

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 confuses the hell out of people that just need the "Hello World" version.

If you want, I will volunteer to be the test subject "dumb" Rust programmer to vet the quality of future examples.

Tangentially related - here's a WASM example that goes from "Hello World" to Conway's Game of Life (I shit you not, that's actually how the tutorial progresses):

https://rustwasm.github.io/docs/book/

View on HN

I think this is a failure of messaging rather than a failure of example-writing. Despite all the hullabaloo, GATs are not a "feature", they're just the lifting of an arbitrary restriction that used to exist in the typechecker. There doesn't need to be a section on GATs in any Rust book, for example. It's just generics in associated types. The examples you've seen like LendingIterator are not intended to be pedagogical, they're intended to showcase some specific cool things that people (who are presumed to already know Rust) will now be able to do, and preview things that might someday find their way into the stdlib as a result of this new ability.

For sure, if people want to learn how to use generics in associated types, then there can be examples catering to those users. But I think that framing this as a "feature" makes people feel like they need to go out of their way to "learn" them, when in reality users will either try to use them naturally (as a result of prior knowledge about generics and traits) and it will "just work" and they'll never think twice about it, or they'll never try to use them because they see no need to based on what they're trying to write.

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.

>Stick to things like apple, orange, pear

While I am no pedagogical psychologist, I have witnessed mutiple times, how poor unrealistic examples give people a bad understanding of the thing they are trying to learn. Going with Apple, Orange, Pear would give people an idea of what the keywords did, but no understanding of when it was a good idea to apply the technique.

I think that is one of the primary reasons OO sucks so badly today. Everyone was trained on Fruit, Shapes, and Cars so they know the keywords, but don't have the foggiest clue of when it is a good idea to use them.

Not that I am suggesting LendingIterator! is a super wonderful example either. A good motivating example like 95% of the difficulty, and reward of programming tutorials.

The solution to this is to have two examples: Beginner and Practical/Advanced

I think the point is that even for beginners these examples are dumb. If you want to explain OOP and inheritance you can use simple but realistic examples, like `class Shape { fn draw() }`, `class Rectangle extends Shape`, `class Circle extends Shape`, rather than `class Dog extends Animal` or some dumb stuff like that.

Bingo

At only twice the cost! A bargain.

Maybe we should be able to parametrize over difficulty :P

The post you're complaining about starts with "because everyone likes to use that LendingIterator example I would offer a bit non-trivial example." It sounds like they are already doing that.

As a Rust beginner, have to completely agree... A lot of the examples are overtly complex. Beyond this, sometimes finding appropriate use case examples for libraries harder still. Mostly in that you have to have a very deep knowledge base to even begin in a lot of ways. I mean, I get it, but it's still much harder to get your feet wet beyond "Hello World" type examples in practice.

Note: been a rust beginner for a while, as I play with it, (re)read a couple books I have on Rust, but then set it aside again as I'm unable to justify using it vs. just getting something done. I really like a lot of the concepts but digging in has been repeatedly difficult.

I agree that this can be simplified further but at the same time I disagree with the "it needs to be understandable to beginners!" attitude.

Some concepts aren't for beginners. This includes most things that have to do with more advanced type theory or for example category theory.

ELI5 GATs? ELI5 Monads? If we could we would.

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.

> Because everyone likes to use that LendingIterator example I would offer a bit non-trivial example

Android devs are having flashbacks to Thermosiphons

This is exactly why open source communities need more than programmers.

Reply on news.ycombinator.com