As a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of synt

As a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of syntactic noise, fast compile times, right-sized standard library, sufficient control over memory without having to worry about memory safety). If I kept a similar counter for the past 3 years, it would be at least five per day. Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. That's constant. Every time I use atomic.Value (often) or sync.Pool (less often) or sync.Map (almost never because I end up rolling my own stupid map+mutex). 90% of the time I want to say a pointer can't be null. 100% of the time I want to handle optional JSON or SQL fields. Fairly often, like > 30% of the time, when wrapping serdes or DTO conversions around data streams. I don't believe the level of generics required to support these use cases requires compromising the other goals of Go. The deficiency should have been obvious as soon as they introduced `sync.Map`.