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

81–90 of 176 posts

Re: Monads and GATs in Nightly Rust

#81

Post by alkonaut »

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.

"Using" a programming language is 99% reading and understanding code and 1% writing code. I only control the 1% i write and not the 99% I read. You can't know everything but you need to know enough to understand most of the code you read. If a feature becomes popular among others, then you need to understand it, even if you never use it yourself.

Re: Monads and GATs in Nightly Rust

#82

Post by cogman10 »

steveklabnik wrote: post #58
Thaxll wrote: post #56

Earlier quoted context omitted.

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

Came here to say this. The last major language changing feature was async/await.

Everything else seems to be on the order of small polish to the language (trailing commas), standard library expansion, and in some cases language restrictions to make rust fit better with embedded systems.

In many ways, Java is seeing more major changes than rust is.

Re: Monads and GATs in Nightly Rust

#83

Post by zaptheimpaler »

ivanbakel wrote: post #80
zaptheimpaler wrote: post #74

Earlier quoted context omitted.

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

> 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"?

Some people are passionate about the language itself, and programming language theory in general. Others are passionate about solving whatever particular problem their project solves.

A simple thought experiment - think about the most widely used libraries and tools across the whole developer ecosystem. How many are built in Haskell? I count maybe one, Pandoc. How many are built in terrible code bases and languages but chug along anyways? I count thousands. How many wildly successful companies have pristine code bases and how many have trash fire code bases that chug along anyways?

Re: Monads and GATs in Nightly Rust

#84

Post by alvarelle »

dathinab wrote: post #67
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 rounde…

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

Is that not the same in C++ and in most languages?

... until someone else in your team uses it in your code base. And then you need to know about it in Rust as well.

Re: Monads and GATs in Nightly Rust

#85

Post by steveklabnik »

lambda_obrien wrote: post #79
whateveracct wrote: post #76

Earlier quoted context omitted.

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.

The core issue here isn't exactly GC, though it is related. The issue is that abstraction is about hiding things, and Rust's type machinery is about exposing things. In Haskell, you have lambdas, and you have types of all of the same size data, because it's all on the heap. In Rust, each closure is a distinct type, plus the three different types of closures, plus types of different sizes...

It's not so much the GC, as it is "in a GC'd language, everything is on the heap and a lot of information (from Rust's perspective) is erased." You may be able to get rid of GC in some sense, but you'd end up with something halfway to Rust, not the whole way.

Re: Monads and GATs in Nightly Rust

#86

Post by Philip-J-Fry »

dathinab wrote: post #67
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 rounde…

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

I don't think that's a particularly good argument, since it's true for all languages. Even if you don't use a feature, you will use and read code written by others all the time and understanding that code can be pretty important.

Re: Monads and GATs in Nightly Rust

#87

Post by NationalPark »

mabbo wrote: post #49
appleflaxen wrote: post #45

GAT = Generic Associated Type

Thank you. I spent 10 minutes fruitlessly googling to no avail. A simple rule: if you're writing for a more general audience, always spell out your initializations the first time you say them.

In their defense, this looks like content marketing for people who buy functional programming consultancy services. So they're not really writing for a general audience. I tend to agree on initializations though. I think a lot of times people use them as a signal of their membership of the technical "in group", to establish a place in a social hierarchy. That's not good communication.

Re: Monads and GATs in Nightly Rust

#88

Post by cle »

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.

It's never this simple. You have to decide what subset to use, understand how that subset could interact with the avoided language features, have a strong team culture that can agree on the subset and have the discipline to commit, understand how new language features affect that commitment, etc. In addition to needing to read and interact with other libraries that probably use it anyway.

The team aspect alone is a deal breaker for me--when you have a technology that attracts people who are intrinsically interested in the technology, good luck trying to get them to avoid certain parts of it. That's a losing battle.

Re: Monads and GATs in Nightly Rust

#89

Post by dathinab »

steveklabnik wrote: post #78
dathinab wrote: post #77

Earlier quoted context omitted.

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.

Lifetimes do not influence code generation (besides potential specialization on 'static, which I'm not sure if it's a thing).

But besides that the amount work is indeed very close by each other. Which is why there is currently no plan to first have lifetime only GATs stable as far as I know.

Re: Monads and GATs in Nightly Rust

#90

Post by steveklabnik »

dathinab wrote: post #89
steveklabnik wrote: post #78

Earlier quoted context omitted.

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

Lifetimes do not influence code generation (besides potential specialization on 'static, which I'm not sure if it's a thing). But besides that the amount work is indeed very close by each other. Which is why there is currently no plan to first have lifetime only GATs stable as far as I know.

You're not wrong that they don't influence codegen, but I don't know why you're bringing that up. I don't see the connection.

You cannot specialize on lifetimes, it is not sound.

Post reply on HN