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

51–60 of 176 posts

Re: Monads and GATs in Nightly Rust

#51

Post by swsieber »

dboreham wrote: post #46
dragonelite wrote: post #40

Earlier quoted context omitted.

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.

You can write custom pints if you're willing to build a custom toolchain (shouldn't be too terrible to rebuild it once a release)

That said, GATs fix a real pain point not actually shown in the article. And that's for impl return types in trait methods. You can have return impl types in normal functions, and even associated methods, just not in trait methods. I think the term for this is existential types. And they occur a lot with async. So async in traits is a real pain point this feature fixes.

Re: Monads and GATs in Nightly Rust

#52

Post by jcora »

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/

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

Re: Monads and GATs in Nightly Rust

#54

Post by f154hfds »

swsieber wrote: post #50
jokethrowaway wrote: post #26

Earlier quoted context omitted.

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.

Is there any work on creating feature-based sub-standard libraries that are aggregations of popular (and robust) crates but tying all of their versions together?

For example, I'd like to put in my Cargo.toml:

sstd = { version = "1.0", features = ["clap", "serde", "rand"] }

Where the sstd crate essentially has a whole mess of crates bundled together ensuring only one version is used for each individual dependency?

Perhaps this is a question best asked elsewhere - your comment just brought it once again to my mind.

Re: Monads and GATs in Nightly Rust

#55

Post by dralley »

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

This is not an added feature, it is a removed restriction.

Re: Monads and GATs in Nightly Rust

#56

Post by Thaxll »

bluGill wrote: post #44
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 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.

Re: Monads and GATs in Nightly Rust

#57

Post by Thiez »

ivanbakel wrote: post #25
The_rationalist wrote: post #16

Earlier quoted context omitted.

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…

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

Re: Monads and GATs in Nightly Rust

#58

Post by steveklabnik »

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 pace has already slowed down significantly, and will continue to do so.

The RFC for GATs was opened in 2016. It's still not clear when this is hitting stable Rust yet.

Re: Monads and GATs in Nightly Rust

#59

Post by steveklabnik »

f154hfds wrote: post #54
swsieber wrote: post #50

Earlier quoted context omitted.

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.

Is there any work on creating feature-based sub-standard libraries that are aggregations of popular (and robust) crates but tying all of their versions together? For example, I'd like to put in my Cargo.toml: sstd = { version = "1.0", features = ["clap", "serde", "rand"] } Where the sstd crate essentially has a whole mess of crates bundled together ensuring only one version is used for each individual dependency? Per…

A bunch of people have tried this over the years, they don’t get used, and the maintainers give up.

(Also, this would not assure that only one version is used of a dependency.)

Re: Monads and GATs in Nightly Rust

#60

Post by adamnemecek »

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 not call them features per se but generalizations of existing features.
Post reply on HN