The appeal of Go is that it has just the bare minimum feature set to be useful for modern backend engineering. It's a language that you can completely fit within your head within a few months of using it, as opposed to certain languages like C++ (or say C# to a lesser but increasing extent) that most will never know completely even after decades of working with it. It's basically the RISC of programming languages.
And if I had to guess, it doesn't have enums so that it can remain flexible when serializing/deserializing enum-like types over the wire. Imagine you can't parse an incoming payload containing an enum field because your service is one version older than the one that extended the enum type (or the enum type is defined in a package dep... you get the idea). Enums are actually a terrible idea now that I think about it.
> The appeal of Go is that it has just the bare minimum feature set to be useful for modern backend engineering. It's a language that you can completely fit within your head within a few months of
To me, golang symbolizes the shift of philosophy of Google as a company. It changed from "it's a smart nerd company for smart nerd people" to "golang will allow us to hire cheaper devs because golang will prevent them from making mistakes". I mean, this makes sense from business perspective, I won't deny this fact, but it's the programming equivalent of Ferrari making a SUV: tremendously profitable, but sad to see.
BTW
> golang doesn't support overloading because overloading is bad. Having said that, it's 'go', not 'golang', like the verb 'go', which already has a thousand meanings depending on the context
Disagree completely. I think by and large Go is a work of genius, the product of lifetimes of deep insight on programming languages and software development.
There are some "design-by-committee" weirdnesses, but if you squint a bit it's perfect.
The law of large numbers says that, the larger the organization, the closer to average the employees will be. Google had no chance of maintaining "a smart nerd company for smart nerd people" at the scale it grew to be.
> The appeal of Go is that it has just the bare minimum feature set to be useful for modern backend engineering
I know that many people love Go, and I respect that, but I was never able to grasp its appeal (despite my two-year stint as a professional Go programmer). To me, the philosophy of Go seems to prioritize simplicity in the language at the cost of making software written in it more complex. Writing in Go often felt like a constant exercise in haveing to reinvent even the simplest things.
I suspect you've only seen poorly written Go, which is actually quite pervasive. The most common sign of it is the overuse of interfaces. You basically shouldn't define your own interface unless you need to export functionality. Interfaces are not a tool for organizing your code. Go is meant to be written in a very linear and naïve way, and it turns out quite good when you just do that.
I prefer the testing libraries that do monkey-patching and consider mock implementations of interfaces to be an antipattern in Go, especially if it's the only reason for putting an interface between the calling code and a type.
In Go you can jump from your IDE into the http server implementation in 3 clicks, and you can read the code easily, it's vastly different from other modern languages that have layers of un-necessary abstraction.
I worked in Java / C# with tons of interfaces all over the place, getter / setter in every files.
Within the 90 seconds of thought while writing a Hacker News post, he's discovered that decades of language design and type theory were actually a terrible idea now that he thinks about it.
One of the tools I work on in my spare time is a Poker calculator that uses enums extensively for things like suits and hand strengths (flush, full house, etc.). This program doesn't connect to the internet in any way. But I hadn't considered that someone might come along and force me to serialize these poker hands and send them over the wire and change the number of suits and ranks in a deck of cards so that it creates incompatibilities. I guess I should go back and rewrite my code to remove those enums, since that's going to be a problem.
Go actually has enums in the basic way that you're thinking of them, but they're just constants of a custom type based on int.
So you'd define `type Suit int` and have constants of type Suit that are `const DIAMONDS Suit = 0` ... `const SPADES Suit = 3`.
Go just doesn't have first-class enums with cardinality less than an int, like Java would. Which means you could have a Suit type variable with a value of 4 or 9000, because Suit serializes/deserializes as an int, not some custom string representation as in other languages.
For a language to be useful for modern backend engineering, I'd expect it to at least have proper enums and union types with pattern matching. Let alone features like structured concurrency, advanced observability, records, good error handling, etc.
The constant gotchas in golang indicate that it does not fit in people's heads within a few months.
And if I had to guess, it doesn't have enums so that it can remain flexible when serializing/deserializing enum-like types over the wire. Imagine you can't parse an incoming payload containing an enum field because your service is one version older than the one that extended the enum type (or the enum type is defined in a package dep... you get the idea). Enums are actually a terrible idea now that I think about it.