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

121–130 of 176 posts

Re: Monads and GATs in Nightly Rust

#121

Post by whateveracct »

tener wrote: post #68
amelius wrote: post #65

Earlier quoted context omitted.

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.

It isn't immediately obvious that FP requires GC. Sure, the languages we have right now make use of GC, but it is far from certain that there is no way for a subset of FP features to exist in a language without GC.

Another reason GC is nice: FP tends to rely on immutable linked data structures with pervasive sharing. That makes ownership complicated.

Re: Monads and GATs in Nightly Rust

#122

Post by Animats »

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 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 those operations. It's like C++ subclassing. So generics over types defined by others can be impossible to write in Rust. This has no safety benefit, since generics are resolved at compile time and all safety tests can be made after generic expansion.

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. This led to a horrible hack involving a Rust crate which has types U1, U2... U50 or so, so small numeric constants can be bashed through the Rust type system.

Not seeing the benefit of all this.

I have to go struggle with another non-helpful "lifetime `'static` required" message from the borrow checker now.

Re: Monads and GATs in Nightly Rust

#123

Post by Animats »

dragonelite wrote: post #40
WhoCaresLies wrote: post #35

This confirms my concerns.. Rust is becoming a Scala language, too much features.. Rust should have been as simple as C, i wonder if there will be some compiler switchs to ban certain features, and crates that are tagged to work with certain features, so at least things will be easier to deal with

You do know you don't have to use everything under the sun. If you want to use a sub set then use the sub set.

Others may have to read your code.

Re: Monads and GATs in Nightly Rust

#124

Post by lambda_obrien »

whateveracct wrote: post #109
lambda_obrien wrote: post #79

Earlier quoted context omitted.

With linear types you could get rid of the GC, probably.

Hm ATS is prior art re: linear types and closures. It's definitely not the same. That said, -XLinearTypes in GHC 9.x will open up a world of memory management capabilities in library-space for Haskell. Very exciting stuff! If you push the heavy stuff off-heap, then the GC just becomes a slightly fancier arena allocator.

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 purpose (it's a stream processing application with a small [code-wise, the data set can be huge] in-memory tree database which I want to be able to do the memory object allocation for myself).

Re: Monads and GATs in Nightly Rust

#125

Post by patrickthebold »

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 haven't been paying too much attention to the language development but AFAIK the vast majority of the FP in scala is in libraries (cats/scalaz) and not baked into the language.

Sure the language _has_ higher kinded types and implicits can be twisted to support type classes, but neither of those seems to have been forced in the language from FP fanatics, but rather the language has always included some set of advanced features.

Re: Monads and GATs in Nightly Rust

#126

Post by pixel_fcker »

Animats wrote: post #122
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 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…

const generics are very close to being done, which will fix the array issue you mention by allowing code to be generic over integers as well as types. This is already in for built-in arrays and traits but user traits currently require nightly.

I agree with you about the orphan rule being annoying and wish they’d relax that, but I much prefer traits to C++ duck-typed templates, if only because it makes error messages from passing an unsupported type to a generic function clear and concise as opposed to the thousands of lines of confusing output you often get in C++.

Re: Monads and GATs in Nightly Rust

#127

Post by Nullabillity »

Animats wrote: post #122
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 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…

> This has no safety benefit, since generics are resolved at compile time and all safety tests can be made after generic expansion.

The compiler can verify that types are satisfied. It cannot verify that you agree on what those types and operations mean.

For example, `Iterator` isn't very useful without being able to agree on what `Iterator::next`'s `Option` means. So implicit structural traits á la Go is somewhere between useless and actively harmful.

You can have nominal traits while allowing orphan instances (that is, implementations of foreign traits on foreign types). Scala and Haskell both have that. But IMO neither has a good solution for the conflicts that inevitably arise in that case.

Re: Monads and GATs in Nightly Rust

#128

Post by Twisol »

mrkeen wrote: post #115
zelly wrote: post #97

Earlier quoted context omitted.

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:…

>> etc

John Backus, who can hardly be considered lesser than any of the others on this cherry-picked list, used his Turing Award lecture to rally for functional programming:

http://www.thocp.net/biographies/papers/backus_turingaward_l...

Re: Monads and GATs in Nightly Rust

#129

Post by Twisol »

zelly wrote: post #106
cbarrick wrote: post #99

Earlier quoted context omitted.

> not even much to do with computer science That is very debatable. Lambda calculus is a BFD in the subfield of programming languages, which is the topic at hand.

> Lambda calculus is a BFD in the subfield of programming languages This is a good example of abusing the vocabulary of mathematics as is common in the FP world. A programming language is not an object in abstract algebra. You can't add, subtract, or factorize a programming language. It's just software.

"BFD" here means "big f#$%ing deal", not "b??? factorization domain".

Re: Monads and GATs in Nightly Rust

#130

Post by lights0123 »

Animats wrote: post #122
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 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…

> This has no safety benefit, since generics are resolved at compile time

It's not only safety. That's why C++ concepts were invented. https://cpp.godbolt.org/z/8Gcrj6

Post reply on HN