There is a simple but fundamental observation that many experienced software engineers discover sooner or later: Reading/understanding code is much more difficult than writing it. Because of that, programming languages should be designed to make the reading part as easy as possible. What is the point of those high-level abstract features if they make reading/understanding the code too difficult?
Because there's no correct level of abstraction. There's only appropriate abstractions for different situations.
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.
As was noted at the beginning of the referenced explanation:
There is a simple but fundamental observation that many experienced software engineers discover sooner or later: Reading/understanding code is much more difficult than writing it. Because of that, programming languages should be designed to make the reading part as easy as possible. What is the point of those high-level abstract features if they make reading/understanding the code too difficult?
Because there's no correct level of abstraction. There's only appropriate abstractions for different situations.
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 hope you don't. To establish my credentials for this comment - GATs were my idea. The entire point of GATs was to carve out a design space that solved peoples' problems without being so high-minded as monads and HKT and so on. Unfortunately, a lot of people who like monads like to talk about GATs in the same way. But its really as simple as this: when you add an associated type to a trait, you can make that type ge…
Not trying to make you feel like you have failed, but whenever I encounter language features on this level - aka not comprehensible for a mortal like myself - I do tend to want to shamefully turn away from this profession entirely. The good news is that I am most likely a total dunce.
I wish I could become reasonable with rust because I do like the concepts that I think I grasp.
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…
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.
Thanks, this was much easier to understand than the original article. What will I use this for? Usually for the “T” to be useful it needs to have some interface. In Java I’d just use Collection or something more abstract.
I forget what exactly a GADT is (even though I've used Haskell a bit before). But just going by the linked example from Reddit, you could make a generic `map` function that worked on any container type. You'd have to implement the map function separately for each type. But then you could make a bunch of utility functions that you'd implement once that use the generic `map` under the hood, and all of those container t…
Just so that we're clear on acronyms for everyone out there, "GADT" is a computer science term for "generalized algebraic data type", which has no relation to "GAT", which is just Rust terminology for generics in associated types (even in Rust, I doubt that anyone will bother to refer to "GAT" in the coming years, rather than just lumping them in with the concept of associated types in general; there's really no need to teach them separately).
What you're describing sounds to me like higher kinded types, which are of some relationship to GATs (GATs enable a better encoding of higher kinded types as I understand it), but are not GATs. https://docs.rs/higher/latest/higher/
> as I understand it You could be 100% right (I have no idea, but it sounds reasonable), but this entire question really hits home that Rust has tons of basically incomprehensible design features. The worst part about features like this are that a few smart people will actually use them (whether because they're powerful features, or just because they feel powerful when using them), and then render their code incompre…
The problem is people who are smart enough to use fancy features, but not wise enough to show restraint.
The question is do we inhibit the wise to protect us from the unwise? The answer might be yes. I enjoy learning about power features so I hope not.
The part that says `T `. GATs don't allow you to do that, not directly. GATs allow you, as said by Boats in https://news.ycombinator.com/item?id=33506540 , have a generic type as an associated type, nothing less, nothing more. If you want to express `T `, GATs _enables_ you to do that as a kind of a distorted encoding, but it's not as simple as https://news.ycombinator.com/item?id=33505810 makes it seem.
Bring able to abstract over Rc/RefCell and Arc/Mutex with marker types seems pretty useful. It's not directly HKT but it enables use cases that would otherwise be supported by HKT.
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…
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 think the easiest way to understand it is this: Suppose you have a concrete type like Vec Regular generics enable you to make the contained type generic, so you have: Vec where T can be i32, u32, String, etc. GATs allow you to make the container generic. So you can have: T where T might be Vec, Option, Box, etc.
Note that this isn't directly what GATs are, but you can use marker types to achieve this effect.