The end result is, in my humble opinion, a very stable language that is very high performance, and is highly maintainable. It's not perfect. It's not great for every use. Java does some things better. C does some things better, etc... It just fills a niche that was unfilled in an opinionated manor.
I work for a giant enterprise company and the range of programming talent that we have is incredible. I know some people that couldn't code there way out of fizbuzz. Unfortunately, getting these folks onboard to learn the functional abstractions doesn't always sell (especially to the biz folks).
One of Go's biggest strengths is that anyone can pick up the language and be somewhat productive in it after a week.
My 2 cents in the bottomless well of programming language opinions.
This ranks just about at the bottom for any language I care to work with.
"Learning a language" is more than just about being able to write syntactically-correct code. It's about understanding effective design patterns, idioms, the standard library, common pitfalls, writing maintainable code, and so on.
Learning the syntax comprises less than 5% of that effort, and optimizing for that step—particularly at the expense of the other steps—is ill-advised. And in my opinion, go has done precisely this by having tons of sharp edges: nil interface values, race conditions with channels, supposed-"meaningful" zero values, implicit interface implementation, etc. are all sharp edges I've personally run into that have caused bugs in production.
IME, that's basically the case with any language with suitable libraries in the application domain and that doesn't have radically unfamiliar syntax or programming paradigm, so this rings as praise for it being neither especially novel nor deficient in library support for it's target uses.
And then what? They find themselves duplicating the same code again and again because Go doesn’t provide good abstractions to reuse code. Or that they write a ton of code to do what could be achieved in a few lines in a reasonable language.
You learn the language in a week because there is not a lot to learn. Shell scripting is simple to learn as well, but nobody is building anything beyond short scripts using it.
An ideal language should allow the user to be a productive after a short time, but should have have enough power for advanced users as well.
One of the things I hate the most about Go is that source code generation is considered an acceptable solution to many problems. Perhaps I should go back to C — the preprocessor can be used to generate code as well as anything. In fact, the predecessor to C++ was a preprocessor used to generate C code that simulated C++ like behaviour.
This.
>You learn the language in a week because there is not a lot to learn.
Exactly. For example, Brainfuck is even simpler and easier than go. It also produces even worse, unmaintainable, horrible code.
Chalking everything missing from go up to "the designers know what they are doing--every omission was on purpose", ignores the way humans design things. We are really good at post hoc rationalization.
Bob: "Why did you draw the woman in tall grass?"
Alice: "To allow the viewer to engage with the piece by forcing them to use their imagination to visualize the hidden area."
Bob: "Are you sure it's not because you don't like drawing hands and feet?"
Go is far from perfect, I just don't agree that lumping things in a good/bad pile is very insightful.
Engineering is all about making compromises. It's unsurprising that you'll meet everyones use cases that it's not designed for. The article would have provided additional value if it explored alternatives to the bad, and the disadvantages that come with them.
Yes, for using monkey coders more effectively.
>and is highly maintainable
No. Lack of exception handling and generics really hurt maintainability a lot. Not to mention that package management is still full of wrongs.
1. It complicates the compiler. 2. It slows down the compilation. 3. We didn’t think about it in the beginning, and can’t add it now without making non backwards compatible changes. 4. It makes the language harder to learn. 5. We don’t use this feature a lot.
I didn’t invent these reasons — search for why doesn’t golang have <insert-feature> — and you will eventually come across one or the other as a reason mentioned by one of the core members.
1. So what? The whole point of writing a high-level language is to pay the cost of low-level burdens once so that application developers don't have to pay them repeatedly.
3. This makes me treasure even more greatly the Rust core team's forethought when releasing Rust 1.0, in ensuring they hadn't walled themselves into any easily-avoidable corners before stabilizing the language. Such an approach has repeatedly paid dividends.
4. Optimizing for a person's first week of using a language at the expense of their next ten years is borderline indefensible.
5. This last one pretty much boils down the entire problem for me. Go is designed to solve problems Google has that most of us don't. It's also designed to solve them in a way that makes the most sense to Google (e.g., dependency management is irrelevant if you have a monorepo).
The people who care about improving their tools and knowledge will almost certainly end up way more productive than those who don't.
There's a thing called meta-ignorance; you don't know what you don't know, so how can you tell you're really getting stuff done optimally?
Improving tools is complicated and involves a lot of trade offs. It’s not just “omg it doesn’t even have generics what a shit language.”