Monads and GATs in Nightly Rust • Hacker News Board

Re: Monads and GATs in Nightly Rust

#141

Post by the_only_law » Fri, Dec 11, 2020, 8:52 PM UTC

alquemist wrote: post #140

uDontKnowMe wrote: post #135

Earlier quoted context omitted.

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.

I’ve been interested in Scala recently, although I’ve heard it’s been unfortunately pigeonholed in industrial use. Would you say it’s worth takin up now or wait for Scala 3?

Re: Monads and GATs in Nightly Rust

#142

Post by alquemist » Fri, Dec 11, 2020, 9:07 PM UTC

the_only_law wrote: post #141

alquemist wrote: post #140

Earlier quoted context omitted.

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

I’ve been interested in Scala recently, although I’ve heard it’s been unfortunately pigeonholed in industrial use. Would you say it’s worth takin up now or wait for Scala 3?

Haha, I'm the wrong person to ask. I was fortunate enough to be in a hands on senior role, and I promoted a very light Java++ style, to be learned in a 2 hours seminar: immutable collections, case classes, pure functions, impure logging & exceptions, sparingly used interface polymorphism, recursion, filter/map/flatmap/fold. Scala: The Good Parts. To this day I have not learned the first thing about implicits or type variance, and probably there are many many many more Scala features I haven't even heard of. The biggest challenge was helping the rest of the team avoid writing inscrutable sbt plugins. The plus side, it makes little difference Scala2 vs. Scala3. The downside, some teams may scoff at such a mundane approach.

Re: Monads and GATs in Nightly Rust

#143

Post by alquemist » Fri, Dec 11, 2020, 9:22 PM UTC

Twisol wrote: post #128

mrkeen wrote: post #115

Earlier quoted context omitted.

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

'FP' covers 2 meanings:

A. Pure functions + immutable data structures.

B. Expressive type systems, all the way to compile-time metaprogramming and dependently typed proofs.

Writing programs in style A. is tremendously valuable. Expending too much effort in the fine points of the type system, which invariably is simultaneously both under-expressive and over-expressive, is a complete waste of time. Some critical projects require high defect-free confidence, and for those it's legitimate to go full in formal proofs and take the 10x-100x productivity slowdown. For mere mortals, documenting the structure of the data (json) manipulated by the respective functions suffices.

Re: Monads and GATs in Nightly Rust

#144

Post by brundolf » Fri, Dec 11, 2020, 9:36 PM UTC

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…

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

IMO the fact that Rust doesn't do inheritance well is a feature, not a bug. My understanding is that most people even in OOP circles have realized that composition is better than inheritance, and I see Rust's choices around it as a reflection of that.

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

Maybe I'm misunderstanding, but do you know that a generic can combine multiple traits? For example:

  fn foo(x: T) {
    ...
  }

Here T must implement Copy and Add and Sync.

