I've had a bit of exposure to it (writing some HTTPS audit tool using Go\Crypto & some third party library - from CloudFlare) and I agree mostly, what struck me as a guy with 10+ years of PHP background is the speed at which I got the first versions of my tool out, really impressive. Definitely keen to may be transition to it if I can find stuff to do to better my knowledge of it.
Have you found a decent way to deal with the dependency management, I found it a bit clunky...
Govendor + vendored dependencies in repo
Godep is also fine, no real issues with dependencies here.
I've ran into some pretty gnarly issues vendoring both helm and Kubernetes in the same project. Your luck really depends on the dependency graph for the stuff you are vendoring.
Longer version:
- I've been writing almost exclusively Go code as my full time job for the last 2.5 years
- I've coded in Python and PHP full time before - each at least as long as Go (and neither of them was my first or second programming language)
- I was able to pick up Go significantly faster than either of the two (0 to push to production in less than 2 weeks)
- I'm at least as productive (measured in problems solved / features delivered in unit of time) in Go as I was in Python
- standard library is great and very often replaces the need for 3rd party libraries (performant, production ready HTTP server for example) and makes dependencies "flatter"
- deployment of a single static binary vs virtualenv hell (pre-docker) is bliss
- it's actually very fast for free - you'll start worrying about (and start spending time on) performance way later
Negatives: - dependency management is bad
From web app/api perspective:
- just using http server from standard library gives you concurency go is known for - each request is a goroutine which is cheap: minimal overhead
- you can delay worring about performance (at least from the app part - not db obviously) more. It's easier to throw hardware at the problem when you need 1/10 of the hardware
- deployment is easy - single static binary that just works
- multiple CPU cores are simply used: you don't have to run multiple processes (node)
- http server in standard library is production ready: no need to stick it behind something else
- you get all that without sacrificing productivity