3 ms·

Anyone else kind of losing the thread of all the programming language abstractions that Rust is stacking on top of each other?

by jstx1 4y ago

numeromancer 4y ago
In this case it is the lack of this ability which, when you meet it, is unexpected and unintuitive. Think of this as a design-level bug-fix.
whatshisface 4y ago
GATs are a really straightforward extension of what the language already has. All this means is that now a generic type can take a value as a parameter, for example there could be a generic fixed-length array, which took a length as a parameter. In the past libraries had to hack their way around this by having huge tables of types named like, "N1, N2... N16... N1003", which were passed to generic signatures to indicate to the type system how big something had to be. I don't think this makes the language more confusing, because putting an integer inside of the generics brackets is something that previously you might try to do, if you didn't know it wasn't allowed. In fact, I would go so far as to say that this is a compiler feature, rather than a language feature, because it fills in a semantic hole that already existed in the way Rust programmers thought about Rust types. :-)
- deleted 4y ago
  [deleted]
- petrosagg 4y ago
  The feature you're referring to is const generics which is different than generic associated types (GATs) which is the feature being stabilized. min_const_generics have been on stable for while
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - tialaramex 4y ago
    Note however broader Const Generics, allowing you to use your enumerated Hat type as a constant parameter to a type, producing PigInAHat<Hat::StrawBoater> as a distinct type from PigInAHat<Hat::Top> are not yet in stable Rust and aren't on the near horizon. The idea is that any types which Rust can see for itself can be trivially compared for equality will eventually qualify for this purpose, so your Hat enumeration, or a structure with four integers and a boolean in it, or anything that Rust says "Yeah, I'll just memcmp that for equality" would qualify. No floating point numbers, no strings, nothing actually crazy. But this is in some undefined future, for now we just have min_const_generics which is basically the fundamental integral types as constants in generics.
avgcorrection 4y ago
Sure. It seems like a pattern for languages that try to be more pragmatic. Instead of a Big Idea, turtles-upon-turtles approach that would take years to finalize in a form that doesn’t invalidate everything that came before it, one goes for an initially good enough approach and then release more and more features which to the insider might seem very holistic but to an outsider (like me) just sound like Static Runtime-Bounded Polyhydral Lambda Cube Type Capabilities and Associates.
aidanhs 4y ago
I recently refactored some traits that had a lot of repetitive noise in the generic type parameters (which end up being reflected in function signatures etc). I went about this without really being overly aware of GATs and their status, but the code that I naturally ended up with required enabling them. So from my point of view, I didn't really need to understand what GATs were bringing - it's a lifting of restrictions that would have previously felt arbitrary.
kibwen 4y ago
Conceptually it's "just" the ability to take one existing concept, generics, and apply it to another existing concept, associated types. Under the hood there's a lot going on to make that work with the type system, and there's some advanced things that this now enables, but as far as a beginner is concerned this is less "a new feature" than "lifting a restriction on an existing feature". By analogy, imagine a version of C where you can't use a struct as a member of a union. Then, a new version of C comes along letting you use structs in unions. We could call that a new feature, "struct-in-unions"... or we could just call it lifting a restriction on an existing feature. It's entirely natural to want to use structs with unions, and it's probably what a learner of the language intuitively expects should be possible. Likewise, a learner of Rust probably expects that any type can be used as an associated type, and before today that wasn't true, and after today that is true.
- smilekzs 4y ago
  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.
- capableweb 4y ago
  > 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"
  - necubi 4y ago
    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.
epilys 4y ago
Well you don't have to use it just because it is added, but it will allow library writers to provide more ergonomic interfaces. This specific type system feature allows for stuff that weren't possible before but make sense and you'd expect to be valid code that compiles: the most common example is the lending iterator. Have a struct that owns a vector of data. Can you implement an iterator that can return a reference of each item when you call next()? Not without GATs, because each time you return from next() you're creating a new lifetime that doesn't exist in your trait definition. That's why current standard library iterators are basically structs that own a reference to what you iterate. See the GAT RFC which explains this concept much better than I can: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md https://github.com/rust-lang/rfcs/blob/master/text/1598-gene... TL;DR it's not a "new" feature per se but something that could have been present from the beginning without making the language different.
deleted 4y ago
[deleted]
api 4y ago
This isn't so much the introduction of a new concept or abstraction as the removal of what feels like an artificial limitation. You should be able to use a generic in a trait in a type defined in that trait, and when you can't it feels broken.

