This article isn't about whether you like or don't like Go, which has been around for 15 years and whose merits have been debated, like those of literally every programming language, forever. We need to be careful about threads like these, because language war arguments spread like kudzu. Let's just try to talk about what this article is actually talking about.

If you want to see an article about the shortcomings of some language discussed, write one.

> I hate that forgetting to initialize all fields of a struct does not lead to an error, but will just fill in "zero-values" for those fields. This has bitten me many times, and zero-values are almost never the behavior I want.

There's a linter for this you can easily integrate into your build or CI. Personally, having worked at a place with that as a CI rule, I'm the opposite. I felt annoyed having to explicitly set things I purposely didn't set. So I think it living as an optional linter is probably the right place.

> I've found Golang's generics to be confusing and unexpressive.

Same. Also with iterators.

> I hate that forgetting to initialize all fields of a struct does not lead to an error, but will just fill in "zero-values" for those fields. This has bitten me many times, and zero-values are almost never the behavior I want.

If empty values are biting you, you need constructors.

There's definitely multiple ways to go about struct initialization, and Go had firmly chosen one approach. Best practice is to make the zero value of a field "useful", and to write a constructor function if you need it populated with any sort of conditional values.

Contrary to (probably) popular opinion, I find the concurrency model to be relatively poor. You get some cute primitives, but they come with a bunch of footguns. It’s really easy to spawn a green thread with `go <expr>`, which means it is easy to introduce deadlocks or race conditions.

On the other hand, I find the syntax to be relatively simple and non-concurrent code to be straightforward and unsurprising.