Do you have any recommendations for how to write this code without generics, without sacrificing performance, and without hundreds of lines of duplicated code?

The constructor might be harder to abstract as a single thing since there are variations for each image type... but that's the gist of how I'd tackle it with all of my 10 minutes of experience with your code :-) If this approach is workable, it should end up being clean and testable IMO.

https://github.com/golang/go/issues/20116

The issues linked at the end there are interesting reads, and maybe they'll do something about this by Go 1.11.

Having said all that, will an implementation of your code with generics be all that much faster? Or slower? Of course, those are not answerable questions in practice with today's tools :-)

Likely yes. If generics are implemented via monomorphization, then you can avoid the overhead of virtual calls necessitated by interfaces.

It is possible that the compiler could become smart enough to devirtualize calls through interfaces.

Agreed. But if I didn't mention it, I'm sure someone would have felt obligated to respond with a "well actually..."

I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.

    void do_stuff(Integer[] integers) {
        ....
    }
    
    do_stuff(new String[]{"1", "2", "3"})
    
    Compiler: whoops, you passed an array of strings when the API called for an array of integers.

  x := reduce(func(a, b int)int{return a*b}, []int[1,2,3])
  y := reduce(func(a, b string)string{return a+b}, []string{"a", "b", "c"})

Or, for another example, you can't write a generic LinkedHashMap, which is a weird data structure that allows you to write constant time LRU caches, and which I presume Go doesn't have.

Once you get over it you find that you can do whatever you need.