[1] Such a benefit doesn't matter in a containerized world.
[1] Such a benefit doesn't matter in a containerized world.
Go is used for the tooling for deploying this containerized world.
Let's take a look at some infra/ops tools written in Go:
* Docker itself - should run on baremetal (duh)
* Nomad, a container scheduler - should run on baremetal
* Kubernetes, a container scheduler - should run on baremetal
* Consul, service discovery - should run on baremetal
* Etcd, service discovery - should run on baremetal
When you actually work in ops, setting up the container conveyer belt by putting Go static binaries on Linux hosts - so that developers can go ahead, containerized their applications, and deploy them - is a big improvement over the Python days of yore.
It does have a nifty concurrency system.
I do like that most Go code is idiomatic because the language really kind of restricts you to writing it a certain way.
I wish it had a less verbose way of dealing with errors... some kind of function composition along with better formalization of Go's multi-return (e.g. Try, Either types) would be nice... of course without generics that is likely tricky.
I'm happy I can read and write it, but for my personal work I'll be sticking with some mix of Python and Java/Kotlin.
I think in 2019 I'm going to really give Rust a shot.