> I'm sorry but nearly all of them are along the lines of "I came from language X and in X we did it this way, but Go's syntax is different". That's not a footgun.

You're right, I meant to link that in reference to how Go can be difficult to learn despite how it simple it seems. Not sure how I a sentence.

The overview of that site explains its purpose/necessity quite well. Some things are footguns, many are just confusing time-wasters. Nevertheless, they are frustrating and hamper the learning process.

> Nevertheless, they are frustrating and hamper the learning process

But that is the learning process. What else is there to learn in a language if the syntax doesn't count? They're all Turing complete and all of them can do everything. All we need to do is learn the exact magic words.

I never said otherwise. My point is that Go is far harder to learn than they're implying. It certainly can't be learned over the weekend — well, maybe it can be, but the code you end up writing will Inevitably be full of resources leaks, panics, nil pointer issues, improperly handled errors, etc. You may be able to put together some basic logic, but you are far from understanding the language.

I don't think it's honest to parade Go as a language that's the paragon of simplicity that's easy to learn when that's simply not true. I also don't think it's honest for people to argue that addressing any of Go's countless warts would somehow make the language more complex or harder to learn.

I agree that it's very unlikely for someone to Go in a week and start writing flawless code.

But Go's real strength is in its readability, not writability. I think it's very much possible to learn Go in a week, then read clean Go code like the standard library and understand exactly what's going on. At least that's my interpretation of what it means for a new grad to be productive in Go in less than a week. Nobody is expecting someone new to write production-grade libraries with intricate concurrency bits in their first week, but they're already productive if they can read and understand it.

As a rule of thumb we spend 10x more time reading code than we do writing it (code reviews, debugging, refactors). So why not optimise for it?

As a fairly experienced engineer, I have to say that reading go code is what gives me the most pause. I find the amount of visual noise and lack of useful abstractions makes it so that to be efficient at reading code, I have to trust that the loop or the error handling code is doing what I expect. The issue with go is that the primitive operations are written `for i := 0; i < 10; i++` instead of `map` and `x, err := foo(); if err != nil {...}; bar(x)` instead of `y := bar(foo()?)`, which requires either presuming, or spending the mental energy ensuring the primitive was written correctly every time it is used.

I generally do the second, because doing the first is extremely tiring when reviewing code, but I dislike it immensely.

I don’t have too much an opinion on either side here, but as a developer who works full time in Go (and has for >6 years) all these things exist in Go.

Uncaught exceptions -> panics, like what this nil catcher is aiming to solve

Places far away -> easy goroutine creation with no origin tracking makes errors appear sometimes very far away from source

Use after free -> close after close

FactoryFactoryFactories -> loads of BuilderFunc.WithSomething

Lots of other pains I could add that are genuinely novel to Go also, but funny that for everything you mentioned my head went “yep, just called X”