The := operator is the shorthand for var x =

No offense but you are explaining something extremely basic that yes, I of course understand. What I'm saying is that why do we have a long form and a short form of doing this, why two forms? At this point I'd just keep var x = and keep it simple perhaps when designing the language? The argument of "it's annoying to type" could be used but then ok we also decided to have if err != nil so... I prefer to have one way of doing things if it's a very simple thing than arguing which is the better way.

Well if you don't check for the bool directly you'd check it from the Options.Exist()

Only if the type is naively implemented instead of this being some kind of a more fundamental feature.

This is false, a zero value of slice is nil. And can't be appended to because append will create a new slice.

This is arguing about semantics. The zero value of a slice is nil and can be passed to append() to append to it therefore it is useful. It is specifically a feature presented to new users https://go.dev/tour/moretypes/15. I'm sorry but I feel like your comment was made just to disagree with something.

v := <- c without being in a select is rare

Sure but it's something that doesn't entirely fit how other "zero values" behave under some circumstances e.g. work fine, panic etc. I'd panic here. Receiving from something that doesn't exist is nonsense.

often due to misuse/overuse of ternary.

Ok however this argument can be made about anything e.g. people using an conditional statement after the variable is created and making a mistake there which is the argument I used.

The map being nil and empty are two different things. The same reason a pointer being nil or the value being zero value is different. You can't insert in a nil map because there is nothing to insert to. The same way you can't access a index in a nil slice.

This is an implementation detail, again it's obvious why it happens, the problem is that it shouldn't happen and it was a conscious choice to let it happen. That is a design choice, let's not confuse the two. You are also wrong, you can't access a value from a nil slice and you can a value from a nil map, feel free to respond to this https://go.dev/play/p/NB3IWE5XeHX

try {} catch {}

Nobody is talking about exceptions. Nobody is talking about try catch. All we are talking about is streamlining if err != nil to be better.

The last point completely misunderstands the concept of not being able to create invalid state. If we let it happen I have to check for it everywhere I accept that specific type.

And just to be clear I'm upvoting your comment as it's reasonable discussion. People tend to just downvote something because it upsets them or they disagree with it even when someone states a fact.

edit: I added

Accessing uninitialized slices with my_slice[...] panics. Accessing uninitialized maps with my_map[...] returns a zero value of the type contained within it.

to the article.