It's always bizarre when someone on a discussion forum defers to the writings of someone else. If that someone else wanted to have a discussion, they could do so themselves. But since I'm in a silly mood, I'll play along with your silliness:
From the GNU C manual: "An enumeration type represents a limited set of integer values, each with a name."
Which is exactly what Go provides. Which isn't surprising as it is identical to C in that regard.
Enums suck, period. That's why many modern languages don't offer enums at all, providing sum types instead, which more accurately model what most people are trying to use enumerations for. It is an antiquated pattern that may have served a useful purpose in the early days of computing, but we've learned a thing or two about programming since then.
Well, at least you've come around to recognizing that Go does have enums, even if you needed someone else's words to say it. After all, Go enums can't suck if it doesn't have them. But, of course, Go purposefully tries to be antiquated. That's kind of its whole deal. Naturally it is going to have enums to really drive home the antiquatedness.
If Go had added generics from the start, it's very unlikely that the implementation would be as solid as the current one. I think their conservative approach paid off in this case.
I think you're making my case for me here :) Yes, Go reached maturity faster than Rust (despite its first release occurring later – one of the many benefits of simplicity), and the lack of generics doesn't seem to have hurt its adoption. Another victory for Worse is Better.
> Go reached maturity faster than Rust (despite its first release occurring later – one of the many benefits of simplicity)
Rust started as a research language by a PL guy working on his free time, he wasn't even suspecting his work would end up becoming mainstream. Rust only became somewhat serious several years after Go was released and used in production at Google. If you count Graydon's first Rust publication, you may as well count all of plan9 as part of Go's history! (Or how about using Go's repository first commit[0] if we're being facetious)
Also, implementing proper generics should have been straightforward from the start for Go, given that it was already mainstream in multiple programming languages back then (including the super mainstream Java and C#, with different approach). But Go was made by people who believe syntax highlighting is useless, of course they decided against generics…
It would have been straightforward to copy an existing approach to generics (though I suspect that this is a usage of the word ‘straightforward’ that has currency only among people who’ve never written a compiler), but I’m glad they waited and did something better that had a proper theoretical foundation. If they’d naively added generic types to Go from the beginning, you can bet there would have been all kinds of interesting unintended consequences, as there were in the case of Java.
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier.
If you take a step back here, the Go team acknowledged their biases and lack of in-depth knowledge in the domain, consulted with domain experts, and eventually settled on exactly the kind of generics system that you apparently approve of.
Could they have done this earlier, in principle? Sure. But at what cost? What other balls would have been dropped? I think they were absolutely right to focus on aspects of the language design and tooling that they were confident about. Go is all the better for it. It's the polar opposite of a language designed to appeal to programming language enthusiasts; and well, that shows in the reactions.
By all means use Rust. I use Rust sometimes too, and it has its advantages over Go. Personally, I find generics in Go an occasional convenience and missed them only a little before 1.18.
Then you don't have to create a new language. Golang was explicitly designed for not very experienced people to learn it and become productive quickly, even in big groups/teams with high attrition; that is: Google. And I think they reached their goal.
If Golang starts to add more and more features, it will lose this advantage and become just "yet another language". But worse: because of how was Golang designed, it will then end up worse than, say, Java. In other words, it will lose its advantages without really gaining much.
The problem is that this is probably inevitable, because the people that start as inexperienced developers with Golang will grow and become unsatisfied with the language features. Some more, some less, but that will be the general trend. And I think they are already vocal enough to push the things you listed.
Instead, I think it would be better for everyone if those people would instead switch programming languages and leave Go as is. Otherwise the cycle will repeat with the next Golang...
Think that is a misconception, that Go was just designed for inexperienced people. Rather it was designed to be easier to use than C++, from which the motivation to have something different came.
That a language is easier to use, doesn't mean it can't add features. The features are relative to how it helps the language be more useful and solve issues that users are having, so keeps it easier to use. Languages are always going to have pressure to adapt.
I didn't say that it was designed only for inexperienced people. But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly.
And the more features a language has and that a codebase uses, the longer it takes for someone to learn it and be productive (unless they can transfer knowledge from similar concepts of other languages of course).
But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly.
Do you have a citation for that? As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones.
I do indeed have a citation for that by Rob Pike - and no matter how downvoted I am, it stays a fact:
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
> Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.
> As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones.
No, it's not a second order effect. Or rather: both what you say (a language "as clean and straightforward as C") as well as a language for devs early in their career (i.e. inexperienced) are both second order effects from the underlying reason that the language is targeted at developers at google.
It definitely wasn't due to lack of previous tested technologies with field experience since the 1970's.