[glmdev]

I think Go's generics are reasonable, but not quite powerful enough to scale.

It's all well and good to generalize basic containers and functions (good, in fact), but I wish the language was better at inferring types.

I'm sure this is something that will improve with time, but a bit after generics were released, I tried to build a type-safe language evaluator in Go using generics and found them lacking the kind of type-narrowing necessary for fully-generic architecture.

Short write-up of my conundrum on SO, if anyone is interested: https://stackoverflow.com/questions/71955121/how-to-type-swi...

TypeScript has me spoiled. :)

[nemothekid]

I haven't looked into Go's actual implementation but isn't this kind of downcasted better suited for interfaces. Your code, as is, wouldn't translate to something like Rust which uses monomorphization; you are doing a runtime "inspection" of the types. This looks more in the domain of duck-typing than something that generics handles.

[SekstiNi]

Here's a writeup exploring this very topic, and showing how Go's generics will currently give worse performance than just using an interface.

https://planetscale.com/blog/generics-can-make-your-go-code-...

[bbkane]

Yes, I was trying to get it to infer the types for some code I was writing as well (a generic funcopt for two different types) and it couldn't - made me specify the type manually.

[socialdemocrat]

I think I am glad that kind of stuff doesn’t work, because that was pretty hard to read. Go is trying to keep things simple.

If you want a sophisticated type system with a language they complied to native code then use Swift or Rust.

I personally think it is good to have some choice in complexity level and that at least one language, Go, tries to carve out a niche in simplicity.

I am only barely convinced that generics was the right choice for Go.

[dividedbyzero]

IME complexity is mostly a feature of intention and business logic and will usually creep in all the same, it just manifests as tons and tons of for loop spaghetti, duplication and code generation. You may not have to actually learn any "hard" language features, but instead you get a large amount of moving parts that can't be abstracted away cleanly and that you need to mentally track. I've just ported a relatively complex bit of business logic from Go to Scala and while the result is definitely not as "simple" in terms of language features used, it's a lot less code in a structure that I can actually keep in my head a lot more easily than reams upon reams of low-level imperative details that are kept consistent only by the implementer's self-discipline. Forcing code to be easily digestible by limiting the language feature set doesn't seem to work too well outside of a relatively limited space of straightforward applications.