I have very mixed feelings about Go's KISS policy. They did manage to keep a lot of stuff easy and they force dev's to not over complicate their code. But there is a line. Generics aren't that hard to grasp. I get focusing on *fearless concurrency*, but how about *fearless list processing* FFS

Does this help?:
https://eli.thegreenplace.net/2018/...

@Oktokolo I'm guessing Go doesn't have metaprogramming, or it would be really easy to add an ADT layer on top of the current typesystem. But I'm sure there are thornier issues with that, but I'd be interested to see if anyone tried it.

@RememberMe
The blog post i linked seems to be about emulating ADT in GO.

@Oktokolo it kinda maybe could be a solution if you just want a type union, but the precise thing that pushed me over the edge was a project that required a round robin, which requires going for interface{}, and also made me implement the same method multiple times, because I needed to support channels, and lists, and structs with .Next(). Round robin could be done with parameterized type and the function could take any iterator. Neither of those can be done with Go, unless you just want to cast to interface{} and lose any type safety

@VOID404
I never did any GO, because back then, when i evaluated it (by reading the Wikipedia page only *g*), it looked like being dumbed down too much.

Simplicity was a design goal and type inference is certainly more easy when there is less to infer.
But yes, if you only have the most basic static type system possible, you obviously can't comfortably do some stuff that is pretty easy to pull off with languages having a more powerful type system...

You might have chosen the wrong language for your project.
If you really want to have type inference, go for OCaml or F#.
If that isn't a requirement, go for Rust.
If you can live with half to a quarter the speed (chances are, you can), you could also just use Java (the perhaps most boring language ever invented - but it is pretty mature now).