I guess the key questions are: what are the tradeoffs Go makes, and what kind of work is it well suited for?
I think Go's key strengths are syntax simplicity, niceties for large scale codebase (good monorepo support, quick builds, quick startup, easy CLIs, testing and language server built in), and good concurrency constructs.
There are controversial aspects too, like an aversion to annotations and exceptions and anything that hides a plain control flow - as well as a reluctance to evolve the syntax and basic aspects of the language. I like those things personally but that is because I find myself well aligned to Go's philosophy.
I would say that the worst parts of the language would actually be performance, I would not use Go if single threaded performance is critical (and the author Notes this). The GC is not the most efficient either. But I think given that hardware evolution is leaning towards more cores, and scaling up is leaning more towards scaling up containers, Go's choices put it in good stead here.
Go is my favourite language at the moment, has been for a while.
Every tool/language designer makes trade-off choices. I like the ones Golang makes. To me it reeked of experienced folks being in charge. I have grey hairs from all the Bad Things I've had to overcome in software engineering over the decades, in production, with big money at stake, oh and late at night on weekends as a bonus. As I learned about Golang I could tell its designer(s) had too and were trying to address it.
Is it perfect in all ways? Perhaps not. But nothing ever is, so that's a non-interesting criticism in my mind. I know a Good Thing when I see it. One of the few bright spots to getting older.
I think Go's key strengths are syntax simplicity, niceties for large scale codebase (good monorepo support, quick builds, quick startup, easy CLIs, testing and language server built in), and good concurrency constructs.
There are controversial aspects too, like an aversion to annotations and exceptions and anything that hides a plain control flow - as well as a reluctance to evolve the syntax and basic aspects of the language. I like those things personally but that is because I find myself well aligned to Go's philosophy.
I would say that the worst parts of the language would actually be performance, I would not use Go if single threaded performance is critical (and the author Notes this). The GC is not the most efficient either. But I think given that hardware evolution is leaning towards more cores, and scaling up is leaning more towards scaling up containers, Go's choices put it in good stead here.
Go is my favourite language at the moment, has been for a while.