Hacker News Reader

Comment by dcposch | Hacker News Reader

I think this illustrates one reason why Go doesn't have generics.

Generics add a lot of complexity to a language. There are two main ways to implement them that I know of--the Java style, with type erasure, and the C++ style, where you essentially generate code for each instantiation--both have significant drawbacks. Either way, it complicates the syntax, complicates the type checker, complicates all the tooling around the language (IDE support, debugger, profiler, linter).

OTOH, if you don't have generics, you either just use concrete types or you essentially do type erasure yourself, explicitly (eg with interface{} in Go or void* in C). It costs you a few casts and maybe some code duplication.

In return, you get a simple language, where it's easier to write robust tooling.

I think erring on the side of simplicity and avoiding generics altogether is more than worth it.

View on HN

Java generics aren't the best example of how to implement generics. C# or Rust are better in this regard, which both have reified generics. Generics do solve a practical problem identified decades ago, ad-hoc code generation or void* aren't the solution. I don't think the omission of generics has any bearing on how easy writing tooling is.

You can always omit them, if you're prepared to deal with code duplication, but I think you're downplaying its significance: it is not just "maybe some" code duplication, nor is it a "a few casts". It's sometimes a deep, murky swamp you're forced to trudge in, and it's not pleasant.

To be fair, generics are only needed for as long as you insist on static typing. Languages with dynamic typing where types are checked at runtime do not need generics.

And generics is complicated topic. I am all for static typing, especially for large code bases. But sometimes when I venture too far out in generic land I find myself wondering if it is worth it? A well-designed library that uses generics prudently can be a bliss to use. But the implementation code can get near-unreadable.

> There are two main ways to implement them that I know of--the Java style, with type erasure, and the C++ style, where you essentially generate code for each instantiation--both have significant drawbacks.

There is also C#/.NET style, which maintains the type system aspect as Java and the run-time reification and efficiency of C++.

> OTOH, if you don't have generics, you either just use concrete types or you essentially do type erasure yourself, explicitly (eg with interface{} in Go or void* in C). It costs you a few casts and maybe some code duplication.

Exactly like Java pre-generics, I remember the JDK 1.0.2/1.1 days also.

> I think erring on the side of simplicity and avoiding generics altogether is more than worth it.

They don't need it day one (neither Java or C# had it in 1.0), but they'll eventually need to add something for generic programming.

Reply on news.ycombinator.com