[7kmph]

Sad to see that rust is heading towards a wrong direction. I think everyone in the core team should be stopping what they are doing and write Haskell for a year. This way they can appreciate the benefit of Haskell, and know what to avoid when they implement those ideas in rust, and anyone who trying to make the language and the philosophy more like c++ or java should be banned from the rust community

[steveklabnik]

Several folks on the language team know Haskell well.

[smabie]

I'm sure they do, but even you must admit that Rust has gotten less 'functional' in nature as time goes on. New syntax or ad-hoc abstractions are being created to handle problems that have well known FP solutions. Take this matching on an Option business. The easy solution is to just add a fold method on the option type. Problem solved, now you never will need to match an option ever again! The harder solution would be to implement HKT and add a real monad trait, but let's not get into that. Another example are the async/await syntax. Why does this syntax need to exist? What value does it provide? Why can't a future just be a regular old class?

A long time ago I thought Rust was going to be a flexible and innovative general purpose language. While it still is undoubtedly innovative, it seems like the target audience has shrunk considerably. And as GCs improve and get more tunable, I think that target audience is going to get even smaller in the future.

[steveklabnik]

> even you must admit that Rust has gotten less 'functional' in nature as time goes on.

I don't think this is true, especially when you look at long timescales.

> New syntax or ad-hoc abstractions are being created to handle problems that have well known FP solutions.

They have known solutions when you have a GC and no control over memory layout. They do not have known solutions in a language like Rust.

> Take this matching on an Option business. The easy solution is to just add a fold method on the option type. Problem solved, now you never will need to match an option ever again!

Sorry, I do not understand what you're talking about. (I coded in Haskell most a decade ago, I'm not on the lang team.) What would fold do on an option, specifically? Fold is usually a list operation, but an option is a list of zero or one... so it would be a no-op?

> The harder solution would be to implement HKT and add a real monad trait, but let's not get into that

Again, this is "we don't know if this is possible in a language like Rust" territory. Which is why you don't want to get into that.

> Another example are the async/await syntax. Why does this syntax need to exist?

Specifically because of the previous statement. It is not clear that a more abstract option is possible. We could wait for more years until maybe it's proven possible, or we could implement a useful feature today that we know is.

It's also more significant in Rust than other languages due to borrowing. http://aturon.github.io/tech/2018/04/24/async-borrowing/ is a bit out of date but the concept is the same.

> Why can't a future just be a regular old class?

Rust doesn't have classes. Futures are a regular old typeclass.

> While it still is undoubtedly innovative, it seems like the target audience has shrunk considerably.

We have seen a massive uptick in adoption over the past few years. async/await, for example, has been a feature that a lot of folks have said "I'll start using Rust once that hits stable."

[saagarjha]

> What would fold do on an option, specifically? Fold is usually a list operation, but an option is a list of zero or one... so it would be a no-op?

Presumably the fold takes advantage of the fact that the default, "accumulator" value is chosen if the Option is empty and the collapse function just runs what would be the Some arm of the match statement.

[steveklabnik]

Oh, duh. Thanks.

Thats https://doc.rust-lang.org/stable/std/option/enum.Option.html..., I think?

[saagarjha]

If the team had just written Haskell for a year they would have picked the obviously superior "fold" name for this operation. (I think you can actually use fold here if you really wanted it, since Option implements IntoIter?):

   Some(0).iter().fold("some", |_, _| "none")

[remcob]

To match the semantics of a 'fold' the closure would have to receive two arguments: the default value and the Some value.

(I don't think Option has such a function, and I don't see why it should.)

[remcob]

> Another example are the async/await syntax.

Besides the GC that is already mentioned, Haskell has lazy evaluation which gives you coroutines for free. Coroutines are more or less synonymous with async, so in Haskell the implementation is a no-op.

From what I read, much of the challenge of adding async to Rust was in designing the coroutine mechanism, which is a substantial language extension.

[geofft]

What do you do if someone writes Haskell for a year and concludes "Actually, C++ and Java are better at this than Haskell"? Force them to write more Haskell until they reach the right conclusion?

(I personally love Rust because I found Haskell amazing but ill-suited to the work I wanted to do and I'm glad to have an option that's not C++ but is suited to the same sorts of applications as C++.)

[voldacar]

based