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

21–30 of 176 posts

Re: Monads and GATs in Nightly Rust

#21

Post by caspper69 »

danappelxx wrote: post #8
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 would say, with the exception of the async split, no. The biggest pain is still the learning/skill curve, it always feels (to me) like there's a language feature I'm not taking advantage of that would make a piece of code more "rusty". Not different in style necessarily, just more elegant.

I can relate to this 100%.

I'm working though a Rust course right now, and while my code works fine (once it compiles), I always see the reference implementations of the code, and it's like 2 lines of filter/map/collect, and voila. Meanwhile, my 8 line frankenfunction looks like the Charlie Brown Christmas tree.

Re: Monads and GATs in Nightly Rust

#22

Post by Twisol »

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

Even in Java, I'm rather sick of passing around types with `` with two honest-to-goodness generic types and two actually-chosen-by-the-implementation generic types. There's no good way in Java to hide those visible wildcards without making a wrapper class that only exposes the meaningful ones.

Associated types make the distinction far clearer. They better capture the qualitative distinction that "you can choose these, I get to choose those".

Also, associated types are inherently "functionally dependent" in the sense of Haskell's multi-parameter type classes. If you have a trait `F` with an associated type Z, you know that given X and Y, Z is fixed. Without associated types, `F` could have multiple legal implementations for the same X, Y and different Z.

This is extremely meaningful in languages like Haskell and Rust which implicitly thread around the trait methods. Typeclasses in Haskell can be imagined as describing concrete dictionaries of functions over the given types. Languages like Java (manually) and Scala (automatically, using "implicit") reify these typeclasses as dictionaries that are threaded through functions as extra parameters. You can often define multiple implementations of a given trait for the same types, and you get to choose which implementation to pass along.

Rust and Haskell assert that traits have a single implementation for a given batch of types, and they automatically look up the correct implementation given the types you've specified. These "functional dependencies" mean that, in my example of `F` with associated type Z, it's sufficient to state what X and Y are to find the right implementation of F -- Z doesn't contribute to the lookup. If you don't have associated types, you could have multiple implementations that simply vary on Z, so you have to tell the compiler explicitly which one to use (by stating what Z is).

Re: Monads and GATs in Nightly Rust

#23

Post by dragonelite »

Milner08 wrote: post #15
dragonelite wrote: post #14

How does one get familiar with these kind meta programming concepts. Is there some kind bible or series one can read to get up to speed?

Im a Scala fan, so all these will be focused around Scala, but they will teach you about Monad and Category Theory. I would start with http://learnyouahaskell.com - Its Haskell based but it covers them pretty well. Otherwise I use https://typelevel.org/cats/ for Scala daily and they have an _ok_ guide. But the best guide I've found for it was http://eed3si9n.com/herding-cats/

LearnYouAHaskell bought the book last year but because of lack of time didn't worked through it. I should dust the book off in januari and give a read.

Re: Monads and GATs in Nightly Rust

#24

Post by monoideism »

dragonelite wrote: post #14

How does one get familiar with these kind meta programming concepts. Is there some kind bible or series one can read to get up to speed?

Many Haskell and functional Scala books will give you a good understanding of type-driven development, but I'd recommend "Functional Scala" by Chisano/Bjarnson (and do the exercises).

Alternately, "Learn You a Haskell" will provide a decent base.

Either of these will give you the base needed to explore higher-level concepts that can easily be used in Haskell, Scala, Purescript, OCaml, a few statically-typed functional languages, and to some extent, Rust.

Re: Monads and GATs in Nightly Rust

#25

Post by ivanbakel »

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

Because they don't. Your link even has an answer that highlights one way which they differ in expressivity - namely, that associated types don't appear in the instance head, so they can produce orphan instances where generics would not.

Consider the example of Rust's Iterator trait[0]. It has an associated type for the iteration item. It could have a generic type argument instead, but the two implementations would be different:

  1. The associated type is a direct consequence of the instance head. That means that, for the type that Iterator is being implemented on, the associated type is known entirely from that type. If you have an iterable value, you know it only produces one kind of iterator item.
  2. As a result, the associated-type version can only be implemented at most once. The generic version would be implementable any number of times, for any number of choices of type argument - and as a result, you would have to specify that you are iterating over an iterator with a particular choice of iterator item type, every time you iterate.

 [0]: https://doc.rust-lang.org/std/iter/trait.Iterator.html

Re: Monads and GATs in Nightly Rust

#26

Post by jokethrowaway »

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 be fair I don't think this is rust specific, I think this is just the bane of OSS solutions with unpaid maintainers.

Sure, I could contribute something or fork them but it takes time.

I'd prefer to just buy in into a solution, pay a monthly fee and know that I'll get a full featured solution with a well paid maintainer.

Re: Monads and GATs in Nightly Rust

#27

Post by cerebellum42 »

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 mean, I've run into situations where GATs would have been a good solution before and had to find a clumsier workaround using boxing or other solutions until now.

So I don't really know what to say to your initial question, except "this feature is useful", and that the question (and especially your answer to it) may be a bit overly reductionist.

Re: Monads and GATs in Nightly Rust

#28

Post by olodus »

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.

Re: Monads and GATs in Nightly Rust

#29

Post by karavelov »

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

Type parameters are decided by the use of the type. The associated types are decided by the implementation of the type. Type params are input, associate type are output.

Re: Monads and GATs in Nightly Rust

#30

Post by jokethrowaway »

bsaul wrote: post #2

Side question : Is there any example of a language that has successfully added HKT after it was released and became popular ?

I don't think they make or break a language for 99% of the developers.

You can get 90% there without HKT and a similar developer experience.

Current rust has some implementations which are simil-functors and simil-monads.

This is just polishing the language by lifting a restriction.

Post reply on HN