Generics can be a bit of an eye sore, but go already had reflection & I recently was mucking around bigquery's internals full of `reflect` having to read through that, & it doesn't even get backed by a type checker

`func Index(s interface{}, v interface{}) int` both has to deal with incompatible types, & the function body is going to be anything but simple

(sure, without generics most people wouldn't even write that `func Index`, but ultimately there's plenty of libraries deep in reflect that'd greatly benefit from generics)

I've also been dealing with temporal.io using interface{} everywhere, got to a point where I wrote typed wrappers using generics to have type checking for signals

I was quite upset that they introduced generics. It is slow marching into C++ like look and feel and all the eyesore that it entails.

In C# I feel you needed generics because there was no resizable array without casting from object (the Pareto 80-20 use case) and later async and Task<T> but I don’t think these problems apply to Go so it could have done without it (maybe!). Non userspace generics may be where it is at to ease suffering in places.

As a language design though Elm remains remarkably simple with parametric polymorphism (aka Generics) but it needs other design choices to do so. Elm is the Go of Haskell :-)

what does the ~ do here anyway?

type Something []string

ensure that the underlying type is a slice

Why do you need a tilda for `S ~[]E`, but not for `E comparable`?

Both are type-constraining annotations, so why two syntaxes?

Because when you define a "type Foo []int" you're definig a new type Foo that is not the same type as []int.

So if the type parameter said "[]E" where E is a comparable then "Foo" wouldn't be allowed because Foo is not the same type as "[]int" (for that you'd need a type alias i.e "type Foo = []int". This is by design since it allows you to define new types you don't want to get accidentally used where you don't want them to.

When defining library functions that are truly generic you may want instead to let them be used on the "underlying type". For example, Sort library authors decided that generally you want it to just work on the underlying type and that's why they added ~ in front of the generic type. Otherwise every invocation of Sort you'd need to convert the type e.g. "slices.Sort([]int(myfoo))".

The other type parameter "E comparable" doesn't need the tilde because "comparable" is not an actual type but a type constraint.

A type constraint is an interface that defines the set of permissible type arguments for the respective type parameter and controls the operations supported by values of that type parameter.

You don't need a tilde because any type that implements that constraint will be accepted. Also any type implementing a constraint that embeds that constraint also works

Guessing that E is the element, so is not a slice (or more accurately we don’t care if it is a slice or not!)

It is like S: where S = []E where E: comperable.

I like the way Rust has it a lot more but it is still imperfect and feels arbitrary in ways.

I find myself unsure where to put the templatization parameters and it doesn't feel perfectly symmetrical.

Unsure if impl MyType<T> where T: X

is comperable to impl MyType<T: X> Sometimes it needs impl<T> MyType<T> where T: X

Agreed, the Rust syntax is no golden standard either - but at least it's regular; this one really weirds me out.

They shot themselves in the foot when they forced themselves to add generics based on bogus surveys.

Anything reusable must be generic; that’s a cost of static typing.

Why were the surveys bogus?

Because they disagreed and thus everyone else is wrong, apparently.