Don't forget the fact that it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on. Even generics in Go were a heated debate because they make the language more complex. All in all Go was created by geniuses and it shows.
> it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on
Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a single HTTP handler actually does.
A certain number of developers will be able to complicate any language or mechanism you provide them, it's how they feel important. I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else, except they aren't, so they build extremely complex systems, because they think that's what smart people do. They are interestingly often extremely well versed in their tool of choice.
You are mistaken if you think that the abundant use of interfaces etc. is motivated by anything along those lines. As someone who often puts basically everything behind an interface and abstracts everything in sight, it's not because it has anything to do with being smart, quite the opposite; it's the only way I can keep any meaningful portion of the code in my head. Give me a 5000-line straightforward / unabstracted implementation of something and I'll struggle, but give me thingDoer.doThing(), behind an interface so I don't even have to know how to construct one, and I'll be happy and able to focus on the task at hand. This applies even if I'm the one who wrote the ThingDoer interface and its implementation(s), and even if it was only 30 minutes ago.
> They are interestingly often extremely well versed in their tool of choice.
This has become a red flag to me; over attachment to a tool or paradigm means that they're driven by and making decisions using feelings, not through actual analysis.
Very well put.
"They are interestingly often extremely well versed in their tool of choice."
People who are, shall I say unwise, but very good at what they do is one of the most annoying things wrong with the world.
> I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else
I've also seen the opposite where people revolve their entire identity around not being the person and they swing too far the other direction and end up being a masochist and doing things the dumb way because they're too afraid of coming across like a snob.
No one is safe from bad developers. I've seen go SDKs for paid products that were clearly written by people with only a vague idea what the target language offers. I have to assume such libraries were hammered until the compiler just accepted what was given
There is this odd thing where the actual syntax and features of a language are (at least partly) independent of how it ends up being used. A culture forms around the language (that the authors have limited influence over). Java does not have to be used the way most people tend to (factoryfactoryimplfactory!). And some go projects (notably at least early k8s are go in Java style).
A lot of what people comment on is less the language and more the dominant culture.
I disagree because I've seen some readable Go codebases but I wholly agree that bad Go codebases are a nightmare.
Try comparing the Honk source (clear, direct, modulo the unangst wacky names for everything) with GotoSocial (unreadable, interfaces and abstractions out the wazoo).
(Yes, I know GTS supports the MastoAPI but that doesn't force the hellish onion-layer abomination they've created.)
That's very strong language. Go was created by some smart people that have completely ignored programming language developments that happened after the 70's.
Go made a lot of odd choices from a language design perspective. It's pretty much "C, but with better types and a garbage collector!"
It certainly has its usages and does some nice things. But at the same time, the obsession with compile speed has, IMO, has been a detriment to the language as a whole. We see this in the way generics ultimately entered go after years of causing problems by not existing from the get-go.
I'd say that the hands-down improvement over C is simplified threading and proper utf8 support. The utf8 alone (because of the notion of rune) is a good reason to use golang over C or C++.
Yeah, but advanced languages are also a problem for long-term maintainability.
Remember, Go was developed at Google - jokingly, while waiting for stuff to compile. They deal with tens of millions of lines of C++ written by thousands of engineers with varying skill levels and career paths. The advancedness of C++ did not reduce the compile times or readability of the code. At those scales you can't rely on being familiar with a particular section of code; you need to be able to drop in anywhere and know what's going on, without having to learn which subset of the advanced language they used for that particular feature.
Advanced languages can compile quickly - it depends on the feature set chosen. For example, do-notation is an advanced feature not found in most languages, but it compiles quickly as it is syntactic sugar. Operator overload, on the other hand, might require a solver and thus compile slower. It's not a particularly advanced feature, however. Binary optimization passes do not make the language any more advanced (on the user side), but will slow down compilation. Advanced design and compile-times are pretty orthogonal.
As for maintainability, it's not clear to me that reams of imperative code is easier to maintain than something terse and declarative. In fact, probably the opposite.
It depends on what libraries you use and how you structure your code. Yes, you can create inheritance hell within Java code. But you can also use composition (what Go uses) within Java and create sane code bases.
Inheritance is a foot gun that got overused in the '90s and early 2000s. But people have learned mostly to avoid it unless really needed.
I remember looking through this insane taxonomy of abstractions of a button to find the code for when it got pressed. There weren’t that many buttons and they had no special requirements. Just trying not to find some real actual code that does the thing. I work on much bigger projects now with much less abstraction and my quality of life is much higher
Go was first and foremost created to serve the needs of Google. Kudos to them for releasing, open sourcing and backing it but it was designed to serve their needs. It’s not a criticism but it explains why it’s quirky in many areas. The authors being genius is not as important as the goals and intentions.
They may be geniuses, but some - mainly Ken Thompson - are also luddites, eschewing things like syntax highlighting. I mean they have a point - if you need colors to make your code readable, your code isn't readable.
But yeah, I love how everything is well thought out and they just say "no" a lot.
