And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want.

With Haskell the process for me has repeatedly been: "okay I'm going to follow this tutorial...okay I need to install it...okay cabal is complaining about versions or exceptions....okay let's try stack....okay this example needs some includes...okay I don't have quite the right ver..."

Then 4 hours later I remember that I can't deploy any of this to my servers, give up, and go back to waiting for someone to make a sane "get started" bundle for an FP language.

Haskell's package management might exist - but it sucks, and I'll take go get/govendor over pretty much anything currently out there.

This is a fundamental misunderstanding of how go dependencies work.

Dependencies are simply package names. It just happens that names are actually meaningful and tell you where you, the developer can get the package. Using vendoring and/or Godep/glide, you then strictly version and manage your dependencies. `go build` doesn't just run `git clone` or something.

These import paths aren't really URLs. They're local import paths, where Go's out-of-box tooling additionally allows for far simpler package install/update flows when one chooses to have these local paths replicate remote-repo URL paths. One doesn't have to, but it essentially turns "any CVS" into what would be Hackage/Stackage in the Haskell world. Sure, no curation, but `go get repo-url` has its charms too for quick iterations and experimentations. Vendoring is also entirely trivial (have a fork, update it from the original when it seems sensible to do so, undo when it turns out not to be). And guess what, with that you have "reproducable builds".

I like the hackage/stackage model, too. As long as there is always some folks tending to those repos. But, the `go get` model is a fine workflow too.