Live data from Hacker News

Monads and GATs in Nightly Rust

fpcomplete.com

131–140 of 176 posts

Re: Monads and GATs in Nightly Rust

#131

I saw Scala taken over and destroyed by the FP fanatics who want to turn every language into Haskell. I hope they don't do the same to Rust. Just use Haskell and leave the rest of us alone! It sounds silly but its true.. as you increase the complexity of the language, the hardcore users making the libraries adopt those features, which means users have to adopt those features as well. Pretty soon everyone is talking a…

I kind of get that feeling, too. Rust uses "traits" to do both generic-like things and inheritance-like things. It's not clear this was a win. The result seems to be a system which does both badly. Rust generics are very restrictive. They're not at all like C++ generics. It's not enough that every operation on a type needed by a generic be implemented. The type has to be part of a single trait that provides for all t…

> Traits and fixed array bounds do not play well together. This is considered a bug, and it's been a bug since at least 2017. Generic parameters can only be types, not numbers.

FWIW the remedy for this is being stabilized soon: https://github.com/rust-lang/rust/pull/79135

Re: Monads and GATs in Nightly Rust

#132

Earlier quoted context omitted.

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, a…

> Rust's type machinery is about exposing things

That makes sense, thanks for explaining that, I am used to Haskell but never used Rust.

Re: Monads and GATs in Nightly Rust

#133

Earlier quoted context omitted.

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, a…

> Rust's type machinery is about exposing things That makes sense, thanks for explaining that, I am used to Haskell but never used Rust.

No problem. I mean, in some sense, it's also about abstracting things, it's just that Rust cares about a lot more details than other languages, and those get reflected in type signatures.

Re: Monads and GATs in Nightly Rust

#134
post #64

Even though I see that these language capabilities remove restrictions I hope that HKTs and with them Functors, Monads, etc. will never make it into Rust. The thing I like most about Rust is that it is still a practical language where I can still solve my problems in different ways and always know what will happen. I also care about the "how" and not only about the "what". Everything being F[_]ed is what I do not nee…

Functors and Monads already exist in Rust, you just can't talk about them in the trait system. Option, Result, and Future are all both Functors (map) and Monads (and_then). You've probably used them without even knowing, because we didn't give it some weird, unlearnable category theory name. If someone were to create an explicit trait for them and RFC it, they'd probably name it something like Map and Then rather tha…

> Option, Result, and Future are all both Functors (map) and Monads (and_then).

No. They are Option and Result and Future.

> You've probably used them without even knowing, because we didn't give it some weird, unlearnable category theory name.

No. I have not used them without even knowing. I have used Option, Result and Future. I do not need some meta-universe which just makes easy things more complicated by stating some laws which types must hold just for the sake of discussing them and have the one ring to rule them all.

Re: Monads and GATs in Nightly Rust

#135

I saw Scala taken over and destroyed by the FP fanatics who want to turn every language into Haskell. I hope they don't do the same to Rust. Just use Haskell and leave the rest of us alone! It sounds silly but its true.. as you increase the complexity of the language, the hardcore users making the libraries adopt those features, which means users have to adopt those features as well. Pretty soon everyone is talking a…

> I saw Scala taken over and destroyed by the FP fanatics I suspect that the above reflects a very personal experience rather than something general. I have been using Scala for 10 years and never used monad transformers. I find Scala code usually easy to write and to read. At this point I wouldn't trade it for any other language. From where I stand, Scala was neither "taken over", nor "destroyed by FP fanatics". It…

I have worked in multiple Scala shops and contributed at the highest levels to the Scala ecosystem and my experiences confirm that this rotten attitude is very real and increasingly the norm, as everyone but the fanatical FP-ers have long-since moved on to other more professional/productive circles.

With the exception of shops using Scala exclusively for Spark, someone entering the ecosystem can expect to be constantly talked down to if you dare to use something deemed by the FP hivemind to be evil (so, anything other than pure, immutable, FP-style with all side effects controlled, no exceptions or nulls, no inheritance (only typeclasses), etc). They'll be derided and skoffed at constantly for being "just a java++ programmer".

Meanwhile, for all their smugness, the FP community has achieved nothing at all that has reached beyond to the world outside of Scala. The projects successful in bringing in developers to Scala have been decidedly in the disparaged lightly-FP/"Java++" style: Spark, Kafka, LinkerD (1.X -- they rewrote 2.X in Go/Rust), Flink, Akka, PlayFramework, Twitter's stack, Prisma, etc. Shockingly, the predominant view among these delusional pure-FP-obsessives, which usually goes unchallenged, is that the creators of Spark don't know anything about Scala or are bad engineers!

