3 ms·

Yeah, for me this is the big problem. For example, I once built a generic flow based library in Go for work (Go was not my choice, and while I like Go it was n

Yeah, for me this is the big problem. For example, I once built a generic flow based library in Go for work (Go was not my choice, and while I like Go it was not really the best choice for this library). The idea is to have a pipeline of go routines where data flows from one stage in the pipeline to the next. Channels and go routines are awesome for this, but setting up all the types for the channels based on the types in the functions being run by the go routines was quite difficult. I had to do it all by reflection and the code was really complicated. With generics, it would have been trivial. The proposal in the 2.0 spec looks promising and I'm looking forward to hopefully being able to play with an implementation sometime.

bpizzi 8y ago
> setting up all the types for the channels based on the types in the functions being run by the go routines was quite difficult. I had to do it all by reflection and the code was really complicated. My guess (and personal experience) is that this would maybe be more convenient to do this via code generation. It's not as ergonomic as generics (well, depending on the implementation...), but still it's less cumbersome and prone to failing at runtime that reflection. Reflection has its uses and places, but as soon as it gets all over a function then it's time (imho) to look into code generation.
- mikekchar 8y ago
  I definitely would have done it that way, but there was no standard code generation in go at the time. I could have whipped something up it's hard to say which would have been more complex.
  - bpizzi 8y ago
    As an anecdote: my 'code generation' go-to solution in go is text/template's based. The '//go generate' on the first line of the source file generating the final code is a mere helper and I could do without it any time. Again that's just my experience ;)

bpizzi 8y ago

> setting up all the types for the channels based on the types in the functions being run by the go routines was quite difficult. I had to do it all by reflection and the code was really complicated. My guess (and personal experience) is that this would maybe be more convenient to do this via code generation. It's not as ergonomic as generics (well, depending on the implementation...), but still it's less cumbersome and prone to failing at runtime that reflection. Reflection has its uses and places, but as soon as it gets all over a function then it's time (imho) to look into code generation.

mikekchar 8y ago
I definitely would have done it that way, but there was no standard code generation in go at the time. I could have whipped something up it's hard to say which would have been more complex.
- bpizzi 8y ago
  As an anecdote: my 'code generation' go-to solution in go is text/template's based. The '//go generate' on the first line of the source file generating the final code is a mere helper and I could do without it any time. Again that's just my experience ;)