While there are plenty of annoying things about Golang, I don’t really agree with some of the things.

1. Yes, Golang tells us to bubble up errors. When you have them! Eg, if I have an exceptional situation that should be handled by the function user, then do it. There are however 2 other situations: a) you don’t have errors to bubble up or b) the only possible exceptional outcome is a panic (as required by whatever library / application you are implementing). There is absolutely no requirement to ALWAYS return an error. If you have an error, yes, you should return it, but if if you don’t then … there’s no point.
2. Yes, error handling is tedious. But you don’t HAVE TO always check whether error is nil. You need to do that if you have something to do in that case. There’s always the option to ignore it (although probably that’s not an often used case in a robust application).
3. Goto: what exactly is a modern language in your opinion? Is that something that inherently makes a language “better” than another? Java has goto, php has goto, c++ has it, C# has it, Python has it, ECMAScript has it … the list goes on. Yeah, I wouldn’t use it but I’m not freaking out about others using it. It’s useless and a pain to maintain & debug code with “goto” but if a library I use happens to have it in their code … whatever. Their unit tests pass, it does what it’s supposed to … ok. It’s not the most elegant code but that’s not what I care about it if I don’t have to touch it.
4. Tooling: yeah, it has issues.But …. I’m sorry, how many languages do have a first-hand language server? ALL other languages I worked it are at the mercy of the best third-party IDE that happens to provide this functionality. Also, the VSCode issue is related to the VSCode plugin implementation, not the language server. The language server itself is a tool, how it’s used …. depends on the user.
5. Tracing: tracing is something not related to the language by any means. Sorry, but it’s totally stupid to say that languages should provide that. The languages don’t need to provide it. Tracing itself is a third-party concept and libraries and implementations depend on who is working on the tracing tool. Jaeger, OpenTracing / etc, their people are providing the libraries to use with Go (or other languages). The way you mix pprof in the paragraph shows me that you’re clueless as to what tracing actually means vs profiling vs the concept of metrics (runtime metrics, that is).

For me, the most annoying thing about Go is the error handling and lack of automatic bubbling up. I do like it more than try / catches because it forces being explicit and transparent about what’s happening. Errors don’t exist in a separate plane of existence where you can catch whatever you feel like and let the app crash for whatever else but are part of your flow and you have to deal with them or at least acknowledge them enough to return them.

Yes, it’s tedious and annoying but I don’t find it bad.