and never mind that Go has had generics for over a year now right? sometimes having a small, stripped down language is better than having a huge bloated monster. I would point to examples, but you know what they are.
1. Generics are bloated and don't allow us to have a single-pass compiler, which we need.
2. You don't need generics because go generate covers all the cases that generics cover (please ignore that this is a second pass).
3. Go has generics!
1. The current proposals for generics are bloated and don't fit properly with our vision for Go.
2. We will do heaps and heaps of work over many years until we get something we like.
3. Go has generics!
Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers.
> 2. We will do heaps and heaps of work over many years until we get something we like.
I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;)
I'd love to hear what meaningful differences you think exist between early proposals for Go generics, and later proposals for Go generics. Or Go generics and generics which had existed in other languages for decades, for that matter.
The result of this silly delay will be felt basically forever, because millions of lines of go were written with error codes, which could have been much-less error-prone option types. I'm not sure it would even be a good idea to start using option types at this point because it would create such inconsistencies in codebases.
> Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers.
Correct! But it was single pass and that was very important because multiple passes were bloat. But multiple passes aren't bloat any more, because now Go has multiple passes and Go doesn't have the bloat of other languages. See how that works?
"The past was alterable. The past never had been altered. Oceania was at war with Eurasia. Oceania had always been at war with Eurasia."
When new C++ standard libraries are written, there is now active, public effort to review what exists in other languages. Finally.
I'm saying that I wanted them...? I didn't say need. I was able to operate without them. I simply _wanted_ them.
Also maybe consider the way you're communicating? I didn't say Go was wrong. I said I didn't enjoy it. I'm allowed to not like things, and I'm allowed to post about them.
_Also_ this concept of "need" is amusing to me. You don't _need_ a garbage collector, or a statically linked binary, or static typing, or IDE support, or a debugger, or, or ,or.
And yet, people _want_ them.
> and never mind that Go has had generics for over a year now right?
Their generics implementation is pretty bad IME. Interfaces lacking type parameters seems pretty untenable to me. I'd rather just not use them.
> sometimes having a small, stripped down language
Of all the things Go is, I wouldn't say its either of these.
But also, if you respond, please try to not be so defensive. You can like Go, that is a valid thing to do.
While Go has had generics for a while now, the vast swath of existing Go code doesn't. The situation is definitely improving but there is still a lot of non-generic legacy cruft.
you know that Go has interfaces right? and I dont just mean the "any" interface. you can write your own interface similar to io.Reader and others, then add types that implement that interface, then no type matching is needed.
> non-generic legacy cruft
AKA normal, fine code. generic code is not some magic pixie dust that makes bad code into good code. plenty of awful bloated slow generic code around as well.
With regards to your second point, there are definitely situations where generics are vastly preferred: type-safe collections being a big one. For instance, the standard library containers (https://pkg.go.dev/container) are still non-generic with no generic versions in the standard library yet. This is the kind of cruft I mean: generic collections can be turned into concrete collections with type safety, but not the other way around. I make no claims about use of generics making your code being absolutely good or bad, but I do make claims that use of generics can make your code less error-prone and more safe.
