i’ve been really digging lwn lately

This generic dust up kinda killed my interest in go. I was writing a fairly large project in go and I was really missing generics as I was coming from C#. I used a code generator to build the days structures I cared about to work around lack of generics.

Go has some nice features, go routines, life memory consumption, but it just seems to lack ergonomics. I haven’t really payed much attention in recent years as .net core took away one of go’s large pluses for me (cross platform). And the speed advantages differences seen to have even out.

I just can’t believe it’s taking “the smartest people in the world” (and I man that sincerely, some very smart people that I have huge respect for work on this language) this long to figure it out.

That why the language architect supreme is Anders Hejlsberg.

I used Turbo Pascal in college and have used C# and typescript extensively.

Andres seems o be very pragmatic about problem solving and actually shipping language features users want vs hemming and hawing for years and years.

rsc on the “three approaches” seems like they ignored a lot of prior art; C# is a mainstream language that has actual reified generics for quite a while, to say nothing of what the FP community has.

Because Go doesn’t support operator overloading or define operators in terms of methods, there’s no way to use interface constraints to specify that a type must support the < operator (as an example). In the proposal, this is done using a new feature called “type lists”, an example of which is shown below:

// Ordered is a type constraint that matches any ordered type.
// An ordered type is one that supports the <, <=, >, and >= operators.
type Ordered interface {
    type int, int8, int16, int32, int64,
        uint, uint8, uint16, uint32, uint64, uintptr,
        float32, float64,
        string
}

In practice, a constraints package would probably be added to the standard library which pre-defined common constraints like Ordered. Type lists allow developers to write generic functions that use built-in operators:

// Smallest returns the smallest element in a slice of "Ordered" values.
func Smallest(type T Ordered)(s []T) T {
    r := s[0]
    for _, v := range s[1:] {
        if v < r { // works due to the "Ordered" constraint
            r = v
        }
    }
    return r
}

Hmm, to me this looks like the Smallest function would only accept the built-in types with a less-than operator <. Don’t you lose a whole lot of usefulness if you’re not allowed to write your own Ordered type which can be used with a Smallest function?

Will be interesting whether they stick with (type T) – I’d assume so, but this further decreases Go’s readability.

I think the alternatives don’t have a lot of chances here:

• <> – Bad choice, also NIH.
• [] – But but fAmiLiArItY, also hard to pull off given the existing misuse of [] in Go.

Nice to see though that Phil Wadler could talk some sense in them.

Here are my cliff notes from the last time I read the current design proposal:

Although methods of a generic type may use the type’s parameters, methods may not themselves have additional type parameters. Where it would be useful to add type arguments to a method, people will have to write a suitably parameterized top-level function.

This is not a fundamental restriction but it complicates the language specification and the implementation.

Preferring the convenience of a dozen compiler writers over solving users’ pains sounds like a bad idea.

Especially considering that if it were added later, it would be a breaking change for every user who wants to clean up his code and make use of this feature.

we introduce a new predeclared type constraint: comparable

Not sure why this one written in lower case. (Skipping comment on poor naming.)

It’s also kinda inconsistent with the approach to comparisons earlier on, which don’t get their special builtin constraint.

Both ==/!= and the </<=/… earlier could have been dealt with less special casing by defining a suitable constraint for each with the corresponding methods, and – if desired – restricting the set of types that are allowed to satisfy them.

The rule is that if a type contraint has a single type parameter, and it is used in a function’s type parameter list without an explicit type argument, then the type argument is the type parameter being constrained.

Unnecessary.

Therefore, we propose that the language change so that func(x(T)) now means a single parameter of type x(T). This will potentially break some existing programs, but the fix will be to simply run gofmt.

Good.

Values of type parameters are not boxed

Good.

It’s impossible for non-generic code to refer to generic code without instantiating it, so there is no reflection information for uninstantiated generic types or functions.

Good.

No covariance or contravariance of function parameters.

Will be interesting to see how this works out in practice.

No operator methods. You can write a generic container that is compile-time type-safe, but you can only access it with ordinary methods, not with syntax like c[k].

Makes sense – this kind of syntax sugar has been a mistake in most languages.

And, of course, there is no way to write a constraint to support either return nil or return 0.

One could use a Zero constraint that is automatically implemented (and cannot be implemented manually) for all types.

Lots of Irritating Silly Parentheses

Agreed. Go is already looking … less-than-structured with its ident Type syntax and having () double for types only makes it worse. If the language didn’t add special builtin [] operators, they could have gone with [] for generics, which is generally the optimal design in bracket-based languages.

The design has no way to express convertability between two different type parameters.

Sounds like a job for a function from T1 to T2.

We would need an untyped boolean type for operations such as ==(T) untyped bool.

This is unclear to me.

… untyped constants …

Seems like they have caused nothing but trouble – was probably a mistake to add them in the first place.

Map keys must be comparable, so key has the predeclared constraint comparable.

This doesn’t seem to resolve the issues around floating point numbers, but they existed like this before. Could have been an opportunity to do better.

Thanks for reading, and yes, it’s normal that the comment gets flagged almost immediately.