Go is a well designed language, actually
mattjhall.co.uk
mattjhall.co.uk
The article also highlights explicit errors vs. exceptions. Sure, I would agree, but that isn't the only comparison. The best comparison would be via "return ADTs" ala Rust (and they could have been special cased for a return type as Go's designers did for special generic list/maps) which make it possible to disambiguate errors from valid return values without risk of error.
I've only ever dabbled in Golang, but isn't the goal of Go ultimately to make it easy for devs to maintain programs with their hyperfocus on non-breaking changes and backwards compatibility (With previous versions)? It's less about being easy/nice to write the first time, but that you don't have to re-write it again and again with each version change, no?
I'm not saying the OP Article is correct, again, not familiar enough with the language to comment on that, but the whole reason I keep wanting to adopt it (just don't have the time) is everyone I know that uses it always sings its praises for the above features. Seems to be the defining point that drives it's adoption, at least among those I interface with.
There is no inherent correct or not, just opinion. If Go meets your needs, go for it (pun not intended, but still comical lol). I honestly don't think the ideal language exists (and it will look a little different for everyone), but something between Rust and Go with a little bit of OOP would be a sweet spot I think.
I never said nor contested that it did. I was questioning what the design philosophy or general appeal of the language was. If what you believe it is/should be differs from the maintainers themselves, then naturally you're going to likely have friction with how it solves problems or implements features in the first place, as you have divergent goals/philosophies. That doesn't make it a poorly designed language, it makes it the wrong tool (for you) for the job.
To abstract the concept: Nails and Screws are both perfectly valid approaches to fastening things in general, but if you expect a hammer to turn screws effectively, you're gonna have a bad time because your approach/philosophies are misaligned, not because the Hammer is poorly designed. That also doesn't mean there isn't merit in the discussion of the pros and cons of nails and screws and when/how to use them, but that's fundamentally a separate (if adjacent, and still valid) discussion.
EDIT: also, just want to clarify, I don't know Golang, so have no skin in the "is it better/worse/correct". I've long been a supporter of "the best tool for the job is the one you know", with perhaps the only exception to that being Brainfuck[0], unless your intended goal is just to fuck with people lol.
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.
Whose goal are we discussing here? Go's principal design philosophy is to keep the language explicit and straightforward, so you can quickly bring new people on board and maintain code you have never seen before without too much hassle. Even reading through the standard library codebase should not require much more than a basic grasp of the syntax. In that sense, I believe Go is very well designed.
Rust is significantly more difficult, but faster and has more hype.
I would love Go that has been optimized to beat Rust. It's actually a really easy language I wouldn't mind working in. Feels like someone made Python you can complie.v