5 ms·

I've been starting up using Go as "fast Python" for web services / REST APIs. The patterns encouraged by Go development are actually how I preferred to write Py

I've been starting up using Go as "fast Python" for web services / REST APIs. The patterns encouraged by Go development are actually how I preferred to write Python in the first place, which is to say 1. largely avoiding huge tightly-coupled frameworks like Django 2. writing a little more boilerplate with the payoff of making code a lot clearer to reason about without having to step through tons of layers of overly-dynamic libraries I think Go will really start to eat up the backend web services space in the coming years.

jdmg94 7y ago
not with google's reputation behind it...
whateveracct 7y ago
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 :)
jrwr 7y ago
its still why I love PHP, its super easy to hack together a website in under a hour does something stupid simple, and I'm not even talking about using any frameworks or libs, just pure PHP that does X simple thing and does it well
echelon 7y ago
> I've been starting up using Go as "fast Python" for web services / REST APIs. I've been using Rust as "fast Python". It's super expressive and you can get things done quick and dirty if you want. IMO, the one advantage Go has over Rust is the fast compile time. Rust's type system makes it worth the wait (which isn't even really that bad).
- skrtskrt 7y ago
  That’s my next destination! I just felt Go was an easier first step away from interpreted languages.
  - lostmsu 7y ago
    Is it any easier than C# or Java? O-o

jdmg94 7y ago

not with google's reputation behind it...

whateveracct 7y ago

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

jrwr 7y ago

its still why I love PHP, its super easy to hack together a website in under a hour does something stupid simple, and I'm not even talking about using any frameworks or libs, just pure PHP that does X simple thing and does it well

echelon 7y ago

> I've been starting up using Go as "fast Python" for web services / REST APIs. I've been using Rust as "fast Python". It's super expressive and you can get things done quick and dirty if you want. IMO, the one advantage Go has over Rust is the fast compile time. Rust's type system makes it worth the wait (which isn't even really that bad).

skrtskrt 7y ago
That’s my next destination! I just felt Go was an easier first step away from interpreted languages.
- lostmsu 7y ago
  Is it any easier than C# or Java? O-o