IMO, the thing that makes go good, from an enterprise point of view, is that you can take a team of mediocre coders who have never used it before, and deliver working code quickly. It might be ugly, it might be dumb, but it'll get the job done, and will generally be easier to maintain than python or ruby in the long run and with good performance.
I think a few things contribute to that:
1) Relatively few language primitives -- it takes like a day to learn 90% of the keywords you'll be using day to day.
2) Transparency -- it's easy to look at any code base, and track down all the relevant code, even without an ide. Compared to a language like ruby, there's not a lot of 'magic' happening.
3) Conciseness. Unlike a lot of statically typed languages -- go code isn't verbose. It's statically typed, but the inference works well enough that you're very rarely having to use type hints all over the place -- Java has started to be more like this, but back when go started, it was a breath of fresh air.
4) Kubernetes. If you want to build on top of k8s, go is pretty much the only game in town. It just makes everything eaaier. Other languages have k8s support, but any language other than go will have more friction.
5) Go channels and concurrency -- I actually don't think this is that important, but knowing that it's available if you have that kind of performance demand is nice.
> Conciseness [...] you're very rarely having to use type hints all over the place
This hasn't been my experience. When I tried porting some Python code to Go, I found it wouldn't compile without lots of type casts (mostly between different integer sizes and signedness).
My experience moving to Go from languages like Python and Ruby required a significant mind shift. I couldn't port my solution - I had to revisit the problem from the perspective of a Go programmer.
I think that is because you’re coming from a weak typed language to a strong typed one. I’d from the outset you have to have your types match you wouldn’t end up with so many types.
It really shouldn't need any type annotations. A Hindley-Milner type system would have been more flexible and require no type annotations (as well as far less interface {} and unsafe casts), and still support everything Go has. The language as a whole seems to just commit all of the mistakes of C, except with garbage collection.
I think a few things contribute to that:
1) Relatively few language primitives -- it takes like a day to learn 90% of the keywords you'll be using day to day.
2) Transparency -- it's easy to look at any code base, and track down all the relevant code, even without an ide. Compared to a language like ruby, there's not a lot of 'magic' happening.
3) Conciseness. Unlike a lot of statically typed languages -- go code isn't verbose. It's statically typed, but the inference works well enough that you're very rarely having to use type hints all over the place -- Java has started to be more like this, but back when go started, it was a breath of fresh air.
4) Kubernetes. If you want to build on top of k8s, go is pretty much the only game in town. It just makes everything eaaier. Other languages have k8s support, but any language other than go will have more friction.
5) Go channels and concurrency -- I actually don't think this is that important, but knowing that it's available if you have that kind of performance demand is nice.