Hacker News Reader

Comment by _ak | Hacker News Reader

> People that might not have much experience with generics to start with.

Well, I as someone who has professionally worked with C++ for over 5 years and used C++ templates quite a bit, I never ever needed generics in Go even once.

Why do you think is that so? Maybe because I do not force my C++ style of thinking onto what language features Go offers and instead write idiomatic Go code?

(n.b. I did more than just playing around with Go a bit, I wrote serious applications in Go some of which are in production use)

View on HN

I've definitely copy/pasted a stripe-locked concurrent map a couple times to use it for different types. Basically any re-usable container class is the canonical case for generics.

I agree that in most other cases, it turns out you can write a simpler API than Thing<OtherThing<Key, ? extends Value>>, and nobody wants to open the door to that mess. But for containers, they either need to dramatically multiply the number of built-in container classes (slice[] map[] are generic in a way), or create a way to write your own.

I found that doing data processing in Go was a bit cumbersome due to missing generics.

Using a functional programming approach, data processing is easy because you can create new data by taking old data and specifying a transformation process. With Go, I had to manually handle the iteration through the old data's container object.

Not a huge deal, but it felt like I was reinventing the wheel in every goroutine.

> (n.b. I did more than just playing around with Go a bit, I wrote serious applications in Go some of which are in production use)

When you are writing an application, you can know all the types you are going to need, so that you can work around the limitations of Go's typing system. When writing a library, you definitely don't have all the information.

I found that in some languages (Haskell, OCaml, Scala), a common way to write applications is to write the different parts you are going to need as generic libraries and then combine them together. I don't think this is the common way Go programmers do thing.

Go's packages make the practice described above explicit, and many go programs are made up of generic libraries (packages) which define protocols (interfaces) for the types which are passed in, and need know nothing else of those types in advance. So what you describe above as what Go should be like is the normal approach to programming in Go, and many parts of apps (packages) are actually reusable in other apps without modification precisely because of this.

Are you really saying that there's no place for generics? You can't think outside your own anecdotal experience and see that there's a reason generics exist and are used and considered important by many serious engineers?

Are you saying that every one of the many serious engineers who miss generics when writing Go are just not thinking outside the generics box? Or are you willing to admit that, while Go without generics may be a great language for many applications, there clearly are applications where generics are the right language construct for the job?

Reply on news.ycombinator.com