The lang team would be in charge of these kinds of features, and I'm not on it, so I can't totally say. There are certainly members who do want this stuff. However, community sentiment is all over the map. https://www.reddit.com/r/rust/comments/b6bu2c/idiomatic_mona... is the reddit thread on this post, you can see a number of different opinions expressed there.

I personally want to see examples of real Rust code that has a problem that this solves. I get monads, I like monads in Haskell, but I'm unconvinced that the additional complexity is worth it in Rust.

Well, I hope they don't. Functional extremism killed Scala for the wider public (IMHO)

I'd say that not enough functional extremism killed Scala. It tried to be all things for all purposes, compatible with every approach. So it grew into a incomprehensible monster of a language, full of subtle traps, like C++.

Making things compact and focused helps. Of mixed-approach languages, I see Kotlin's approach to integrating FP as more successful.

I'm sorry, I respectfully disagree on the "not enough" :-)

I think it is a matter of choice of audience. If you want pure functional languages, there are plenty that will rock your boat (Haskell, OCaml ...).

But, to my mind, I see Rust as a somewhat "modernised" C/C++ with, like Python, the most interesting and accessible parts of FP backed in. It is a balance and it is fragile. So, as I said, I hope that Rust will keep that fine line.

All that said, it only is my opinion, I might be wrong and the wider audience might be ready for "harder" FP. But I doubt it.

I'm not sure what parts of FP python has you're referring to but it seems pretty lacking. It has a few combinators, that's about it.

The influence of "FP" on rust is really more like the influence of Haskell's type system. Rust is pretty far from a functional language but it does share a lot of type system features with Haskell: type classes, sum and product types, HM type inference

Rust not only has some good parts from FP; they are added thoughtfully enough to keep them logically sound. So the fact that there are math-backed theories behind them still matters.

With C++, I can't say the same is true. Some libraries try to alleviate that, of course.

What math-backed theories? Why do they matter? Do you mean for the compiler team or for the users?

Hindley-Milner type inference and linear types (used indirectly for lifetimes) spring to mind.

Those are useful for compiler devs and language designers, not so much for the average user of the language.

Kotlin doesn't even have real pattern matching. Calling it integrating FP is a sad joke.

It's got algebraic types, and a typeclasses proposal (with a PR!) was actively worked on, last time I checked.

Algebraic types without being able to conveniently destructure them is maybe half the benefit at best.

Pattern matching has nothing to do with FP.

Only if you think algebraic types have nothing to do with FP, in which case you have a very idiosyncratic definition of FP.

imo the early explosion of language complexity is what doomed Scala. There were a lot of failed and semi-failed experiments in the language. They even tried and gave up on structural typing and regressed to some half-assed attempt. Jumped on bandwagons they regretted like xml literals. There was also that research-based scala v2 rewrite. http://dotty.epfl.ch/ -- These kinds of endeavors suck a lot of thought power from the community.

There was functional extremism in Tony Morris and his scalaz pet project, but Scala was already doomed.

Of course, these are all things Rust has seemed to avoid and hopefully continues to avoid.

> There was also that research-based scala v2 rewrite. http://dotty.epfl.ch/

Was? Last I heard, Dotty is ongoing and will transition into Scala 3.

I like to think of Scala as the C++ of the JVM world. It's a complex language with a lot of features, but it can be extremely powerful if you know what idioms to use and where to use them. For example, template abuse in C++ is akin to implicit abuse in Scala.

This is right. Dotty is in very active development, and is planned to become Scala 3 some time in 2020.

Well, sadly, too powerful often leads to abuses and unmaintainable code.

Maybe this is something that helped grow Go's popularity by being simpler ? (I don't know, just wondering)

Ok, I've been oversimplifying by reducing it to the functional aspect of it (granted that might come from Scalaz recollection) but I stand by my opinion that too much functionalism will hurt.

But, on the other hand, a balance has to be found if Rust ever want to be widely adopted. Let's be honest 2s here, Rust is already hard enough to learn for the average developer, adding higher order function on top of that will not help adoption.

IMHO, right now Rust the just enough amount of complexity to still be interesting to the majority. It really depends on who Rust want to target in the long run.

> I like monads in Haskell, but I'm unconvinced that the additional complexity is worth it in Rust.

Haskell and Rust are different enough that this is definitely a concern. Lazy evaluation and GC used throughout, vs. eager evaluation in a language which uses affine typing and regions to avoid GC... I can see how general monads might not work very well, and the OP does touch on this a little bit.

Sounds about right. Thanks! And I’d guess that the perf overhead would be nontrivial either even in Rust.