Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monads and GATs in Nightly Rust

fpcomplete.com

Post reply on HN
Print view View original

31–40 of 176 posts

Re: Monads and GATs in Nightly Rust

#31

Post by contravariant »

olodus wrote: post #28

I like that the article starts with describing Functor as "something almost every developer knows about". That might be a bit of a stretch. I would say almost all developers has interacted with what could be called a functor, but knowing the concept is something different. In certain areas it is starting to get well known though.

I agree, though I think developers should be aware of type-parameters, and should be aware that if A is a subtype of B then List[A] should be considered a subtype of List[B] (which turns List into a functor on types by inclusion). In fact I reckon almost every developer is aware of these things but perhaps doesn't realise the underlying pattern.

Re: Monads and GATs in Nightly Rust

#32

Post by CryZe »

Philip-J-Fry wrote: post #6

It seems that Rust just keeps getting more and more features. Do people generally feel like the more features the better the language? I'm personally of the opinion that less is more. Is this a pain point at the moment for Rust devs? Do you feel like the code you write is the same code 99% of other Rust developers would write to solve the same problem? Or is there actually a really large variety of styles?

I'd argue that for the most part Rust is not really gaining more features. Instead rough edges are being polished. GATs for example sound like a fancy feature, but in reality, it just allows you to make your associated types generic, just like everywhere else where you can define a type. A Rust beginner would expect this to work by default, and actively has to learn that it currently does not work. By enabling GATs new learners will have to learn less, not more. Most other upcoming features have been planned for a long time, such as const generics and allowing more things in const fn (which yet again, you currently have to learn the limitations, which are constantly being lifted). I'd expect the development of new features to rapidly slow down once those are finished. In fact they are already struggling to justify a Rust 2021 edition, as there's not a whole lot of features that would even require an edition.

Re: Monads and GATs in Nightly Rust

#33

Post by Twisol »

contravariant wrote: post #31
olodus wrote: post #28

I like that the article starts with describing Functor as "something almost every developer knows about". That might be a bit of a stretch. I would say almost all developers has interacted with what could be called a functor, but knowing the concept is something different. In certain areas it is starting to get well known though.

I agree, though I think developers should be aware of type-parameters, and should be aware that if A is a subtype of B then List[A] should be considered a subtype of List[B] (which turns List into a functor on types by inclusion). In fact I reckon almost every developer is aware of these things but perhaps doesn't realise the underlying pattern.

> if A is a subtype of B then List[A] should be considered a subtype of List[B]

Well, careful -- I'm sure you know this by your name, but the naive treatment of Java's native array type as A[] Fundamentally that's because you can both read and write to Java's arrays; if you assume arrays are read-only then A[] <: B[] is indeed sound.

Re: Monads and GATs in Nightly Rust

#34

Post by kzrdude »

As has been noted in other forums, this article does not cover implementing Functor/Monad for the Option type family (for example) faithfully.

What's missing is implementing Functor for `Option` (the "unapplied" option, without a type parameter), in such a way that it is evident in from the trait implementation that if you pass an Option to `fmap`, then you get an Option out (not just any Functor). In other words, that the particular flavour of functor or monad is preserved in these operations.

Proof of concept code for this exists, but Rust doesn't support it in a fluent way, even with the GAT feature.

Re: Monads and GATs in Nightly Rust

#35

Post by WhoCaresLies »

This confirms my concerns.. Rust is becoming a Scala language, too much features.. Rust should have been as simple as C, i wonder if there will be some compiler switchs to ban certain features, and crates that are tagged to work with certain features, so at least things will be easier to deal with

Re: Monads and GATs in Nightly Rust

#36

Post by Twisol »

kzrdude wrote: post #34

As has been noted in other forums, this article does not cover implementing Functor/Monad for the Option type family (for example) faithfully. What's missing is implementing Functor for `Option` (the "unapplied" option, without a type parameter), in such a way that it is evident in from the trait implementation that if you pass an Option to `fmap`, then you get an Option out (not just any Functor). In other words, th…

> What's missing is implementing Functor for `Option` (the "unapplied" option, without a type parameter), in such a way that it is evident in from the trait implementation that if you pass an Option to `fmap`, then you get an Option out (not just any Functor).

I was momentarily confused by this explanation, so allow me to distill the problem.

