Hacker News Reader

Comment by vsnf | Hacker News Reader

Without being too flippant, that is Go’s history in a nutshell.

Do you know how Go handled collection classes in the past without generics?

Where they just not typesafe, like a Java List<Object>?

The native collections were generic already. They were a special case. Custom collections were either hand-rolled for a specific type, unsafe as in your example, or generated per type using a tool.

Built-in map and vector types are generic.

E.g. map[int]*MyType

Using interface{} is quite common in the absence of sum types (or inheritance with base class). I guess interface{} is like Object in Java.

It's not worse than Python or other dynamic languages that many people are fine with. The run-time panics when asserting that a type is something it's not.

E.g. https://go.dev/play/p/c4hx8HSiB8I

That said, no, it's not optimal and could be better (IMHO).

>Built-in map and vector types are generic.

I understand what people mean by this, but it's not true for any reasonable notion of 'generic'. Pre-generics Go no more has generic maps than C has generic arrays. Yes, you can declare a map or a slice of values of any given type, but you can't write a generic function that abstracts over these types. That's what is usually meant by 'generics'.

Sure but it's worth emphasizing that Go language designers gave these built-in collections the exorbitant privilege of being parameterized by a type and declaring that any new type created by a mere programmer has to be monomorphic.

> the exorbitant privilege of being parameterized by a type

This is how built in collection types work in pretty much all statically typed languages. For example, here is an array of ints in C:

    int foo[] = { 1, 2, 3 };

We wouldn't usually say that C has 'generic arrays'.

> any new type created by a mere programmer has to be monomorphic.

Collections in (pre-Generics) Go are monomorphic. []foo and []bar are as different as foo and bar. That is why, for example, the first argument of sort.Slice has type 'any' (https://cs.opensource.google/go/go/+/go1.18.2:src/sort/slice...)

Yes, you are correct. I had not thought about it deeply. There are restrictions for what can be used as a map keys according to some built-in equality rules. And of course the types used as map keys and values are concrete types so you can't pass a map to generic functions pre generics.

But was the built-in append function generic pre generics? I think it is?

There were three or four generic types and a few generic functions (close, len, cap, make, append, delete, x[y], <-, ==, for-range, select), they just didn’t let normal users define new ones without forking the compiler.

I don’t think it makes sense to see built in operations on arrays and maps as generic functions. If 'len' was some kind of built-in generic function then you'd expect to be able to monomorphize it like this:

    func intLen(foo []int, lenfunc func ([]int) int) int {
      return lenfunc(foo)
    }

    intLen([]int{1,2,3}, len)

There is just no sense in which Go 1.17 has “generic types” and (e.g.) C doesn’t. All statically typed languages allow you to define arrays of different types and use the same operators on these arrays. Go adds a handful of additional built in types (slices, maps, channels).

The idea that some completely ordinary language features somehow constitute a crippled version of generics that has been 'turned off' for regular users seems to be an artefact of certain communities' hobbyhorsing over Go's (former) lack of generics.

As a thing that takes an argument and returns a result, I would have expected len to be an ordinary function. That I don’t is only because I remember the disappointing state of the language at launch.

The usual pattern was to use an empty interface (`var collection []interface{}`).

Reply on news.ycombinator.com