Except that these kind of experiments contributed to Java generics, being made available 3 years before Go 1.0 was given a green light.
Which is why Go had already a good example to learn from on how not to do language design.
Which is why Go had already a good example to learn from on how not to do language design.
As much as I like generics, Go's popularity is a success: programmers have spoken, and they value other things more than generics.
Hindsight is 20/20, and even this isn't a commitment to introduce generics in Go.
If I had to write a list of “tools I would have preferred to have”:
1. Perfect serialization libraries - Serde is the gold standard here, and IIRC the macro system from Rust is as important a part of it as the traits part.
2. Mutability of types in shared caches - to build efficient controller patterns you need fast and efficient caches - an immutable type that protects against mutation would have saved a lot of ugly mutation testing code
3. Client library definitions shared across types - we could have reduced a fair amount of boilerplate with generics, although most bugs are in the serialization part these days as types evolve
But most of these are dwarfed by the need to scale reviewer time across hundreds of people submitting PRs that change fundamentals of the code. The simplicity of Go and ability to review stupid, obvious, absolutely critical code is the reason why I love it.
Having a strong way to reduce cleverness has been a godsend. It doesn’t mean cleverness is bad, or I don’t want more tools in Go. But I appreciate that aspect of Go in a way that others may not.
Edit: I have been watching kube-rs mature, but to get the same level of scale and performance we’d have to reproduce the shared index informers and that’s a lot of drudge work to get right. That’s one place where someone motivated could really help Rust become a first place way to extend Kubernetes, which would be exciting.
Don't mind.
It’s just ugly because that’s how it evolved after a community formed and that’s what real evolved software looks like. :)
Both its main influences, Oberon-2 and Limbo had zero traction on the market, and Limbo not only is quite close to Go, it had an whole OS full of the Plan 9 ideas to come along, yet it failed on the market.
Lack of generics has already been publicly acknowldge as problem.
> In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language.
https://blog.golang.org/why-generics
And yes, there is no place on the 21st century for typed languages without generics, we already have enough of them from the previous century already.
CLU and ML, the first languages to support genericity are from the mid-70's, they are older than C++ and contemporary to C.
Why isn't Dart seeing the same type of success?
Original Go team did not suffer from this.
That's from people who complain because they want Golang to be like Java
It can also feel sometimes like a dynamic language which has attracted people from ruby, python, JS, etc... communities.
You say there's no place for it in the 21st century, yet it already has a place and it doesn't really need generics to continue living.
I agree Go cannot offer similar things due to a weaker type system.
I willingly code Go day-to-day. I miss Java streams, and sometimes the codebase is slightly worse due to the lack of Java streams (or equivalent).
I accept a weaker language because I spend less time debating the Right Way to do things (Go is too inexpressive to support a Right Way), and because I can widen my hiring pool from those that know Java, to those that any language, knowing that they can easily pick up Go.
Not saying it is a bad language, but it really helps that Go had Google's blessing.
How exactly is Google "shoving it down our throats"?
Or perhaps Google has many hearts and no one knows exactly how many or where they are at any given point in time :-)
Second what Sun choose to implement was a smaller subset and not that close to Featherweight Java/pizza compiler. It was only generics, not first class functions at the time, nor algebraic types/pattern matching.