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

161–170 of 176 posts

Re: Monads and GATs in Nightly Rust

#161

Post by joel_ms »

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 personally of the opinion that less is more.

I used to have this position as well, writing everything in either assembly or pure lambda calculus, to avoid all these pesky higher level language features.

Re: Monads and GATs in Nightly Rust

#162

Post by pdimitar »

akiselev wrote: post #117
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…

I've never really grasped FP and I seem to be in an eternal state of confusion about monads but I'm excited about GATs in Rust. They'll allow for traits that hide implementation details like `trait Foo { type Bar = T | Box | Arc }` without dynamic dispatch or ugly hacks.

I work with FP languages for 4 years now and I still have no clue what a Monad or GAT is.

Using FP without reaching for the most advanced techniques (which Haskell seems to employ) is a very valid and viable choice.

Re: Monads and GATs in Nightly Rust

#163

Post by chridou »

ebruchez wrote: post #151
chridou wrote: post #138

Earlier quoted context omitted.

> I suspect that the above reflects a very personal experience rather than something general. Isn't the FP community in the Scala world at war?

> Isn't the FP community in the Scala world at war? I have heard that there have been one or two difficult individuals in certain segments of the FP community, especially 5-10 years ago. I understand that this caused the Scalaz/Cats split. But I have never really needed to care about it and it seems to me that this is history. I could be wrong but it's my personal experience.

Thank you for sharing your experience. Back then when I used Scala this was really turning me off Scala. Good that it all settled and that the Scala community can focus on the more important tasks again.

Re: Monads and GATs in Nightly Rust

#164

Post by tome »

pdimitar wrote: post #162
akiselev wrote: post #117

Earlier quoted context omitted.

I've never really grasped FP and I seem to be in an eternal state of confusion about monads but I'm excited about GATs in Rust. They'll allow for traits that hide implementation details like `trait Foo { type Bar = T | Box | Arc }` without dynamic dispatch or ugly hacks.

I work with FP languages for 4 years now and I still have no clue what a Monad or GAT is. Using FP without reaching for the most advanced techniques (which Haskell seems to employ) is a very valid and viable choice.

I'm not sure if you meant to imply otherwise, but using Haskell without reaching for the most advanced techniques is also a very valid and viable choice.

Re: Monads and GATs in Nightly Rust

#165

Post by pdimitar »

tome wrote: post #164
pdimitar wrote: post #162

Earlier quoted context omitted.

I work with FP languages for 4 years now and I still have no clue what a Monad or GAT is. Using FP without reaching for the most advanced techniques (which Haskell seems to employ) is a very valid and viable choice.

I'm not sure if you meant to imply otherwise, but using Haskell without reaching for the most advanced techniques is also a very valid and viable choice.

Definitely, but I'd imagine this is being frowned upon because the realistic (and non-fanatic) folks who use Haskell, use it mostly for these advanced features, I'd imagine. Could be wrong.

Re: Monads and GATs in Nightly Rust

#166

Post by tome »

pdimitar wrote: post #165
tome wrote: post #164

Earlier quoted context omitted.

I'm not sure if you meant to imply otherwise, but using Haskell without reaching for the most advanced techniques is also a very valid and viable choice.

Definitely, but I'd imagine this is being frowned upon because the realistic (and non-fanatic) folks who use Haskell, use it mostly for these advanced features, I'd imagine. Could be wrong.

There are quite a number of realistic folks who want to use Haskell because of the simplicity of its basic feature set. See, for example

* https://www.simplehaskell.org/

* https://www.snoyman.com/blog/2019/11/boring-haskell-manifest...

Re: Monads and GATs in Nightly Rust

#167

Post by tome »

Twisol wrote: post #129
zelly wrote: post #106

Earlier quoted context omitted.

> Lambda calculus is a BFD in the subfield of programming languages This is a good example of abusing the vocabulary of mathematics as is common in the FP world. A programming language is not an object in abstract algebra. You can't add, subtract, or factorize a programming language. It's just software.

"BFD" here means "big f#$%ing deal", not "b??? factorization domain".

"Bounded Factorization Domain" apparently

https://en.wikipedia.org/wiki/Atomic_domain#Special_cases

This is a pretty hilarious misinterpretation

> "Lambda calculus is a bounded factorization domain in the subfield of programming languages. What's the problem?"

Re: Monads and GATs in Nightly Rust

#168

Post by zozbot234 »

Animats wrote: post #122
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…

I kind of get that feeling, too. Rust uses "traits" to do both generic-like things and inheritance-like things. It's not clear this was a win. The result seems to be a system which does both badly. Rust generics are very restrictive. They're not at all like C++ generics. It's not enough that every operation on a type needed by a generic be implemented. The type has to be part of a single trait that provides for all t…

> This has no safety benefit, since generics are resolved at compile time and all safety tests can be made after generic expansion.

Rust has macros and procedural macros for the "check after generic expansion" use case. It's a good thing that this is separate from generics; it side-steps a whole lot of incidental complexity that's seen in C++.

Re: Monads and GATs in Nightly Rust

#169

Post by vips7L »

Animats wrote: post #122
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…

I kind of get that feeling, too. Rust uses "traits" to do both generic-like things and inheritance-like things. It's not clear this was a win. The result seems to be a system which does both badly. Rust generics are very restrictive. They're not at all like C++ generics. It's not enough that every operation on a type needed by a generic be implemented. The type has to be part of a single trait that provides for all t…

The thing I found confusing with traits and their generic system was the choice to include "associative types" for out types instead of also defining them in a generic bound:

    trait Iterator {
        type Out;

        fn next() -> Option;
    }
vs

    trait Iterator {
        fn next() -> Option;
    }
Multiple ways to do something has made it harder to understand.

Re: Monads and GATs in Nightly Rust

#170

Post by chridou »

tasuki wrote: post #148
chridou wrote: post #134

Earlier quoted context omitted.

> Option, Result, and Future are all both Functors (map) and Monads (and_then). No. They are Option and Result and Future. > You've probably used them without even knowing, because we didn't give it some weird, unlearnable category theory name. No. I have not used them without even knowing. I have used Option, Result and Future. I do not need some meta-universe which just makes easy things more complicated by stating…

It could be argued that understanding the commonality of certain aspects of Option, Result, and Future results in a simpler model rather than a more complicated one. Don't you find it intriguing and interesting that these seemingly different types have these commonalities?

Well, you somehow got me. When I mentioned the "everything F[_]ed" in my top post I thought I'd made it clear that I knew the commonalities.

And I have to admit that I find these commonalities very fascinating. I can still remember how I enjoyed applicatives and the like when I started with scalaz back then. Whether the model becomes simpler? I do not really know. I just found out for myself that I do not need this knowledge at work and that it didn't really help me to solve my daily problems. This is actually what drove me to Rust which in my perception is a nice practical "in between" (I know it also is no silver bullet).

Post reply on HN