3 ms·

As somebody who likes it for work, how do you deal with lack of generics? My team is starting several new projects in go, where in the past we used either java

As somebody who likes it for work, how do you deal with lack of generics? My team is starting several new projects in go, where in the past we used either java (and I actually liked java typesystem) or nodejs (and I liked that one as well). I especialy got used to the functional style of using map/reduce/filter everywhere, and I am not sure if I would be able to continue in this style in staticly typed language without generics? Or is there a different style I should adopt?

jerf 9y ago
"As somebody who likes it for work, how do you deal with lack of generics?" By using it in its core domain, network servers, where you don't tend to use generics very much. I've observed that generics seem to be less useful when you're almost always only one transformation away from your data even having just been or being just about to be a simple []byte buffer. "I especialy got used to the functional style of using map/reduce/filter everywhere, and I am not sure if I would be able to continue in this style in staticly typed language without generics?" Even if Go had generics it would probably still be a language where you write for loops. I'm exceedingly iconoclastic on this point relative to the rest of the world: I don't believe "declarative" languages exist. As far as I'm concerned, reduce(func(x, y) -> x + y, 0, [1, 2, 3, 4]) is not very different than for _, val := range [1, 2, 3, 4] { sum += val } Reduce is not any sort of "declaration" of how you want it to be done, it's just an alternate spelling for what may very well be identical machine code. I am aware of the compositional arguments; my counterargument is that the only language I've used that is slick enough for the composition to end up being useful is Haskell, where the example I gave is foldl (+) 0 [1, 2, 3, 4] where this is fluid enough that composition and factoring out bits of the pipeline is actually worth it. In languages like Javascript, due to the fact it is roughly an order of magnitude more noisy in the syntax, all the code I've seen that is using maps and reduces and folds could be trivially converted to for loops without loss of much more than vertical lines. (Sometimes I even would do the true FP thing and factor out bits of the pipeline, I found it confused people.) (You can "win" in Javascript by using that sort of style to compose promises together or whathaveyou, but then, in Go, you're always writing at the promise level, so that doesn't matter.) Basically, when composing two functions together is any harder than x . y, it's just not something people do. However, your mileage may vary.

jerf 9y ago

"As somebody who likes it for work, how do you deal with lack of generics?" By using it in its core domain, network servers, where you don't tend to use generics very much. I've observed that generics seem to be less useful when you're almost always only one transformation away from your data even having just been or being just about to be a simple []byte buffer. "I especialy got used to the functional style of using map/reduce/filter everywhere, and I am not sure if I would be able to continue in this style in staticly typed language without generics?" Even if Go had generics it would probably still be a language where you write for loops. I'm exceedingly iconoclastic on this point relative to the rest of the world: I don't believe "declarative" languages exist. As far as I'm concerned, reduce(func(x, y) -> x + y, 0, [1, 2, 3, 4]) is not very different than for _, val := range [1, 2, 3, 4] { sum += val } Reduce is not any sort of "declaration" of how you want it to be done, it's just an alternate spelling for what may very well be identical machine code. I am aware of the compositional arguments; my counterargument is that the only language I've used that is slick enough for the composition to end up being useful is Haskell, where the example I gave is foldl (+) 0 [1, 2, 3, 4] where this is fluid enough that composition and factoring out bits of the pipeline is actually worth it. In languages like Javascript, due to the fact it is roughly an order of magnitude more noisy in the syntax, all the code I've seen that is using maps and reduces and folds could be trivially converted to for loops without loss of much more than vertical lines. (Sometimes I even would do the true FP thing and factor out bits of the pipeline, I found it confused people.) (You can "win" in Javascript by using that sort of style to compose promises together or whathaveyou, but then, in Go, you're always writing at the promise level, so that doesn't matter.) Basically, when composing two functions together is any harder than x . y, it's just not something people do. However, your mileage may vary.