5 ms·

It's been three years since I started writing Go professionally and I think adding generics to Go is one of the worst ideas I've ever encountered. I love Haskel

It's been three years since I started writing Go professionally and I think adding generics to Go is one of the worst ideas I've ever encountered. I love Haskell, and I much prefer hindley-milner type systems, type classes, and real sum types. I see the value of generics where appropriate. Golang, however, made the tradeoff to sacrifice anything near that level of abstraction, and it's success might largely be attributed to the approach-ability of the language as a result of that tradeoff. Retrofitting generics onto the language will be at it's best a death sentence for the principles and ergonomics of the language. One thing that has become clear to me as I have spent time with Erlang, Haskell, and Go is that it's much better to use the right tool for the job rather than trying to manipulate a tool to fit every use case, which is precisely what adding generics is all about.

oppositelock 8y ago
I've also been writing a lot of Go professionally for a long time, and I've used every part of the language extensively, and I disagree. There are many times I remember where I've had to implement some sort of application specific data structure that's not built into the language, and generics would have made it a lot nicer. I made it generic by using interfaces, but then you have the problem of throwing away type safety, so to preserve it, you need wrappers which cast. It's not a given that adding generics would ruin the ergonomics of the language. I hope that whatever form generics do take in the end, that they remain simple. If I see template meta-programming in Go of the sort that occurs in C++, I think I'll scream, but that meta programming was to work around limitations in C++'s typing system which Go doesn't share.
- ilovecaching 8y ago
  What do you mean by nicer? I would imagine that something that is application specific would not require generics. Interfaces do not throw away type safety if they are used correctly. They are also better suited for the consumer of the type rather than the definer. One of your problems might be that you are prematurely abstracting your interfaces for your callers.
  - deleted 8y ago
    [deleted]
  - singingboyo 8y ago
    interface {} definitely does throw away type safety, however, and is reasonably necessary for some library use cases. Is it possible that you're coming at this from an angle of building applications for specific purposes, while oppositelock is building more libraries? My experience (admittedly limited) is that application writing in Go is nice, but as soon as I try to build a library for use in several similar (but not quite identical) cases, maintaining type safety can quickly become a hassle.
  - oppositelock 8y ago
    Let's say that I have an interface called Sortable, so I design my data structure to accept and return Sortables. I can insert any Sortable into it. When I get the Sortable in a future lookup, I don't know its type. I have to use reflection to error check. With generics, I could create a generic data structure which is strongly typed - what goes in is what comes out. Right now, the way to ensure that is to wrap your data structure in something that converts those Sortables into specific classes, say PatientRecords. Interfaces are wonderful, I like working in Go more than any other language so far, but they have their limitations.
lumost 8y ago
I loved go from 1.3 onwards, and it still has a special place in my heart. But ultimately a failed attempt at writing a heavy numeric/scientific app in Go soured me on the lack of generics. the overhead of needing to re-implement functions in order to avoid casts was way to much to bear in one app, and projects such as gonum suffer either due to an over-reliance on interface or the requirement to constantly re-implement functions to deal with the change in type signature between int, float, and their associated sizes.
- ilovecaching 8y ago
  This is an example of why I say use the right tool for the right job. Go is not the best language for scientific computing. Depending on the math involved you should likely be looking at Fortran or Python, which will most likely use Fortran or C under the hood. Go is best suited for small application or microservices, or as glue code for services.

oppositelock 8y ago

I've also been writing a lot of Go professionally for a long time, and I've used every part of the language extensively, and I disagree. There are many times I remember where I've had to implement some sort of application specific data structure that's not built into the language, and generics would have made it a lot nicer. I made it generic by using interfaces, but then you have the problem of throwing away type safety, so to preserve it, you need wrappers which cast. It's not a given that adding generics would ruin the ergonomics of the language. I hope that whatever form generics do take in the end, that they remain simple. If I see template meta-programming in Go of the sort that occurs in C++, I think I'll scream, but that meta programming was to work around limitations in C++'s typing system which Go doesn't share.

ilovecaching 8y ago
What do you mean by nicer? I would imagine that something that is application specific would not require generics. Interfaces do not throw away type safety if they are used correctly. They are also better suited for the consumer of the type rather than the definer. One of your problems might be that you are prematurely abstracting your interfaces for your callers.
- deleted 8y ago
  [deleted]
- singingboyo 8y ago
  interface {} definitely does throw away type safety, however, and is reasonably necessary for some library use cases. Is it possible that you're coming at this from an angle of building applications for specific purposes, while oppositelock is building more libraries? My experience (admittedly limited) is that application writing in Go is nice, but as soon as I try to build a library for use in several similar (but not quite identical) cases, maintaining type safety can quickly become a hassle.
- oppositelock 8y ago
  Let's say that I have an interface called Sortable, so I design my data structure to accept and return Sortables. I can insert any Sortable into it. When I get the Sortable in a future lookup, I don't know its type. I have to use reflection to error check. With generics, I could create a generic data structure which is strongly typed - what goes in is what comes out. Right now, the way to ensure that is to wrap your data structure in something that converts those Sortables into specific classes, say PatientRecords. Interfaces are wonderful, I like working in Go more than any other language so far, but they have their limitations.

lumost 8y ago

I loved go from 1.3 onwards, and it still has a special place in my heart. But ultimately a failed attempt at writing a heavy numeric/scientific app in Go soured me on the lack of generics. the overhead of needing to re-implement functions in order to avoid casts was way to much to bear in one app, and projects such as gonum suffer either due to an over-reliance on interface or the requirement to constantly re-implement functions to deal with the change in type signature between int, float, and their associated sizes.

ilovecaching 8y ago
This is an example of why I say use the right tool for the right job. Go is not the best language for scientific computing. Depending on the math involved you should likely be looking at Fortran or Python, which will most likely use Fortran or C under the hood. Go is best suited for small application or microservices, or as glue code for services.