3 ms·

> 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. High-minded

> 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. High-minded or snobbish or whatever other deragotory words that one wants to use: the benefit of something like HKT is that it encompasses one thing that Rust now currently ends up catching up to by implementing dozens of “X with Y” (“generic const in associated lifetimes positions”… to use a made up feature) that are just about lifting limitations, and that end up sounding “complicated” and “featureful” (kitchen sink accusations) to anyone who isn’t knee deep in building an async runtime library or whatever. Meanwhile a Haskell programmer might go years and never think about HKT as a feature. It’s just “kinds” without artificial-looking limitations.

withoutboats2 4y ago
Before writing a completely asinine comment like this, you might consider that I, having been paid real American dollars to design this language, might know more than you about the relationship between GATs and HKTs and the design of Rust as a whole. Your comment evinces a total ignorance of the type theoretical issues that actually informed our decision on this issue. Fortunately, Niko Matsakis blogged about our design discussions at the time. You can read more here and in the linked predecessor posts (at the time we were calling GATs "ATCs") https://smallcultfollowing.com/babysteps/blog/2016/11/04/associated-type-constructors-part-3-what-higher-kinded-types-might-look-like/ https://smallcultfollowing.com/babysteps/blog/2016/11/04/ass...
- avgcorrection 4y ago
  Yes, your attitude (shall we say) was apparent from the start.
Tainnor 4y ago
> Meanwhile a Haskell programmer might go years and never think about HKT as a feature. It’s just “kinds” without artificial-looking limitations. And yet, at the same time, Haskell has many, many extensions to enable certain features that would come for free in a dependently typed language, for example. I find Idris's type system easier to fit in my head, for example. There's always a next level of generality in which previously complicated concepts can be expressed more simply, but there are also sometimes reasons not to want to reach that level of abstraction, for various reasons. (Although in principle, I agree. I don't find the concept of HKTs particularly complicated per se.)
- avgcorrection 4y ago
  > And yet, at the same time, Haskell has many, many extensions to enable certain features that would come for free in a dependently typed language, for example. For sure. In Rust’s case though it seemed that insiders were saying that HKT was more than the language needed, while now they keep running into limitations which necessitates patching up feature limitations. And patching up the language itself, not compiler extensions (maybe rustc is the only compiler that people use (?) but the updates are really to the language (in the abstract) itself). But in any case, I’ve been told that I’m just talking out of my behind ;)

withoutboats2 4y ago

Before writing a completely asinine comment like this, you might consider that I, having been paid real American dollars to design this language, might know more than you about the relationship between GATs and HKTs and the design of Rust as a whole. Your comment evinces a total ignorance of the type theoretical issues that actually informed our decision on this issue. Fortunately, Niko Matsakis blogged about our design discussions at the time. You can read more here and in the linked predecessor posts (at the time we were calling GATs "ATCs") https://smallcultfollowing.com/babysteps/blog/2016/11/04/associated-type-constructors-part-3-what-higher-kinded-types-might-look-like/ https://smallcultfollowing.com/babysteps/blog/2016/11/04/ass...

avgcorrection 4y ago
Yes, your attitude (shall we say) was apparent from the start.

Tainnor 4y ago

> Meanwhile a Haskell programmer might go years and never think about HKT as a feature. It’s just “kinds” without artificial-looking limitations. And yet, at the same time, Haskell has many, many extensions to enable certain features that would come for free in a dependently typed language, for example. I find Idris's type system easier to fit in my head, for example. There's always a next level of generality in which previously complicated concepts can be expressed more simply, but there are also sometimes reasons not to want to reach that level of abstraction, for various reasons. (Although in principle, I agree. I don't find the concept of HKTs particularly complicated per se.)

avgcorrection 4y ago
> And yet, at the same time, Haskell has many, many extensions to enable certain features that would come for free in a dependently typed language, for example. For sure. In Rust’s case though it seemed that insiders were saying that HKT was more than the language needed, while now they keep running into limitations which necessitates patching up feature limitations. And patching up the language itself, not compiler extensions (maybe rustc is the only compiler that people use (?) but the updates are really to the language (in the abstract) itself). But in any case, I’ve been told that I’m just talking out of my behind ;)