Anyone else kind of losing the thread of all the programming language abstractions that Rust is stacking on top of each other?

by jstx1 4y ago

Anyone else kind of losing the thread of all the programming language abstractions that Rust is stacking on top of each other?

numeromancer 4y ago

In this case it is the lack of this ability which, when you meet it, is unexpected and unintuitive. Think of this as a design-level bug-fix.

whatshisface 4y ago

GATs are a really straightforward extension of what the language already has. All this means is that now a generic type can take a value as a parameter, for example there could be a generic fixed-length array, which took a length as a parameter. In the past libraries had to hack their way around this by having huge tables of types named like, "N1, N2... N16... N1003", which were passed to generic signatures to indicate to the type system how big something had to be. I don't think this makes the language more confusing, because putting an integer inside of the generics brackets is something that previously you might try to do, if you didn't know it wasn't allowed. In fact, I would go so far as to say that this is a compiler feature, rather than a language feature, because it fills in a semantic hole that already existed in the way Rust programmers thought about Rust types. :-)

deleted 4y ago
[deleted]
petrosagg 4y ago
The feature you're referring to is const generics which is different than generic associated types (GATs) which is the feature being stabilized. min_const_generics have been on stable for while
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- tialaramex 4y ago
  Note however broader Const Generics, allowing you to use your enumerated Hat type as a constant parameter to a type, producing PigInAHat<Hat::StrawBoater> as a distinct type from PigInAHat<Hat::Top> are not yet in stable Rust and aren't on the near horizon. The idea is that any types which Rust can see for itself can be trivially compared for equality will eventually qualify for this purpose, so your Hat enumeration, or a structure with four integers and a boolean in it, or anything that Rust says "Yeah, I'll just memcmp that for equality" would qualify. No floating point numbers, no strings, nothing actually crazy. But this is in some undefined future, for now we just have min_const_generics which is basically the fundamental integral types as constants in generics.

avgcorrection 4y ago

Sure. It seems like a pattern for languages that try to be more pragmatic. Instead of a Big Idea, turtles-upon-turtles approach that would take years to finalize in a form that doesn’t invalidate everything that came before it, one goes for an initially good enough approach and then release more and more features which to the insider might seem very holistic but to an outsider (like me) just sound like Static Runtime-Bounded Polyhydral Lambda Cube Type Capabilities and Associates.

aidanhs 4y ago

I recently refactored some traits that had a lot of repetitive noise in the generic type parameters (which end up being reflected in function signatures etc). I went about this without really being overly aware of GATs and their status, but the code that I naturally ended up with required enabling them. So from my point of view, I didn't really need to understand what GATs were bringing - it's a lifting of restrictions that would have previously felt arbitrary.

kibwen 4y ago

Conceptually it's "just" the ability to take one existing concept, generics, and apply it to another existing concept, associated types. Under the hood there's a lot going on to make that work with the type system, and there's some advanced things that this now enables, but as far as a beginner is concerned this is less "a new feature" than "lifting a restriction on an existing feature". By analogy, imagine a version of C where you can't use a struct as a member of a union. Then, a new version of C comes along letting you use structs in unions. We could call that a new feature, "struct-in-unions"... or we could just call it lifting a restriction on an existing feature. It's entirely natural to want to use structs with unions, and it's probably what a learner of the language intuitively expects should be possible. Likewise, a learner of Rust probably expects that any type can be used as an associated type, and before today that wasn't true, and after today that is true.

smilekzs 4y ago
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.
capableweb 4y ago
> 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"
- necubi 4y ago
  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.

epilys 4y ago

Well you don't have to use it just because it is added, but it will allow library writers to provide more ergonomic interfaces. This specific type system feature allows for stuff that weren't possible before but make sense and you'd expect to be valid code that compiles: the most common example is the lending iterator. Have a struct that owns a vector of data. Can you implement an iterator that can return a reference of each item when you call next()? Not without GATs, because each time you return from next() you're creating a new lifetime that doesn't exist in your trait definition. That's why current standard library iterators are basically structs that own a reference to what you iterate. See the GAT RFC which explains this concept much better than I can: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md https://github.com/rust-lang/rfcs/blob/master/text/1598-gene... TL;DR it's not a "new" feature per se but something that could have been present from the beginning without making the language different.

deleted 4y ago

[deleted]

api 4y ago

This isn't so much the introduction of a new concept or abstraction as the removal of what feels like an artificial limitation. You should be able to use a generic in a trait in a type defined in that trait, and when you can't it feels broken.