|
|
|
|
|
|
by nu11ptr
520 days ago
|
|
|
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. |
|
|
That is in fact what I'm trying to get you to understand. You're arguing a different point than what was proposed. What you propose is entirely valid, but is missing the forest for the trees.
Your goals for what a language should be/do and what Golangs Goals for a language should are not equivalent. You admit it yourself in part here:
> I just think starting from a "C mindset" was the wrong foundation in which to build a language at this point in time.
It's why I've entirely bypassed your attempts to discuss the nuance.
You may disagree with the "C mindset" and other design principles, but ignoring the context of why decisions were made is not productive discourse for determining whether something is designed well or not, which again, was your original and very firmly stated assertion up top.
There is more to a language than it's abstractions and syntax/syntactical sugar and paradigm. Learning curve, intuitiveness, familiarity, conventions, devex (creating and maintaining) and usecase and who is intended/expected to use it are all important as well, and inform why certain decisions are made.
In other words, Thinking people need to move on from the C mindset is an entirely valid argument to make. It has no bearing on whether C or C-inspired languages are designed well, as it entirely ignores what those designs were intended to achieve and who they were trying to cater to.
TL;DR: How well something caters to your goals isn't the same discussion of how well it's designed to cater to someone elses/it's own stated goals. So yes, you feel it's badly designed because you refuse to acknowledge it's not trying to cater you, and that it has no duty to.