[KirinDave]

I mean, I think Go generally holds that it cannot be nearly as complex as other languages with type aliases. It's a curious restriction for a language with pointers to take, I know... But I suppose that the way go implemented vendoring introduces some strange outcomes here.

[mixedCase]

Go pointers have no pointer arithmetic and are clearer than guessing what's being passed by value/reference and something like C#'s out/ref.

With or without pointers, as a programmer you'll have to understand passing by value and passing by reference. Go just makes it explicit in a language construct.

[KirinDave]

I am confused why C# came up or why you'd call it's in/out parameters "guessing."

Your second paragraph seems to invalidate your first?

[mixedCase]

What I said is that the (ugly) C# solution is one alternative to "guessing" (or rather, knowing the implicit details of the language).

Go pointers make references and values quite visible to the programmer, because in the real world it's not actually convenient to hide those details.

[KirinDave]

I do not think in/out parameters are ugly. I find them to be a lot more elegant than the cudgel that is pointers.

Go's pointers are certainly BETTER than C++ pointers, but I don't think that immediately makes it better. BOTH languages have value and reference semantics, and BOTH languages use syntax to dogwhistle that to programmers.