[stickfigure]

I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing?

The answer is: A lot.

[jacques_chester]

People from the post-1.4 era of Java aren't aware how huge code generation was before generics showed up.

And then all that momentum, all the tools, the books, the conference presentations, the code ... all of it. Pop! It died. Because code generation sucks. It is the worst solution to any problem solvable by a type system.

[pjmlp]

Here is a good one, using Eclipse EMF for code generation having as input UML data files generated from Rational Rose.

[BoorishBears]

My favorite example of generics wonkiness was when I needed a channel to wrap an untyped channel to avoid "infecting" every call site for a utility function with untyped pointers.

I thought it was madness, but bringing it up to a very large Golang group and get "nope channels are cheap! That's fine! There's repetition but it's easy to follow"

I've said before, my personal take is use Go, get a feel for the Go mentality, then take it with you to another language.

Go is just too stuck between low level and high level for me personally. I'd rather go under with Rust or over with Kotlin or C#

[praptak]

Go (without generics) is not Java 1.4.

Go's built-in collections are actually generic and Java's generic-less awkwardness was mostly about collections.

[anothernewdude]

I know, right? In Java 1.4 you cast to Object, in Go you cast to interface{}. Totally different.

[praptak]

Most of the casting in Java 1.4 was from collections of Object. In Go the collections are typed, so the casting is confined to some very specialized pieces of code.

[simiones]

The only difference between Go and Java 1.4 in terms of collections is that Go has a generic map type, which Java didn't. Java 1.4 still had generic arrays, just like Go. In fact, it was a little easier to program with generic arrays in Java vs Go (but also less safe) because in Java a subtype[] can be passed to a function which takes a supertype[] (arrays are covariant).

[pjmlp]

Yeah, right because we never been there before.

    class IntList {
       private List objList;

    public add(int elem) {
       objList.add(Integer.of(elem));
    }

   }

Rest is left as exercise for the readers that never used Java generics, or C++ templates.

[sam_lowry_]

I miss Java 1.4. It was small and concise. Java 5 added so much that none knows all of it. Just look at the length of Java Generics FAQ. It's hilarious.

[skinkestek]

I've

- read that from start to end exactly zero times,

- picked up generics in a day or two,

- struggled with advanced types twice, half a day each time

- struggled with type erasure twice, also about half a day each time.

Meanwhile generics often saves me a number of minutes pr hour and makes everything cleaner and easier to read.

I used Java before generics but once it arrived I never looked back and neither did anyone i know.

[karmakaze]

Java before 5 wasn't a language, it was a library and number of jvm implementations. It wasn't until Java 5 that there was a memory model spec that defined how stuff was supposed to work.

[uncledave]

Yeah that's ok until you have 20 million lines of generic ridden crapola pumped out by the lowest bidder. That's the hell I spent a good chunk of the last few years untangling on the C# front. Let's model this correctly! Oh no someone said fuck it, lets just use a bunch of generic data types!

Dictionary<List<Dictionary<string, object>>>, SortedSet<Dictionary<int, string>>>>

Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. I'm not even sure I'm happy with it for abstract data types.

Please can we keep Go special.

[travv0]

> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top.

What does any of that have to do with generics?

[uncledave]

Well the generic programming model tends to favour using light weight abstract data structures instead of well defined types. Those abstractions are by nature leaky so many internal concerns leak out of abstraction boundaries into the caller and give them one hell of a bad time.

[cannabis_sam]

> Those abstractions are by nature leaky

Do you have any examples?

[Smaug123]

`Dictionary<List<Dictionary<string, object>>>, SortedSet<Dictionary<int, string>>>>`

This is not a problem with generics, but with C#'s lack of discriminated unions and/or tiny-types. Except what on earth are you doing with a dictionary whose keys are lists of dictionaries? I am quite sure someone has not modelled their domain correctly there. That's not something you can blame on the existence of generics - I shudder to imagine how much worse it could have been without generics!

[swirepe]

> I shudder to imagine how much worse it could have been without generics!

It probably would have just become a very long String pretty early on. It would have xml in it, but not always, because nobody is that lucky.

[uncledave]

I was exaggerating there I admit, mostly because I can't post some of the hell I've seen without breaking contracts. The worst example I've seen was a completely generic data type specified abstract syntax tree. I spent a couple of weeks rewriting that using concrete types and managed to find and fix tens of trivial bugs caused entirely by the design.

The point is really that it's hard to reason about such things and define if they are appropriate or not for a lot of people. It's a lot of rope to hang yourself with.

[a1369209993]

The sufficiently stupid-but-hard-working programmer can write crap code in any language. The actually-useful question is whether the language gives competent programmers enough rope to build whatever they're trying to build.

[marcus_holmes]

I think the answer for that for Go is "yes"

[uncledave]

We shouldn’t build stuff for the 5%

[marcus_holmes]

Agreed. I'll be banning generics from any code I have control over unless there's a very good reason for it. I saw too much of this crap in C#, and ran from it screaming.

[swirepe]

Say you need a binary heap to hold some customer records, and another binary heap to store some orders. How many times do you implement a binary heap?

[masklinn]

Apparently their answer is “five times”.

[marcus_holmes]

Well, twice at least.

I don't know why you're all so scared of a little repetition ;)