[staticint]

I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly.

The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with number types, for example. You leave the burden on the programmer to ensure their generalized function is applied only to types which it is intended to be used with.

While that is less than ideal, I cannot see that increasing developer time by a significant margin.

[15155]

> It is not like someone is going to manually write out identical functions twenty times for each type they want to support.

I'll stop you right there. Have you seen a modern Go codebase?

They most certainly duplicate the simplest of functions, resort to `go generate`, or use reflection.

[staticint]

I am afraid I am not entirely sure of what you are trying to get across here. Your mere mention of go generate indicates to me that you do understand my point about computers being able to free the programmer from doing the drudgery of implementing the same generalized function twenty times. And since you are familiar with go generate, I expect you also realize there are seemingly endless tools that exist to solve this specific problem.

I _think_ what you are trying to say is that templates in Go are less convenient than in some other languages. That is a completely fair assertion. But the idea of having to type `go generate` occasionally adding significant man hours to a project seems a little far fetched. You could even:

  alias go='go generate && go'

I completely understand the appeal of templates/generics being a first-class language feature. Not even the Go authors themselves discount the usefulness. I don't understand why the lack of them is adding so many more man-hours to your projects? The overhead of working around the lack of them should not be that significant, even if less pleasant.