> If anybody wants to learn go, ignore everything about how easy it is to learn. Because it's extremely deceptive. Take time to actually read through a lot of the important underlying concepts like how slices work.

What is your standard for "simple" if learning how to use slices is complex? Go slices are just windows into contiguous blocks of memory. There are pitfalls--if you have two juxtaposed slices backed by the same contiguous block of memory, growing the former will write over the latter, but you quickly learn that you should virtually never be appending to slices that don't have sole ownership over their backing memory. Probably the worst part is that there aren't higher-level functions for prepending or deleting an item, so you have to build them yourself with append, copy, etc primitives (but even this has the nice property of exposing the cost of these operations, e.g., deleting from the middle of a slice is expensive and your average Pythonista probably doesn't understand this).

> Ignore comments about how go is simple to write. There's a fair amount of bad go code and people break rules all the time. From official sdks to standard libs. Go can be extremely difficult to both write and read.

This hasn't been my experience.

> implicit interfaces

I love structural sub typing ("implicit interfaces")--I can define an interface for a third party type which in a nominally subtyped language would require wrapping the third party type in a new type whose only purpose is to express the suitability of a particular interface. And for no real gain at all (or at least I've never felt myself wanting nominal subtyping; perhaps it's a difference in workflow).

> judicious abuse of interface{}

Putting aside the contradiction of "judicious abuse", I don't think `interface{}` is very common in Go, and where it exists it's usually appropriate, for example, JSON de/serialization or Printf. `interface{}` is used very sparingly in Go, and considering that people build real, successful applications in languages like Python and JavaScript where everything is an `interface{}`, Go's use isn't that bad.

> Writing go can be difficult because of a lack of some language constructs that leave you unsure how to proceed.

I particularly disagree here as well. There's often one way to do something in Go, and I've had very good luck by Googling "How to do x in Go?".

> OTOH, things like criticisms about it's error handling are overblown. At best it's a mild nuisance, and more often than not, a good thing that makes error handling explicit and clear.

Agree here. Maybe I'm an unusually fast typer, but the majority of criticisms seem to be about how long it takes people to type out the `if err != nil {` boilerplate.

Personally my biggest criticism of Go is the lack of sum types (IMO I would much prefer sum types to generics). There are a lot of cases where it would be nice to express OR constraints. There are workarounds in Go--for example, using an interface with a private method that the variants must implement, but that's a lot of error-prone boilerplate and it tends to result in unnecessary allocations and dynamic dispatch (as opposed to a switch statement).

Another criticism is that the compiler doesn't optimize as aggressively as I would like, including that many abstractions are runtime abstractions that could be compile-time abstractions (specifically, Go doesn't have semantics for distinguishing between a run- and compile-time abstractions and the compiler pretty much always assumes that all abstractions are runtime abstractions.

> If you can, use goland. I use vscode and it's... not pretty. Almost every single thread I've seen on reddit recommends goland. My experience with vscode has been very unpleasant, particularly with go plus.

I've been pretty happy with vim. I haven't used goland. vscode became noticeably worse around the time that modules landed, and IMO never fully recovered. `gopls` has also been disappointing. Go's editor story used to be best in class in general, but it seems to have gone downhill. Still, I think it's well above average (especially with respect to the dynamically typed languages).