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

41–50 of 176 posts

Re: Monads and GATs in Nightly Rust

#41

Post by Nullabillity »

Twisol wrote: post #36
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>::…

Adding that restriction would make it impossible to implement Functor for lazy collections (for example, `::map()` returns a `Map` where F is usually some unmentionable closure type).

Re: Monads and GATs in Nightly Rust

#42

Post by Twisol »

Nullabillity wrote: post #41
Twisol wrote: post #36

Earlier quoted context omitted.

> 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>::…

Adding that restriction would make it impossible to implement Functor for lazy collections (for example, ` ::map()` returns a `Map ` where F is usually some unmentionable closure type).

The lazy collections are an interesting case, because as you build up a stack of transformations, the type itself grows in ways beyond simple A -> B type substitutions. That's a really good example of a case better served by GATs than HKTs -- they're not that kind of Functor to begin with.

To be explicit, a lazy collection type in Rust is more than just `List` -- it needs to carry an additional type describing the set of transformations being applied. You'd really have something closer to `List`, and as you apply transformations, F grows while T is substituted.

(You could avoid this by storing a trait object for your transformation stack instead of parametrizing over F, but half the point is that you can often flatten the whole stack down into highly-efficient generated code, and abstracting over the precise F hinders that flattenability.)

Re: Monads and GATs in Nightly Rust

#43

Post by steveklabnik »

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.

Re: Monads and GATs in Nightly Rust

#44

Post by bluGill »

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?

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 programming language to write any program possible. Look up single instruction languages for proof that it is possible and such single features languages exist.

What we need are languages with many features that are easy to use to create complex programs that are still easy to understand.

C++ is a very powerful language, but the various features do not fit together well and so even experts tend not to know how to use everything and so the whole suffers. Most languages since then have attempted to take the [all or some subset of] the features of C++ to make a better language. (when any other language comes up with a good feature C++ copies it so is often getting credit for ideas that actually come from elsewhere - possibly better)

When someone is saying they want less features they mean one of the following: "I don't know how to use some feature and I've gotten this far so it must be useless". "That feature is useless for my domain so I don't want to pay the compromises required to allow it". "That feature is too often abused to write bad code and so it isn't worth having". "That features is neat but it makes the whole language ugly and so it isn't worth having". There is probably something I missed but you get the idea. Some of the above are logical fallacies, the others are compromises that apply to a particular problem. None of them are universal truths for problems.

Re: Monads and GATs in Nightly Rust

#46

Post by dboreham »

dragonelite wrote: post #40
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.

Without tooling (a kind of lint rule I suppose) to prohibit the use of advanced features, this is difficult to achieve in multi-developer projects.

Re: Monads and GATs in Nightly Rust

#47

Post by Lermex »

hurril wrote: post #4
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 ?

Would you consider Scala? It wasn't wildly popular before 2.8 (which is when HKTs were added) but not unpopular either.

I was surprised that to learn that HKT weren't part of Scala from the beginning and had to look that up. You're a bit wrong about when that happened: it was Scala 2.5 in 2007, not 2.8 which was released in 2010.

Re: Monads and GATs in Nightly Rust

#48

Post by swsieber »

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?

The reason Rust has so many features is to manage the complexity lifetimes introduce in a safe, zero-cost way. The big recent additions and outstanding work is trying to fill gaps there.

* async - you can write futures without async, but async lets you do more because of how it resolves lifetime issues you'd normally get when using combinators. The other route without async would be to manually write unsafe state machines. Yuck.

* GATs - these are required to be able to have native support for async methods in traits (interfaces) without needing to box the return value (ie. have statically dispatched ... not sure what the term is, but it lets it be online too, IIRC; I might be wrong about the performance ipact, but ergonomic pain is real)

* const generics - this gives better support for stuff like arrays, since really what it's doing is stuff like supporting array length as a generic type parameter instead of a special case.

Re: Monads and GATs in Nightly Rust

#50

Post by swsieber »

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…

I would lament if everything were in the std at this point. There will be another wave of change after GATs stabilize.

That said, there are some traits being standardized and moving to the std, which should be great for interop.

Post reply on HN