Maybe what you're talking about is the fact that methods' identities aren't fully described by their names + types, but also by their trait? i.e.:

    trait TraitA {
     fn foo(&self, x: i32) -> i32;
    }
    
    trait TraitB {
     fn foo(&self, x: i32) -> i32;
    }
    
    struct Foo {
    }
    
    impl TraitA for Foo {
     fn foo(&self, x: i32) -> i32 {
      x + 1
     }
    }
    
    fn requires_b(x: T) {
        x.foo(12);
    }
    
    fn main() {
        let f = Foo { };
        requires_b(f);
    }

    error[E0277]: the trait bound `Foo: TraitB` is not satisfied
      --> src/main.rs:25:16
       |
    19 | fn requires_b(x: T) {
       |                  ------ required by this bound in `requires_b`
    ...
    25 |     requires_b(f);
       |                ^ the trait `TraitB` is not implemented for `Foo`

This was an opinionated decision made by the Rust team - which I think was a good decision - to address the fact that it's possible to have unwanted overlaps between trait method signatures. Just because fn foo(&self, x: i32) -> i32 is defined for a struct, doesn't mean it's the same foo that you're wanting to call. Distinguishing things by trait strengthens the contract. It also avoids the diamond problem. You're right that this isn't directly related to "safety" in a memory sense, but it's part of an overarching philosophy of Rust that encourages intentionality and discourages footguns.

> Generic parameters can only be types, not numbers.

This is a work in progress and has partially been rolled-out; the full implementation is on the way: https://rust-lang.github.io/rfcs/2000-const-generics.html

Re: Monads and GATs in Nightly Rust

#145

Post by whateveracct » Fri, Dec 11, 2020, 10:21 PM UTC

lambda_obrien wrote: post #124

whateveracct wrote: post #109

Earlier quoted context omitted.

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

Re: Monads and GATs in Nightly Rust

#146

Post by Bjartr » Fri, Dec 11, 2020, 10:40 PM UTC

dustingetz wrote: post #136

uDontKnowMe wrote: post #135

Earlier quoted context omitted.

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?

Well, that would've been a side-effect

Re: Monads and GATs in Nightly Rust

#147

Post by kmeisthax » Fri, Dec 11, 2020, 10:46 PM UTC

burntsushi wrote: post #119

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…

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.

Re: Monads and GATs in Nightly Rust

#148

Post by tasuki » Fri, Dec 11, 2020, 11:11 PM UTC

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…

It could be argued that understanding the commonality of certain aspects of Option, Result, and Future results in a simpler model rather than a more complicated one.

Don't you find it intriguing and interesting that these seemingly different types have these commonalities?

Re: Monads and GATs in Nightly Rust

#149

Post by ebruchez » Fri, Dec 11, 2020, 11:57 PM UTC

uDontKnowMe wrote: post #135

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 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 am not sure how much of that is worth responding to. You obviously have a strong opinion and have been burned and appear to have pent up anger. I don't share your opinion.

I use Scala, I love it, I am looking forward very much to Scala 3, and I find help in the community when I need it. And I am not a pure FP programmer, although I like lots of the ideas of FP.

> everyone but the fanatical FP-ers have long-since moved on to other more professional/productive circles

I for one haven't and I am not a "fanatical FP-er". I bet I am not the only one.

> Scala 3 is a joke […] it's a grown into a monstrosity of complicated features that your average dev will never use

I don't think that's true at all.

> New type-system features are being added without even knowing if there's a possible use-case.

I don't know what you are referring to. From the doc, I note:

- intersection types, which are essentially a better way (commutative) of doing `A with B`

- union types, which several languages now have, including TypeScript, and which are definitely a very useful feature (in particular for Java and JavaScript interop, but there are other use cases)

- dependent and polymorphic function types, which are just an extension of what was possible before with methods

- match types and type lambdas, which I cannot comment on

> The whole thing is a mess

I obviously don't see things with the same eyes you do. I am really excited about Scala 3 and I do think it improves the language significantly, as it should.

Scala 3 also aims at solving a very real issue with previous releases of Scala, namely that there is a solid binary compatibility story, within Scala 3.x, but also between Scala 2 and Scala 3.

> the only people still around are FP'ers who don't want people using loops in the first place

I can't remember the last time I used `do-while`. But you can rewrite this trivially to a `while`, which is not going away (in fact, I think that Scalafix will do that for you automatically). In any case, community questions about things like mutability, loops, or more imperative features, typically receive answers to the effect that it's all right to use such constructs, especially in the small (like a the level of a single function). These features are part of Scala and generally accepted. They are used by the Scala standard library, and regularly acknowledged by Martin Odersky. A quick code search finds such uses in libraries such as Circe and Cats.

Regarding non-local `return`, you are also overlooking the fact that this is a frequent cause of confusion and errors. Removing this feature has little or nothing to do with FP fanaticism.

Personally, I can only encourage programmers to look into Scala. It is a fantastic language with great features. It also has an incredible JavaScript story with Scala.js, which is rock-solid. The transition to Scala 3 will be a good time for newcomers to look at the language and its community with a fresh look.

Re: Monads and GATs in Nightly Rust

#150

Post by ebruchez » Sat, Dec 12, 2020, 12:03 AM UTC

the_only_law wrote: post #141

alquemist wrote: post #140

Earlier quoted context omitted.

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

I’ve been interested in Scala recently, although I’ve heard it’s been unfortunately pigeonholed in industrial use. Would you say it’s worth takin up now or wait for Scala 3?

It doesn't matter much in my opinion if you start with Scala 2 now or wait for Scala 3. Scala 3 is 95-99% compatible with Scala 2. There is very little that you would learn in Scala 2, especially as a beginner, that will be truly obsolete when 3 is out (an exception might be symbols, which had very little use anyway). In addition, most existing codebases are in Scala 2 at this time.

(I, and my company, use Scala as a general-purpose language, targeting both the JVM and JavaScript, by the way.)