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

151–160 of 176 posts

Re: Monads and GATs in Nightly Rust

#151

Post by ebruchez »

chridou wrote: post #138
ebruchez wrote: post #108

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 suspect that the above reflects a very personal experience rather than something general. Isn't the FP community in the Scala world at war?

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

I have heard that there have been one or two difficult individuals in certain segments of the FP community, especially 5-10 years ago. I understand that this caused the Scalaz/Cats split. But I have never really needed to care about it and it seems to me that this is history. I could be wrong but it's my personal experience.

Re: Monads and GATs in Nightly Rust

#152

Post by a1369209993 »

chridou wrote: post #134
kmeisthax wrote: post #107

Earlier quoted context omitted.

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…

> and have the one ring to rule them all.

It's not a ring, it's a monoid; there's (in general) no negation.

Re: Monads and GATs in Nightly Rust

#153

Post by alquemist »

s-combinator wrote: post #114
stevedonovan wrote: post #61

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…

99% of the time a loop works just fine, because there are no measurable gains to be had from parallelism. For the 1% where performance matters, it's usually a bit more involved that simply using a map or fold, and hopefully already packaged as an off-the-shelf library. To have measurable gains from parallelism one has to be very intentional in balancing communication vs computation. Think carefully designed libraries like cuDNN.

Re: Monads and GATs in Nightly Rust

#154

Post by burntsushi »

kmeisthax wrote: post #147
burntsushi wrote: post #119

Earlier quoted context omitted.

If someone asked me if I've ever used functors or monads in Rust, I would unequivocally say "no, I haven't." And I would say that because I've never written code that's generic over functors or monads. I think this kind of "you've already used functors or monads, they are just scary names" retort is really missing the point of what folks are complaining about.

Right, but I can think of a few cases where one might want to be generic over effect systems; especially in library code. For example, you could have a parsing library that accepts both blocking and non-blocking I/O streams. You need a Map/Then trait in order to express that generically.

I didn't say there weren't any use cases. Of course there are use cases.

I'm not even taking a side here in this thread (although I have advocated against functors/monads in the past). I'm saying that your comment is missing the point of folks who are skeptical of things like functors and monads.

Re: Monads and GATs in Nightly Rust

#155

Post by valenterry »

deeviant wrote: post #111
valenterry wrote: post #69

Earlier quoted context omitted.

It's pretty flourishing though if you look at the graphs.

If you look at the graphs or some HN comment, apparently, every language is flourishing, including cloture! Conversely, using the same technique, one could also ascertain that every language is also languishing.

COBOL is flourishing? A nightmare!

Re: Monads and GATs in Nightly Rust

#156

Post by valenterry »

zaptheimpaler wrote: post #74
valenterry wrote: post #69

Earlier quoted context omitted.

It's pretty flourishing though if you look at the graphs.

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.

You are right with your concern.

Fortunately, when you look at the latest version, Scala 3, you will see that they put more effort into simplifying the language and removing things that people complained about than adding new things.

To be a bit more concrete:

- Remove certain ways of using implicits and making them less confusing

- Cleaning up the language core and removing features (such as impure macros or constructs that are rarely used or confusing)

- Making syntax easier for many cases without adding new features

- Adding union types (comparable to typescript). This is a new feature and not a small one, but I think it will make the language easier to use for many people.

And I think union types and intersection types are a very practical thing to have. So all in all, I'm happy to see that Scala becomes more practical and less esoteric with this release.

Re: Monads and GATs in Nightly Rust

#157

Post by Avi-D-coder »

amelius wrote: post #65
chridou wrote: 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…

You will probably not see much Haskell style functional programming in Rust simply because there is no garbage collector in Rust, and Haskell depends on one very much.

I'm working on fixing that ;)

Unfortunately we don't yet have covariant associated types, so my GC is a pain to use.

In all seriousness, I'm not sure if Rust will ever be a great fit for abstract high level programing. The syntax is just too verbose, and lifetimes are a leaky abstraction. It might make a good compiler target though. At the very least next generation FP needs to have a great Rust interop story.

Re: Monads and GATs in Nightly Rust

#158

Post by eggy »

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 have decided to learn Rust to replace C (for me) instead of Zig, which I like, but Rust has more support for my learning in terms of community and documentation. I plan to return to Zig when it matures a bit more. I get my dose of FP when I program in J or APL. I use them for very mathy and fun things, and I don't even think about FP; they are FP. I am working my way through an 11-page paper that implements a CNN in APL in 10 functions that amounts to 10 lines of APL, 1 function per line [1]. Amazing and simpler than my stabs at Haskell and Idris or Scala and F#.

[1] https://dl.acm.org/doi/pdf/10.1145/3315454.3329960?download=...

Re: Monads and GATs in Nightly Rust

#159

Post by lambda_obrien »

whateveracct wrote: post #145
lambda_obrien wrote: post #124

Earlier quoted context omitted.

I'm very interested in that. I was using zig for a while, and I wish I could build my own (simple) memory allocators for certain things in Haskell like that. I have a project where I want to be able to directly control the memory layout of the data structures but since that's just a tiny part of the whole program I don't want to build the whole thing in zig or something like C, I prefer Haskell for this specific purp…

Yeah you can do that. I'm actually working on a little library to do just that (control memory layout) although it's more focused on 0-copy FFI w/hsc2hs You can also have the RTS manage the memory itself, but have complete access to a pointer to raw memory. That doesn't work if you have pointers in the raw memory ofc, but it is a nice option if that's not the case.

If you don't mind, can you send me your repos if it's public work? I'm interested in 0-copy stuff, too, the database I'm doing can benefit from 0-copy (again, a small part of the codebase but a big part of the technical challenge), and I'm seeing that linear types help a lot with that kind of thing from the reading I've done lately. I'm mostly a tinkerer and like to see what's the newest cool stuff people are making. My email is in my profile.

Re: Monads and GATs in Nightly Rust

#160

Post by joel_ms »

zaptheimpaler wrote: post #66

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…

So scala is neither taken over or destroyed and the author of this post stresses multiple times that he does not suggest that this approach by adopted by the rust community, even concluding with:

>But Rust is not Haskell. The ergonomics of GATs, in my opinion, will never compete with higher kinded types on Haskell's home turf. And I'm not at all convinced that it should. Rust is a wonderful language as is. I'm happy to write Rust style in a Rust codebase, and save my Haskell coding for my Haskell codebases.

How is any of this fanatical?

Post reply on HN