Is it too late for Go's generics?

[hollowaykeanho (Holloway)]

@acim

And for generics coming so slow to the language, I think the main reason was a resistance of some authors. I think that opinion of the community should drive every open source project including Go, not authors or some “important” (and usually corporate) people

There was some thought about generics in the beginning but was dropped due to the “after effect” should generic be introduced. Folks tends to go overly creative with generics. This broke 3 of the Go’s values:

1. easy to use
2. easy to learn
3. strict static type checking (magic avoidance)

Hence, the decision was not to take generic in early on and introduce a new concept known as interface to solve some generic needs without breaking Go’s values.

The team is proposing to introduce generics in Go 2. You can join the discussion inside these posts:

1. A Proposal for Adding Generics to Go - The Go Programming Language
2. The Next Step for Generics - The Go Programming Language

@acim

I mean shorter, neater, like ? in Rust. Instead of always writing:

if err != nil {
  return err
}

The strict errors checking is adopted from defensive programming practice in critical systems like Linux kernel. The concept is to keep your Go codes as stable and critical as writing a kernel driver, yet removing the crazy high learning curve of creating one.

There are so many ways to reduce the error checking (e.g. package decoupling with vertical approach).

---

My opinion ahead

Given the fact that Go actually solve some severe pain points in software ecosystem such as:

1. Managing dependencies for final output binary (e.g. AppImage like output)
2. Compilation approach (codes friendly to human; output binary friendly to CPU)
3. Standardizes codes for fast learning (easy to read, learn, reference, and peer review)
4. Customer distribution (it’s so easy to package and distribute 1 binary app)
5. Friendliness to current modern platforms (looking at Git, Gitlab, Gittea, and Github)

Go would not die off due to the absent of generics by the fact that something as large and critical as Linux kernel did not use generics. I strongly believe Rob Pike and his founding team did consider that into their thought process and have their strong reasons not to include in. For me, generic is optional (good to have). No harm introducing if it does not sacrifice Go’s existing values and performances.

That’s why Go branded themselves “opinionated” language in the first place.