Hacker News Reader

Comment by stefan_ | Hacker News Reader

Rust better figure out quick how they can shut down the Haskell & C++ language artisans or it will be their downfall (in favor of something like Zig).

View on HN

GATs are an essential part of Rust's long-term async/await story. It's not language-wankery, this is driven by actual real-world use cases. Rust's own stdlib would have benefited from this in many places had this feature existed years ago.

No, they're not. GATs are used internally in the compiler to implement async methods, but there is absolutely no need for them to be in the language for that (just like generators are used to implement await but are not part of the (stable) language). GATs may or may not be useful, but IMO the actual real-world use cases are pretty weak.

Yes, I've read the stabilization thread and I'm aware of your stance. :P Whether or not it's exposed, the mechanism still needs to exist in the compiler, and enough library authors are clamoring to use it that I think the argument in favor of exposing them is stronger than you're giving it credit for.

You mention generators, but a lot of people are clamoring for those as well, and I fully expect them to be exposed to end-users someday.

My point is that there or may or may not be reasonable justification for adding GATs, reasonable people can disagree on that. But async methods are not part of that justification. Similarly, generators may or may not be good for the language (IMO they would be good to add, if they can be made to work etc.) but they didn't need to be part of the language to add await.

Even if the use cases outside the standard library were weak, given that the work needs to be done anyway for the standard library, why wouldn't you expose them?

To be clear, there are not use cases in the std lib. The use case is as an intermediate representation for the compiler, and that is no motivation for inclusion in the language (in the same way that we don't have vtables or register allocation in the surface syntax)

Being able to have a generic "Mappable" trait seems like a good use case for the standard library. It's something I've wanted in the past, and was disappointed that it didn't exist.

Well, in this realm Haskell

- allows you to write these things with less effort

- is more expressive

I keep an eye on Nim as well. Their syntax for algebraic data types could use some syntactic sugar, but it looks like a powerful and fast language, and the syntax allows you to do away with all the c-style braces, curly braces and semicolons that pesters so many languages and gives me RSI.

More upsides I found: macros on the AST-level and fast compilation; it is a language that deserves more attention.

Well, it's not academic, it solves real problems. More so for library developers than for application developers, but a thriving and great ecosystem of libraries is also good for application developers.

Rust getting more of Haskell's type system features is a good thing. The stronger your type system is, the more mistakes you can discover as compiler errors instead of runtime bugs.

If a typesystem has any impact on the popularity of a language, then i assume rust doesn’t want to copy too much of haskell and needs to know where to stop..

Typescript.

As for Haskell, their motto is "avoid success at any cost" for a reason.

C++ sorta has the equivalent of this feature in the form of nested templates. C++ is kind of popular and rust wants to be a direct replacement.

Next step: template template parameters!

The whole design of GATs is predicated on the notion that Rust doesn't want to go as far as Haskell does here. See boats' comment: https://news.ycombinator.com/item?id=33506540

> The stronger your type system is...

I used to think a stronger and stronger type system was a universal good, then I got experience with code written by architecture astronauts[1] armed with such type systems. Knowing exactly which kinds of things to make impossible at compile time and which not is absolutely an art form. Unfortunately, such type systems seem to result in so many nightmares.

https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

at the end of the day architecture astronauts delegate pipe laying to plumbers, and the plumbers benefit from existing build plans created by architects with all their sophisticated tooling.

The linked article talks about abstraction, and that you could abstract so much that the concrete problem doesn't fit in your abstraction. I.e., your abstraction is broken.

I think that is precisely why OOP started to disappoint (tbh: I also think many people did not understand OOP really well). Haskell pushes you to compose types instead of building inheritance hierarchies. Multiple inheritance turned out to be a bad idea too, so yeah, OOP program do typically not have the best models of the problem domain they were intended to model.

At the other end of the spectrum you see people just give up: everything is a kind of dict or a string, or wo knows, null? Looking at you php, python, javascript..

All the improvements you see in todays OOP languages are ideas stolen from functional languages like Haskell. What Haskell could have done better is be strict instead of lazy by default.

To model the real world and make assumptions explicit, a type system, as Haskell gives you, is so nice.

I agree that you can make types also really abstract like some people indeed do. It's fine if you do that as a library author, but you should offer a facade with some simpler type aliases. If you stick to Haskell98 and possibly enable GADT support you already get an immensely powerful language.

Also, I have not used Haskell for a while, but I heard the compiler error messages have become way more human friendly these days, so that helps with complex types.

As with anything, it all goes well until it doesn't. When you have a single bug (e.g. type error or dynamic error), the guts of whatever is in the box spill out. Case in point: all the implicit template parameters to std:: in C++ these days. The only way to add configuration options in a backwards-compatible way was to add default values for template arguments. That's all fine and good when you can't see them, but as soon as you have a nasty type error, the types that come spilling out in error messages have zillions of default arguments that get printed.

It's almost always the same with inference. I would be very, very wary of doing so much type sophistry that it requires heavy inference to be usable.

An architecture astronauts in Java just use code generation and runtime reflection, which are bigger nightmares than type system features.

Architecture astronauts are going to be a problem regardless of language features.

There will always be more things that someone will want to formally verify that don't exist in the type system. How do you decide what is and isn't worth putting into the type system?

Actually I find C++ concepts much easier to grasp than GATs.

Zig still has to win the love of the giants that ship C++, and increasingly Rust, in their products.

Aren't GATs equivalent to nested template classes? I.e. they are really orthogonal to concepts.

Might be a bit of job deformation, knowing C++ since 1993, and I still need to get myself used to those patterns.

Maybe I should delve again into GADTs in OCaml, before having a second look.

GATs are completely unrelated to GADTs.

From my point of view they look quite similar from language type theory point of view, plus the machinery for affine types.

The only thing similar about them is the acronym:

GATs are generic type aliases which are defined inside traits.

GADTs are generic sum types with extra constraints on which variants may be used with which type arguments.

There is no reasonable way in which they are "quite similar," nor do either of them have anything at all to do with affine types.

Where is the type theory for Rust's GATs for us to educate ourselves?

The RFC might be a good place to start: https://rust-lang.github.io/rfcs/1598-generic_associated_typ...

Thanks.

Reply on news.ycombinator.com