Scala 3 is a joke and will do the exact opposite of the stated goals from years back. It was supposed to streamline and simplify the language, remove gotchas, add a few high-impact simple features like Union types and trait parameters. Now it's a grown into a monstrosity of complicated features that your average dev will never use. Rather than streamline and simplify Scala 2's issues with having dozens of ways to do the same thing, it introduces multiple new dimensions by which people can do things in multiple ways (legacy implicit system vs new "given" syntax; braces syntax vs indentation-based).

Control structures helpful for imperative programmers are being removed (you cannot early return from a for loop without a huge hassle), `do-while` is removed, etc. These breakages were not pushed back against because the only people still around are FP'ers who don't want people using loops in the first place.

New type-system features are being added without even knowing if there's a possible use-case. The whole thing is a mess.

Re: Monads and GATs in Nightly Rust

#136

Earlier quoted context omitted.

> I saw Scala taken over and destroyed by the FP fanatics I suspect that the above reflects a very personal experience rather than something general. I have been using Scala for 10 years and never used monad transformers. I find Scala code usually easy to write and to read. At this point I wouldn't trade it for any other language. From where I stand, Scala was neither "taken over", nor "destroyed by FP fanatics". It…

I have worked in multiple Scala shops and contributed at the highest levels to the Scala ecosystem and my experiences confirm that this rotten attitude is very real and increasingly the norm, as everyone but the fanatical FP-ers have long-since moved on to other more professional/productive circles. With the exception of shops using Scala exclusively for Spark, someone entering the ecosystem can expect to be constant…

> the [pure] FP community has achieved nothing at all [in the last 20 years]

feels so right, is it true?

Re: Monads and GATs in Nightly Rust

#137
I know some people are worried about this, but the true power of GATs is to allow you to add lifetimes to associated types. This leads to a whole avenue of new optimizations and efficient representations.

It’s not about making things “more like Haskell”, that just happens to be a consequence of making more low-level operations representable in safe rust code, which if you think about it is the way rust has operated from the very beginning.

Re: Monads and GATs in Nightly Rust

#138

I saw Scala taken over and destroyed by the FP fanatics who want to turn every language into Haskell. I hope they don't do the same to Rust. Just use Haskell and leave the rest of us alone! It sounds silly but its true.. as you increase the complexity of the language, the hardcore users making the libraries adopt those features, which means users have to adopt those features as well. Pretty soon everyone is talking a…

> I saw Scala taken over and destroyed by the FP fanatics I suspect that the above reflects a very personal experience rather than something general. I have been using Scala for 10 years and never used monad transformers. I find Scala code usually easy to write and to read. At this point I wouldn't trade it for any other language. From where I stand, Scala was neither "taken over", nor "destroyed by FP fanatics". It…

> I suspect that the above reflects a very personal experience rather than something general.

Isn't the FP community in the Scala world at war?

Re: Monads and GATs in Nightly Rust

#139

Earlier quoted context omitted.

Remember, using a loop is not a sin! (And I would hate us to get to the point where loops are automatically considered kindergarten code)

Using a loop is not a sin, but it is often counterproductively over-prescriptive. A loop says, 'do these things in this order in a single thread'. If the loop body is an effect-free function, then the order doesn't matter, why not use a map to let the compiler or run-time decide how many cores/containers/botnets to throw at the problem? Similarly, if the loop combines the results of its iterations in a unital and ass…

> why not use a fold/reduce in order to get as much parallelism as possible for free?

I always wondered how this would then be configured in a convenient way. I mean, there are situations where you can not just let the compiler parallelize to the max (e.g. web services).

Re: Monads and GATs in Nightly Rust

#140

Earlier quoted context omitted.

> I saw Scala taken over and destroyed by the FP fanatics I suspect that the above reflects a very personal experience rather than something general. I have been using Scala for 10 years and never used monad transformers. I find Scala code usually easy to write and to read. At this point I wouldn't trade it for any other language. From where I stand, Scala was neither "taken over", nor "destroyed by FP fanatics". It…

I have worked in multiple Scala shops and contributed at the highest levels to the Scala ecosystem and my experiences confirm that this rotten attitude is very real and increasingly the norm, as everyone but the fanatical FP-ers have long-since moved on to other more professional/productive circles. With the exception of shops using Scala exclusively for Spark, someone entering the ecosystem can expect to be constant…

I used Scala2 professionally for a few years. Recently picked up Typescript, it has become a very usable Java++ language.
Post reply on HN