5 ms·

> I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times Who would have thought. Maybe a rewrite would

• kuschku 10y ago
  Porting meant rewriting here. But I still ended up with the same classes replicated hundreds of times. Polymorphic code is not possible in any other way in go – you always have to duplicate the code.
  • jy3 10y ago
    I'm sorry it went badly then. Your example intrigues me, isn't an interface enough? Is what bother you that the return value won't be typed T but IIncrementable in go?
    • kuschku 10y ago
      Yes, exactly. This is an actual issue. My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts. So, the library now gets these functions, and does all the filtering on other threads. So either I have to replicate the entire async code for every type, or I can’t keep type safety.
      • rogpeppe1 10y ago
        Don't keep type safety then. Think of Go as half-way between Python and Haskell in that respect. Types are great when they're useful, but they're not required.
        • kuschku 10y ago
          If you’re serious, that’s... the worst solution I’ve heard yet. That’s the same mistake C did with void, Java did with Object and corrected with generics in 1.5, just called interface{} this time. And while with python and Java, even if I circumvent the type system, I can still use annotations (see typed python, or JetBrains @Contract, Google’s @IntRange, etc), with Go I have nothing of that sort. Types are useful to provide safety, if your type system has to be turnt off, then I am losing all that safety, and might as well code in PHP (although they also* saw that mistake, and are fixing it now, with 7.0 and later).