Hacker News Reader

Comment by symlock | Hacker News Reader

The only time I find I need generics is when I'm prototyping things and making lots of changes. Node, Ruby, & Python are great for this. In fact, PHP's associative array is really powerful/sloppy since it can be used as a list, hash/dictionary, iterable, or object.

That aside, I don't think I've ever really been bothered by the lack of generics for actual work code.

View on HN

I've been working full time in Go since 2012. I've never had a use for generics.

You've definitely had a use for it. Maps, chan and slices are all generic types. The built-in functions len(), make(), delete(), new(), append(), etc. are also generic. It's just that you can't define your own generic functions and types.

Ok, this is true :)

One of my first Go programs was based on this image resizer: https://github.com/nfnt/resize/blob/master/resize.go#L109

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

After only a quick glance at your code, I'd try to tackle it by wrapping my own interface around the different image types (which you could argue the image standard lib should've already done for you). The interface will define CreateWeights and Resize operations. Each implementing type will consist of a struct with an embedded field of each image type you're handling, and passthrough calls to the underlying function you need. This way, your resizing logic can be implemented in one place.

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.

Image allows you to do this more or less. The problem to be solved here is that if you write the resize logic just once, you are accessing pixels from the image via the interface in a tight loop, and most of the time taken by your image resizer is the overhead of that access.

Interesting, you have a point actually. I would have thought that the performance cost of calling through an interface would be negligible, but I'm wrong about that:

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 :-)

Go 1.11 is already feature freeze and it doesn't seem likely.

> Having said all that, will an implementation of your code with generics be all that much faster?

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.

Pretty sure devirtualization is a whole program optimization in the general case, and I don’t see the Go dev team Pershing that in the next couple of years.

> I don’t see the Go dev team Pershing that in the next couple of years

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

How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me.

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

Go can statically type check hash maps, arrays, and channels. If you want some other container type it must be written with a concrete element type in mind.

Wait, really? The language designers gave themselves (effective) generics and then kicked down the ladder afterwards so that other container implementers couldn't follow? That's hilarious.

Yes. And yes.

Why does it need to be fair? Serious question.

It doesn't, obviously, it's just hypocritical and patronizing.

What do you mean?

    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.

Umm don't? Why are you iterating over unknown types?

Right back atcha.

Try implementing a shared map type where access is protected by a mutex and otherwise works just like Go's builtin map type (which is a generic map type).

Why would I need to re-implement what is already there?

It's honestly hard for me to tell whether you're trolling or not, but all you need to do is compare and contrast the API of the built in map type and sync.Map. One has compile time type safety and the other one doesn't.

If you want a more motivating example, try implementing generic array operations such as reduce, scan, each, reverse etc. Ideally these should be as easy to use as this example:

  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"})

Rob Pike implemented "ivy", an array programming language, in Go but producing something like an array programming package that can be used from Go (sort of like NumPy for Pyhton) can be very messy to use or implement (even with the use of reflect package).

bakul's point is that it's not already implemented--Go's existing map doesn't have finegrained synchronization, and you can't write a generic map that does.

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.

And I've read about many people using Go and wishing for generics from day one.

It's mostly a "day 1" concern, is all.

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

All turing complete languages can be used to do whatever we need, doesn't mean all of them are usefull to keep using in 2018.

Reply on news.ycombinator.com