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

71–80 of 176 posts

Re: Monads and GATs in Nightly Rust

#71

Post by dathinab »

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

They don't have the exact same expressive power.

If you have a `trait A { type B; ... }` then for any type T you can implement one specific A with one specific B.

But if you have `trait A { ... }` then you can have a different implementation of A for every disjoint type B.

Then if you have `trait A { type C; ... }` you can have one specific C for every possible disjoint B.

So with associated types you can express additional constraints/semantics which you can not express with only "classic" generics.

Furthermore the compiler can rely on this constraints for e.g. type inference.

Re: Monads and GATs in Nightly Rust

#72

Post by ivanbakel »

Thiez wrote: post #57
ivanbakel wrote: post #25

Earlier quoted context omitted.

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…

Back in the days before associated types you could implement `Deref` multiple times for the same type. That was fun.

You can still do similarly hellish impls with `Index` - especially if you mix `Deref` into it. IIRC, the compiler will perform automatic recursive derefs when you try to use the indexing operator `[]`, until it finds a deref target which matches the index you're using. I doubt anything relies on that search behaviour outside of the compiler code itself.

I imagine abuse of specialisation could also increase the confusion, if you were so inclined.

Re: Monads and GATs in Nightly Rust

#73

Post by valenterry »

jokethrowaway wrote: post #30
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.

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

True

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

Not really though. Unless similar developer experience means you suffer like hell and still have to deal with runtime errors and worse performance.

Re: Monads and GATs in Nightly Rust

#74

Post by zaptheimpaler »

valenterry wrote: post #69
zaptheimpaler wrote: post #66

I saw Scala taken over and destroyed by the FP fanatics who want to turn every language into Haskell. I hope they don't do the same to Rust. Just use Haskell and leave the rest of us alone! It sounds silly but its true.. as you increase the complexity of the language, the hardcore users making the libraries adopt those features, which means users have to adopt those features as well. Pretty soon everyone is talking a…

It's pretty flourishing though if you look at the graphs.

I agree its doing great for now. This new addition just feels like a minor cause for concern though. Time will tell how things play out and which faction wins - those who actually build shit or architecture astronauts making towers of monads.

Re: Monads and GATs in Nightly Rust

#75

Post by dathinab »

Thaxll wrote: post #56
bluGill wrote: post #44

Earlier quoted context omitted.

Yes, more features make a better language. I need those features to abstract my software so I can wrap my mind around all 15 million lines of code I have to deal with (that is both too many for one human to understand, and yet I know many will respond that they work on much larger system!). We don't need new languages without features: it has already been proven that you only need exactly one feature in your programm…

"Yes, more features make a better language" At the pace of what Rust is adding feature, it's the next C++ in the next 5-10years.

The main difference is that in rust if you don't use a feature you in general don't have to know about it , many features are intuitive(-ish) and due to rust safety guarantees you can often just "try" if your intuitive understanding works and as long as it doesn't involve unsafe you normally don't have any bad surprises.

In C++ this is less so the case. It's quite simple to write code which seems ok, currently happens to execute expected behaviour but triggers undefined behaviour.

Re: Monads and GATs in Nightly Rust

#76

Post by whateveracct »

tener wrote: post #68
amelius wrote: post #65

Earlier quoted context omitted.

You will probably not see much Haskell style functional programming in Rust simply because there is no garbage collector in Rust, and Haskell depends on one very much.

It isn't immediately obvious that FP requires GC. Sure, the languages we have right now make use of GC, but it is far from certain that there is no way for a subset of FP features to exist in a language without GC.

The F in FP definitely hugely benefits from GC. Closures in Rust don't compare to Haskell.

Combine that with GHC's optimizer and it's no contest which language to choose if both ergonomics and performance of code written largely as lambdas is your priority.

Re: Monads and GATs in Nightly Rust

#77

Post by dathinab »

steveklabnik wrote: post #43
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?

Lack of monads is not a super huge pain point, but GATs do solve a big pain point: they're needed in order to have async methods. To be clear here, you don’t need to write any of this stuff in the blog post to write an async method, but the desugaring of an async method involves GATs, so the language has to have them.

GAT limited to lifetimes would already be good enough for me.

What I need is something similar to:

trait AsyncCallback {

  type Input: 'a;

  type Output: Future + 'a

  fn call(self, Self::Input) -> Self::Output;
}

Re: Monads and GATs in Nightly Rust

#78

Post by steveklabnik »

dathinab wrote: post #77
steveklabnik wrote: post #43

Earlier quoted context omitted.

Lack of monads is not a super huge pain point, but GATs do solve a big pain point: they're needed in order to have async methods. To be clear here, you don’t need to write any of this stuff in the blog post to write an async method, but the desugaring of an async method involves GATs, so the language has to have them.

GAT limited to lifetimes would already be good enough for me. What I need is something similar to: trait AsyncCallback { type Input : 'a; type Output : Future + 'a fn call (self, Self::Input ) -> Self::Output ; }

Lifetimes are already generics, so it is harder to add "lifetime only GATs" than it is GATs, in my understanding.

Re: Monads and GATs in Nightly Rust

#79

Post by lambda_obrien »

whateveracct wrote: post #76
tener wrote: post #68

Earlier quoted context omitted.

It isn't immediately obvious that FP requires GC. Sure, the languages we have right now make use of GC, but it is far from certain that there is no way for a subset of FP features to exist in a language without GC.

The F in FP definitely hugely benefits from GC. Closures in Rust don't compare to Haskell. Combine that with GHC's optimizer and it's no contest which language to choose if both ergonomics and performance of code written largely as lambdas is your priority.

With linear types you could get rid of the GC, probably.

Re: Monads and GATs in Nightly Rust

#80

Post by ivanbakel »

zaptheimpaler wrote: post #74
valenterry wrote: post #69

Earlier quoted context omitted.

It's pretty flourishing though if you look at the graphs.

I agree its doing great for now. This new addition just feels like a minor cause for concern though. Time will tell how things play out and which faction wins - those who actually build shit or architecture astronauts making towers of monads.

Your claims are at odds with each other. If the people who are passionate about a language are the ones who pursue its advanced features (and therefore somehow force them on the rest of the world), who then is left to "actually build shit"? Why, if simple functionality is such a strong requirement of productivity, aren't those who stick to simple features productive enough to maintain an ecosystem without the Architecture Astronauts building all the infrastructure?

It doesn't track that it's possible to simultaneously ruin a language by sabotaging all of its major libraries with novel features if writing code using novel features is actually incredibly difficult. It certainly doesn't track that, once you have somehow sabotaged a language's major libraries, that nobody bothers to "fix" them by introducing a new, simpler version.

Post reply on HN