That isn't my argument. My argument is that the features chosen are worse on all accounts, and better on either none or almost none, therefore it is poorly designed language.
A few examples:
Multiple return vs. tuple: tuples can regarded as a single entity OR multiple entities
null pointer vs Option type: impossible to have null pointer exceptions
enums vs integers: no need to roll it yourself or have "stringer" code generator
multiple return errors vs result type: prevent accidental use of value when not valid
The list goes on. Go DID do some really nice things on balance: channels, go routines, etc. I think work quite well. I just think starting from a "C mindset" was the wrong foundation in which to build a language at this point in time.
Also, a good example of what you are talking about would be functional vs. imperative programming. THAT is very much in line with your argument, but that isn't what I'm talking about.
A few examples:
Multiple return vs. tuple: tuples can regarded as a single entity OR multiple entities
null pointer vs Option type: impossible to have null pointer exceptions
enums vs integers: no need to roll it yourself or have "stringer" code generator
multiple return errors vs result type: prevent accidental use of value when not valid
The list goes on. Go DID do some really nice things on balance: channels, go routines, etc. I think work quite well. I just think starting from a "C mindset" was the wrong foundation in which to build a language at this point in time.
Also, a good example of what you are talking about would be functional vs. imperative programming. THAT is very much in line with your argument, but that isn't what I'm talking about.