4 ms·

Oh, hey, it's a generic package that means you lose type safety and saves you from writing roughly 10 lines of code. Buffered channels + goroutines + WaitGroup

by TheDong 12y ago

Oh, hey, it's a generic package that means you lose type safety and saves you from writing roughly 10 lines of code. Buffered channels + goroutines + WaitGroup already allow you to implement this trivially, and because channels are builtin generic, you can do it without the nasty type casts. Really, []interface{} is a terrible type to work with.

sunfmin 12y ago
Yes, I often find myself lost in this trivial channels + goroutines + WaitGroup combination. For my self I'd prefer cast interface{}, :-)
- chimeracoder 12y ago
  interface{} is different from []interface{}. You can do a type assertion (not cast - these are different concepts) from interface{} to another type. You cannot do a type assertion on []interface{}; you have to iterate over each element and assert individually. I agree with GP - the built-in primitives for synchronization, along with sync from the stdlib, are much cleaner once you know how to use them, and they're more idiomatic.
coldtea 12y ago
>Oh, hey, it's a generic package that means you lose type safety and saves you from writing roughly 10 lines of code. Or actually, it's not a generic (as in generics) package, which is why you lose type safety.
- chimeracoder 12y ago
  > Or actually, it's not a generic (as in generics) package, which is why you lose type safety. Can we please skip just one opportunity to begin this endless flamewar on a HN post about Go? Just one? Please? This topic has been beaten to death and beyond, and is not relevant to TFA at all, as the word "generic" can be used in many contexts, and it's more than clear which context OP meant.
  - coldtea 12y ago
    >and is not relevant to TFA at all How is it not relevant to TFA? This is a speficic example of the problem with not having generics!
namelezz 12y ago
Is interface{} similar to type erasure on JVM?
- TheDong 12y ago
  No, it's most like "Object" in Java.

by TheDong 12y ago

sunfmin 12y ago

Yes, I often find myself lost in this trivial channels + goroutines + WaitGroup combination. For my self I'd prefer cast interface{}, :-)

chimeracoder 12y ago
interface{} is different from []interface{}. You can do a type assertion (not cast - these are different concepts) from interface{} to another type. You cannot do a type assertion on []interface{}; you have to iterate over each element and assert individually. I agree with GP - the built-in primitives for synchronization, along with sync from the stdlib, are much cleaner once you know how to use them, and they're more idiomatic.

coldtea 12y ago

>Oh, hey, it's a generic package that means you lose type safety and saves you from writing roughly 10 lines of code. Or actually, it's not a generic (as in generics) package, which is why you lose type safety.

chimeracoder 12y ago
> Or actually, it's not a generic (as in generics) package, which is why you lose type safety. Can we please skip just one opportunity to begin this endless flamewar on a HN post about Go? Just one? Please? This topic has been beaten to death and beyond, and is not relevant to TFA at all, as the word "generic" can be used in many contexts, and it's more than clear which context OP meant.
- coldtea 12y ago
  >and is not relevant to TFA at all How is it not relevant to TFA? This is a speficic example of the problem with not having generics!

namelezz 12y ago

Is interface{} similar to type erasure on JVM?

TheDong 12y ago
No, it's most like "Object" in Java.