3 ms·

If you don't count learning curve (as it's a static "ease of use" cost), Haskell also fits the bill. I've used both Haskell and Go extensively and tbh they are

If you don't count learning curve (as it's a static "ease of use" cost), Haskell also fits the bill. I've used both Haskell and Go extensively and tbh they are more similar than different. They each could afford to absorb the other's strengths.

tome 3y ago
Which Go strengths would you recommend Haskell absorb?
- whateveracct 3y ago
  There's nothing quite like interfaces in Haskell. Or rather, there's a bunch of ways to encode them. But even so, the Go structural typing there is nice. In industry, I have found this means Haskellers (especially beginners who just do that big Haskell book) don't program against interfaces. Which isn't a scalable way to write a large software project and results in a lot of unnecessary coupling, which in turn means compile times don't stay fast. The Go GC is also pretty nice as far as latency-focused ones go. But Haskell already got a latency-oriented GC.
  - dllthomas 3y ago
    > There's nothing quite like interfaces in Haskell. What are the differences you care about between programming against an interface in go and programming against a typeclass in Haskell? From my industrial Haskell experience, programming against a typeclass is natural and common, and the differences that come to mind (no need to declare instances, pervasive ability to fallibly downcast) don't seem to support a claim that Haskellers "don't program against instances" except in the useless sense (that I don't think you intend) that what they program against aren't exactly go interfaces.
    - whateveracct 3y ago
      Hm well there just isn't a simple way to do it? Your equivalent options are - Record of functions - mtl classes - extensible effects - other weird hand-rolled things I work in a normal boring "ReaderT IO" backend-y codebase and it's like pulling teeth to write neat code against interfaces. Doubly so to get less experienced Haskellers to do it. Tbh if we used proper extensible effects (any of them), that would qualify and accomplish what I'm talking about. But even seasoned "simple" Haskellers push back on that for being to "fancy."
      - dllthomas 3y ago
        I think there's a somewhat common failing in Haskell that because a larger vision is possible, smaller solutions get ignored. Extensible effects (or doing tricky things with a monad stack, or...) promises to let you intercept (approximately) everything your function might do. Awesome. That's probably a thing you'd like in go when you say a function accepts an io.Writer. It's not what you get in go, when you say your function accepts an io.Writer. If your code mostly operates in `ReaderT ... IO`, then the simplest typeclass that's equivalent to io.Writer is a typeclass with a function that operates in that same `ReaderT ... IO`.
        whateveracct 3y ago
        The problem with the TC approach is substituting implementations for testing ends up being annoying compared to Go. And substituting multiple different interfaces doesn't compose well (this is essentially the mtl problem). I tend to just record-of-functions everything which is essentially Go interfaces. It does work very well! As functions args usually do :) But those aren't espoused heavily enough by "authorities" so I find less experienced Haskellers don't lean into them or feel comfortable working with them.
        tome 3y ago
        If you like record-of-functions then you might like my new effect library Bluefin, where effects are passed around at the value level. Here's the documentation about how you use record-of-functions: https://hackage.haskell.org/package/bluefin-0.0.4.2/docs/Bluefin-Compound.html#g:6 https://hackage.haskell.org/package/bluefin-0.0.4.2/docs/Blu...

tome 3y ago

Which Go strengths would you recommend Haskell absorb?

whateveracct 3y ago
There's nothing quite like interfaces in Haskell. Or rather, there's a bunch of ways to encode them. But even so, the Go structural typing there is nice. In industry, I have found this means Haskellers (especially beginners who just do that big Haskell book) don't program against interfaces. Which isn't a scalable way to write a large software project and results in a lot of unnecessary coupling, which in turn means compile times don't stay fast. The Go GC is also pretty nice as far as latency-focused ones go. But Haskell already got a latency-oriented GC.
- dllthomas 3y ago
  > There's nothing quite like interfaces in Haskell. What are the differences you care about between programming against an interface in go and programming against a typeclass in Haskell? From my industrial Haskell experience, programming against a typeclass is natural and common, and the differences that come to mind (no need to declare instances, pervasive ability to fallibly downcast) don't seem to support a claim that Haskellers "don't program against instances" except in the useless sense (that I don't think you intend) that what they program against aren't exactly go interfaces.
  - whateveracct 3y ago
    Hm well there just isn't a simple way to do it? Your equivalent options are - Record of functions - mtl classes - extensible effects - other weird hand-rolled things I work in a normal boring "ReaderT IO" backend-y codebase and it's like pulling teeth to write neat code against interfaces. Doubly so to get less experienced Haskellers to do it. Tbh if we used proper extensible effects (any of them), that would qualify and accomplish what I'm talking about. But even seasoned "simple" Haskellers push back on that for being to "fancy."
    - dllthomas 3y ago
      I think there's a somewhat common failing in Haskell that because a larger vision is possible, smaller solutions get ignored. Extensible effects (or doing tricky things with a monad stack, or...) promises to let you intercept (approximately) everything your function might do. Awesome. That's probably a thing you'd like in go when you say a function accepts an io.Writer. It's not what you get in go, when you say your function accepts an io.Writer. If your code mostly operates in `ReaderT ... IO`, then the simplest typeclass that's equivalent to io.Writer is a typeclass with a function that operates in that same `ReaderT ... IO`.
      - whateveracct 3y ago
        The problem with the TC approach is substituting implementations for testing ends up being annoying compared to Go. And substituting multiple different interfaces doesn't compose well (this is essentially the mtl problem). I tend to just record-of-functions everything which is essentially Go interfaces. It does work very well! As functions args usually do :) But those aren't espoused heavily enough by "authorities" so I find less experienced Haskellers don't lean into them or feel comfortable working with them.
        tome 3y ago
        If you like record-of-functions then you might like my new effect library Bluefin, where effects are passed around at the value level. Here's the documentation about how you use record-of-functions: https://hackage.haskell.org/package/bluefin-0.0.4.2/docs/Bluefin-Compound.html#g:6 https://hackage.haskell.org/package/bluefin-0.0.4.2/docs/Blu...