In the trait declaration for Functor, nothing requires that ` as Functor>::Wrapped == X`. In other words, the implementing type can be different from the return type of `map`. You would want to return `Self` from `map`, but `Self` refers to the fully-reified type, which is to say the implementor has already decided what the type parameter (if any) is, and you as the trait author have no control over it.

You need some way to force the above equality, which is probably what the referenced "proof of concept" does. (I think I found it here: https://github.com/edmundsmith/type-plugs)

(EDIT: I found another proof of concept via the author's bug report. The two approaches seem pretty much the same, and it doesn't look too difficult to understand. https://users.rust-lang.org/t/monads-in-rust-with-gats/50487)

The article does mention this problem explicitly:

>> Interestingly, we have lost the knowledge here that Self::Wrapped is also a Pointed. That's going to be a recurring theme for the next few traits.

Re: Monads and GATs in Nightly Rust

#37

Post by chombier »

The_rationalist wrote: post #16
sfvisser wrote: post #7

Earlier quoted context omitted.

I'm not sure you can only see this in the light of 'more features'. From a more fundamental perspective GATs just lift a restriction. Rust already has generics and Rust already has associated types. Previously you needed to know/remember those features cannot interact for some reason, now they can. To me this is in a sense 'less' and not 'more'. So, a matter of perspective I guess.

But why have associated types in the first place since they have the same expressive power as generics? https://stackoverflow.com/questions/33647337/what-is-the-dif...

Looking at the replies the difference was not entirely clear to me, but the book has a nice explanation https://doc.rust-lang.org/stable/book/ch19-03-advanced-trait...

> "The difference is that when using generics, as in Listing 19-13, we must annotate the types in each implementation; because we can also implement Iterator for Counter or any other type, we could have multiple implementations of Iterator for Counter. In other words, when a trait has a generic parameter, it can be implemented for a type multiple times, changing the concrete types of the generic type parameters each time. When we use the next method on Counter, we would have to provide type annotations to indicate which implementation of Iterator we want to use."

Re: Monads and GATs in Nightly Rust

#38

Post by contravariant »

Twisol wrote: post #33
contravariant wrote: post #31

Earlier quoted context omitted.

I agree, though I think developers should be aware of type-parameters, and should be aware that if A is a subtype of B then List[A] should be considered a subtype of List[B] (which turns List into a functor on types by inclusion). In fact I reckon almost every developer is aware of these things but perhaps doesn't realise the underlying pattern.

> if A is a subtype of B then List[A] should be considered a subtype of List[B] Well, careful -- I'm sure you know this by your name, but the naive treatment of Java's native array type as A[] Fundamentally that's because you can both read and write to Java's arrays; if you assume arrays are read-only then A[] <: B[] is indeed sound.

Yeah I was thinking of the read only kind, you do need to be a bit careful when your objects are mutable ;-)

Re: Monads and GATs in Nightly Rust

#39

Post by nicoburns »

jokethrowaway wrote: post #26
Philip-J-Fry wrote: post #6

It seems that Rust just keeps getting more and more features. Do people generally feel like the more features the better the language? I'm personally of the opinion that less is more. Is this a pain point at the moment for Rust devs? Do you feel like the code you write is the same code 99% of other Rust developers would write to solve the same problem? Or is there actually a really large variety of styles?

I think rust does a good job at keeping things simple in the std. Where I get some analysis paralysis is in getting one library over another one. Eg. I'd love to have a std lib recommended way of doing async and task execution with a thread pool eg. Async-std vs Tokyo Vs Rayon. They're all individually great pieces of software but none of them feel complete and I always reach out for something that is not there. To b…

> They're all individually great pieces of software but none of them feel complete and I always reach out for something that is not there.

I'm not convinced that the libs being in std would help you with this issue. Instead you'd probably have the same incompleteness with a whole bunch of the functionality only available in nightly rust because of the stability contract implied by std.

Picking either tokio or async-std (flip a coin if you can't decide) and using their recommended way doing a given async task isn't really all that different from doing the same with a hypothetical std::async.

Re: Monads and GATs in Nightly Rust

#40

Post by dragonelite »

WhoCaresLies wrote: post #35

This confirms my concerns.. Rust is becoming a Scala language, too much features.. Rust should have been as simple as C, i wonder if there will be some compiler switchs to ban certain features, and crates that are tagged to work with certain features, so at least things will be easier to deal with

You do know you don't have to use everything under the sun. If you want to use a sub set then use the sub set.
Post reply on HN