> The small one is the lack of IDE support. You don't need to write an IDE. You just need to have sufficient integration into Jetbrains IDEs (at a minimum).

Jetbrains wrote their own Go IDE, goland. The rest of us use an LSP client that talks to gopls. I have used that for about a year and it does everything that I would want an IDE to do; accurate context-sensitive completion, an easy way to peek at signatures and documentation, jump to definition, accurate renames, import organization/cleaning, etc. I am continually surprised at how good a job it does when I'm 8 nested protos deep and it can still complete struct keys and values (i.e. you can type "&Foo{ B" and it will complete it to "&Foo{ Bar: &Bar{}").

> The first big problem--and it still is a problem--is the dependency management, in that there wasn't a solution to this out of the gate (unlike, say, Rust and Crate). Like I was shocked the first time I saw import 'github.com/some_random_user/...' I dare you to go look at any even moderately sized Go project and unravel the levels of dependencies (including repeated dependencies, which may or may not impact binary size, I'm not sure).

I am pretty happy with go's approach to dependency management in the Go module era. You can tell the Internet "a little duplication is better than a little dependency," which Go does, but they will do it anyway. I like that I have tools that can just vendor all my dependencies (mostly so that CI builds can be completely stateless and free from network communication), and that every module I use is declared in go.mod file that the toolchain itself keeps tidy and accurate. The mechanics of an upgrade are a breeze -- find the module and update the version number next to it. If I want to edit some module I depend on, I can just use gohack and it checks out the source code in a convenient location and edits go.mod to make go pick up that version of the code instead of the Internet's version. And, you can at least figure out why you have a certain dependency with "go mod why". Finally, I love that "go doc xxx.Foo" is aware of what modules my module uses, so that I always get the right symbol. I would kill for "typescript doc xxx" or "clang doc yyy". (Seems like other people prefer 80 browser tabs with random websites loaded to do the same thing. I like my command-line, or at least some IDE integration.)

I have used other approaches to dependency management and they haven't made me as happy as Go's. npm is slow and fills my entire screen with garbage, only to eventually inform me that "module A depends on module B which depends on module C which has a SEVERE SECURITY VULNERABILITY!!!!!!! and there's nothing you can do except whine on Github!" I like Bazel's WORKSPACE approach, allowing me to specify the exact sha256 of the compiler toolchain I want to use, and every version of every transitive dependency. Somehow I feel like nobody is that serious about dependency provenance, though, and they invent a lot of clever workarounds to avoid maintaining that file. But at least you can be correct and in control if you want to. (With go projects, the biggest problem I've had is keeping protoc, protoc-gen-go, and the Go proto library in sync. Go doesn't handle non-Go things, and that really sucks. You have manually manage that stuff, and people mess it up. Or use Bazel, which I've tried and came to the conclusion that nobody else has ever done.)

So all in all, I think Go's IDE support and dependency management meet my needs. I dare say I think they're great! All of this stuff is relatively recent, though, so there are probably a lot of people stuck with their code in ~/go/src/github.com/me/my-app that manually run "goimports" from time to time. That sucks. But there are better tools available!