10 ms·

In this vein, I've been focused on finding/creating tooling at the same level of abstraction as Go (net/http, database/sql + sqlx, etc) but in Haskell. So it en

In this vein, I've been focused on finding/creating tooling at the same level of abstraction as Go (net/http, database/sql + sqlx, etc) but in Haskell. So it ends up being a bit more ergonomic for a variety of reasons. scotty (-> net/http), aeson (-> encoding/json), and postgresql-simple (-> database/sql) are pretty close, although aeson & postgresql-simple need some tooling on top to get them on par w/Go struct tag reflection imo. I still love to use more advanced Haskell libraries, but there's something to be said for stitching together functions in IO with simple types.

creyes 7y ago
I think you're right that the level of abstraction is the same but the language ergonomics are drastically different. Go was designed so that anyone coming out of school could read/understand/write it very quickly. I'm not a Go expert and I can reason about code pretty well and even write some stuff. That's absolutely NOT true of Haskell. It's a much more nuanced language and while I'm sure it's great once you learn it, the learning curve is steep. Because of that I think it's much easier to hire Go developers than Haskell developers too
- whateveracct 7y ago
  Optimizing for the beginner isn't necessarily a good thing though. While that is true of Go, the trade-off is for even somewhat complex systems, Go starts to falter compared to Haskell. Local reasoning of Haskell scales nicely with complexity, at the cost of learning it. There are economics at play here too. If your turnover rate is high (1-2 years even), the company can get the short end of the stick, while the employees get to pay the fixed cost of learning Haskell on company time. My experience though is FP novices can get to doing new-hire-level tasks in Haskell within a couple weeks of mentorship. I've seen 0-FP-experience interns dive into applicative functor code in _Scala_ and have no trouble so long as we sat down and explained things from first principles (and motivated the value of the abstractions we use.) I have actually found the opposite to be true for hiring. Every place I've worked has had more Haskell applicants than they knew what to do with. Largely because Haskell can make your company uniquely desirable in a sea of options. The only time a Haskell company I worked at "had trouble hiring" was when we turned away countless Haskell-experienced developers due to the sole veto of a VPE over and over again. After months of observation, it was clear that he was actually starving the team of Haskell resources so he could build momentum to move away from it (despite the team being fine with the language)
  - apta 7y ago
    > Go starts to falter compared to Haskell. Not just Haskell, but any mature OO language/runtime as well (JVM, .NET). The fact remains that golang is popular because of Google's name behind it. While its concurrency model is somewhat decent, its warts get in the way very quickly for any non-trivial project.
    - hactually 7y ago
      what do you define as non-trivial? I'm aware of a number of companies and projects that are definitely more than non-trivial. I think Java/C# are verbose and ineffectual languages and people are seeking alternatives that make a lot more sense and deliver more power and speed.
whateveracct 7y ago
Here's a bunch of things that Haskell has better solutions for that I run into in Go all the time: * ResourceT is composable defer * Streaming libraries (I use conduit due to familiarity) mean I don't have to write wonky loops to process data in constant memory * ExceptT & Either is more composable error handling * Parametric Polymorphism all around, but especially when it comes to concurrency (no need to hand-roll goroutine rube goldberg machines!) and collections (same but for hand-rolled loops) * Async exceptions mean you can't have runaway threads without added implementation burden (I'm looking at you select + Context!) * Sum types for a variety of use-cases :)

creyes 7y ago

I think you're right that the level of abstraction is the same but the language ergonomics are drastically different. Go was designed so that anyone coming out of school could read/understand/write it very quickly. I'm not a Go expert and I can reason about code pretty well and even write some stuff. That's absolutely NOT true of Haskell. It's a much more nuanced language and while I'm sure it's great once you learn it, the learning curve is steep. Because of that I think it's much easier to hire Go developers than Haskell developers too

whateveracct 7y ago
Optimizing for the beginner isn't necessarily a good thing though. While that is true of Go, the trade-off is for even somewhat complex systems, Go starts to falter compared to Haskell. Local reasoning of Haskell scales nicely with complexity, at the cost of learning it. There are economics at play here too. If your turnover rate is high (1-2 years even), the company can get the short end of the stick, while the employees get to pay the fixed cost of learning Haskell on company time. My experience though is FP novices can get to doing new-hire-level tasks in Haskell within a couple weeks of mentorship. I've seen 0-FP-experience interns dive into applicative functor code in _Scala_ and have no trouble so long as we sat down and explained things from first principles (and motivated the value of the abstractions we use.) I have actually found the opposite to be true for hiring. Every place I've worked has had more Haskell applicants than they knew what to do with. Largely because Haskell can make your company uniquely desirable in a sea of options. The only time a Haskell company I worked at "had trouble hiring" was when we turned away countless Haskell-experienced developers due to the sole veto of a VPE over and over again. After months of observation, it was clear that he was actually starving the team of Haskell resources so he could build momentum to move away from it (despite the team being fine with the language)
- apta 7y ago
  > Go starts to falter compared to Haskell. Not just Haskell, but any mature OO language/runtime as well (JVM, .NET). The fact remains that golang is popular because of Google's name behind it. While its concurrency model is somewhat decent, its warts get in the way very quickly for any non-trivial project.
  - hactually 7y ago
    what do you define as non-trivial? I'm aware of a number of companies and projects that are definitely more than non-trivial. I think Java/C# are verbose and ineffectual languages and people are seeking alternatives that make a lot more sense and deliver more power and speed.

whateveracct 7y ago

Here's a bunch of things that Haskell has better solutions for that I run into in Go all the time: * ResourceT is composable defer * Streaming libraries (I use conduit due to familiarity) mean I don't have to write wonky loops to process data in constant memory * ExceptT & Either is more composable error handling * Parametric Polymorphism all around, but especially when it comes to concurrency (no need to hand-roll goroutine rube goldberg machines!) and collections (same but for hand-rolled loops) * Async exceptions mean you can't have runaway threads without added implementation burden (I'm looking at you select + Context!) * Sum types for a variety of use-cases :)