> Errors on unused variables are annoying as well. > Not everything that should be done needs to be done right here right now. Hence the ability to suppress i

> Errors on unused variables are annoying as well. > Not everything that should be done needs to be done right here right now. Hence the ability to suppress it with `_ = unused_var`! The point is that it's explicit. You have an out — it's not the pretty out you like but that's the whole point. It's unpretty and annoying in order to force you to think twice. Every design decision is Go has been the result of consensus of multiple people who've been bitten many times by the issue the design is addressing (in case that wasn't obvious). Have a read of issues, drafts and proposals on Go issue tracker to get a feel of what it takes to get something in. > Imagine trying to learn a musical instrument and being berated at every time you play the wrong note. That’s not a way to teach; it’s a way of asserting dominance. WTF! > No sum types with exhaustive pattern matching > I tried a search for a code pattern often seen due to the lack of exhaustive pattern-matching in Go > That’s 38.7k hits in the source code across GitHub etc. as of Apr 29 2022. Great. Write it up in an issue and with such an overwhelming evidence, it's a good candidate to make it to the language in the future. Why isn't it there to begin with? See above. > No overloading for common operations For many, that's a huge positive. When reading the code, it's much easier to reason about the extent of side effects for-loops have. > Yes, one can use map[T]struct{}, but that feels needlessly cumbersome. Now you're just trying too hard. > Go has a convention that doc comments must begin with the name of the entity they describe. Rob Pike, and docs, and blog posts talk about why this is the convention. Read up. > Limited markup support in godoc Thank goodness. You have a rust/swift programmer (from dozens of mentions of each language) trying to beat Go into a shape they're familiar with and not enjoying it. That's not the right way to learn and use a language, just as you don't go learning Japanese, expecting it follow the grammar rules of English. And especially in case of Go, bits are added pragmatically and after long and careful deliberation, not as a race to have as many features, bells and whistle as every other hot-lang out there. A experience report that keeps mentioned language X and Y as a benchmark for what language Z should be like, only tells how language Z differs, not whether it's better, worse, etc. So labeling the differences positive and negative is of little value in this case.