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

111–120 of 176 posts

Re: Monads and GATs in Nightly Rust

#111

Post by deeviant »

valenterry wrote: post #69
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…

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.

Re: Monads and GATs in Nightly Rust

#112

Post by troutwine »

Philip-J-Fry wrote: post #86
dathinab wrote: post #67

Earlier quoted context omitted.

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

I agree with you. Spend enough time in an ecosystem and you'll eventually find a need to interact with most of its features.

My experience in Rust has been pretty positive. I'm writing a new book on systems programming with Rust and, as a result, have spent a great deal of time digging into the internals of libraries, the compiler. The compiler is, by far, the most surprising because it's allowed to use nightly features in new and interesting ways. Everything else, when I encounter something new to me, I'm able to understand from the Rust documentation. The key differentiator with C++ is, I think, the focus on documentation and ensuring that new features are explainable in a simplistic way. This helps make new features introduced into the language jive, to my eye.

That said, there are areas of the ecosystem _outside_ the language that are hard to keep up with. The future notion in Rust used to be like that, before Future was included in the base language. That's tricky but, again, I think Rust strikes a good balance here: conservative about content in the base language, enthusiastic experimentation in the ecosystem. It's possible that this'll break down some day but it hasn't yet and I don't see it as happening soon.

Re: Monads and GATs in Nightly Rust

#113

Post by swsieber »

f154hfds wrote: post #54
swsieber wrote: post #50

Earlier quoted context omitted.

I would lament if everything were in the std at this point. There will be another wave of change after GATs stabilize. That said, there are some traits being standardized and moving to the std, which should be great for interop.

Is there any work on creating feature-based sub-standard libraries that are aggregations of popular (and robust) crates but tying all of their versions together? For example, I'd like to put in my Cargo.toml: sstd = { version = "1.0", features = ["clap", "serde", "rand"] } Where the sstd crate essentially has a whole mess of crates bundled together ensuring only one version is used for each individual dependency? Per…

In addition to what Steve said, note that the rust playground includes support for the most popular crates.

Re: Monads and GATs in Nightly Rust

#114

Post by s-combinator »

stevedonovan wrote: post #61
caspper69 wrote: post #21

Earlier quoted context omitted.

I can relate to this 100%. I'm working though a Rust course right now, and while my code works fine (once it compiles), I always see the reference implementations of the code, and it's like 2 lines of filter/map/collect, and voila. Meanwhile, my 8 line frankenfunction looks like the Charlie Brown Christmas tree.

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 associative way, why not use a fold/reduce in order to get as much parallelism as possible for free? Sure, your compiler could try to do some fancy static analysis to try to figure out whether the loop you've written is equivalent to a more efficient program, and if so, replace it for you, but that's a lot of work for the compiler writer and inherently limited: we're a long way away from compilers being able to guess properties of programs and synthesize proofs for them. Sometimes avoiding loops is both conceptually clearer and practically more efficient.

Re: Monads and GATs in Nightly Rust

#115

Post by mrkeen »

zelly wrote: post #97
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…

FP has little to do with real-world programming and not even much to do with computer science. Look through Knuth, Dijkstra, Turing, etc. and find an example of FP--you can't. It's the mentally challenged stepchild of CS for programmers who have developed physics envy (or perhaps more appropriately, string theory envy).

> Look through Knuth, Dijkstra, Turing, etc.

Why even name-drop academics though? Shouldn't you be dismissing them as irrelevant and praising Gates, Jobs and Gosford instead? You know, real INDUSTRY figures?

> find an example of FP--you can't.

Programming with functions... programming with functions... programming with functions. Sure.

> Dijkstra

Here is Dijkstra protesting the replacement of Haskell with Java https://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs...

> Turing

Turing and Church were contemporaries. The Turing Machine was a landmark achievement useful for reasoning about the limits of computation, but where is it today? Have you tried building anything out of a Turing machine (assuming you had infinite tape)? It's basically Brainfuck. Church's Lambda Calculus predates it and is still useful.

Re: Monads and GATs in Nightly Rust

#116

Post by mrkeen »

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…

The exact same argument exists for not hiding IntList and StringList behind fancy generics like List[I], which obscure the how.

Re: Monads and GATs in Nightly Rust

#117

Post by akiselev »

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…

I've never really grasped FP and I seem to be in an eternal state of confusion about monads but I'm excited about GATs in Rust. They'll allow for traits that hide implementation details like `trait Foo { type Bar = T | Box | Arc }` without dynamic dispatch or ugly hacks.

Re: Monads and GATs in Nightly Rust

#119

Post by burntsushi »

kmeisthax wrote: post #107
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…

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…

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.

Post reply on HN