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

61–70 of 176 posts

Re: Monads and GATs in Nightly Rust

#61

Post by stevedonovan »

caspper69 wrote: post #21
danappelxx wrote: post #8

Earlier quoted context omitted.

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.

Remember, using a loop is not a sin! (And I would hate us to get to the point where loops are automatically considered kindergarten code)

Re: Monads and GATs in Nightly Rust

#62

Post by lambda_obrien »

jcora wrote: post #53
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?

Just learn haskell

Seconded, even if you don't later use Haskell, it's a great language to learn if you want to see some interesting programming concepts that are tried and true but not well known. You could also try something like Purescript if you want your code to compile to CommonJS and could try Idris 2 if you also want to try out linear types, which is cool.

Re: Monads and GATs in Nightly Rust

#63

Post by [deleted] »

jcora wrote: post #52
Milner08 wrote: post #15

Earlier quoted context omitted.

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/

Do note this won't teach you actual category theory (and shouldn't)

[deleted]

Re: Monads and GATs in Nightly Rust

#64

Post by chridou »

Even though I see that these language capabilities remove restrictions I hope that HKTs and with them Functors, Monads, etc. will never make it into Rust.

The thing I like most about Rust is that it is still a practical language where I can still solve my problems in different ways and always know what will happen. I also care about the "how" and not only about the "what".

Everything being F[_]ed is what I do not need anymore.

Re: Monads and GATs in Nightly Rust

#65

Post by amelius »

chridou wrote: post #64

Even though I see that these language capabilities remove restrictions I hope that HKTs and with them Functors, Monads, etc. will never make it into Rust. The thing I like most about Rust is that it is still a practical language where I can still solve my problems in different ways and always know what will happen. I also care about the "how" and not only about the "what". Everything being F[_]ed is what I do not nee…

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.

Re: Monads and GATs in Nightly Rust

#66

Post by zaptheimpaler »

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 about monad transformers and HKTs and it takes 4 hours to write something that would take 15 minutes in Python.

Then the wave of FP consultancies and trainings show up so they can bill you $10000s on workshops and conferences to teach your devs monads.

Re: Monads and GATs in Nightly Rust

#67

Post by dathinab »

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?

> Is this a pain point at the moment for Rust devs?

No, in rust as long as you don't use a feature you don't need to know about it.

> Or is there actually a really large variety of styles?

There are official(-ish?) style guidelines. So while there are a variety of styles most code uses mostly the same style.

> I'm personally of the opinion that less is more.

Sure, but you normally want to have a "complete well rounded language".

For this in rust you need GAT, but you don't need HKT, Functors, Monades or similar.

I hope there will never be a Monade trait in std, it would add a lot of mostly hardly useful complexity we really don't need and would mostly be used for IMHO mostly useless over abstraction.

But GAT are really needed. E.g. to properly work with certain async use cases (through for this you only need GAT for lifetimes, not arbitrary type. In my experience GAT limited to lifetimes cover 80+% of the cases where you really really need GAT).

Re: Monads and GATs in Nightly Rust

#68

Post by tener »

amelius wrote: post #65
chridou wrote: post #64

Even though I see that these language capabilities remove restrictions I hope that HKTs and with them Functors, Monads, etc. will never make it into Rust. The thing I like most about Rust is that it is still a practical language where I can still solve my problems in different ways and always know what will happen. I also care about the "how" and not only about the "what". Everything being F[_]ed is what I do not nee…

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.

Re: Monads and GATs in Nightly Rust

#69

Post by valenterry »

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.

Re: Monads and GATs in Nightly Rust

#70

Post by brundolf »

sfvisser wrote: post #7
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'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.

Came here to say this. Adding new syntaxes is something I have mixed feelings about at this stage, but opening up what you can do with existing ones (and, indeed, removing the complexity of remembering special-cases of what's not allowed) is a strict win in my book.
Post reply on HN