4 ms·

It’s amazing — amazing I say — how little generics are missed. Ooof. I've just spent about 3 days debugging Go code that was copypasted x N, with minor (incorr

• lostmyoldone 7y ago
  Yeah, I wish more people would accept that there are clear tradeoffs between different type systems. The tradeoff in Go seems to work reasonably well for services that doesn't want, or need, to handle complex application domain as fluently as concurrency. Essentially it works well for network/systems level code, and anything that looks like that. But for code that is more of an encoding on an application/service domain, the lack if generics hinders reasoning more than it helps. There you have no use for the fancy concurrency stuff, it has to be abstracted away for the domain experts to be able to be productive. There are, usually, also enough code that global readability become less helpful, and unambiguous contracts/types across systems becomes moreso. The latter case is massively helped by any way to enforce contracts over methods and types, as long as refactoring tools can reason over it. Nevertheless I do believe that locally (in methods/functions) a well behaved type inference and IDE tooling is better than extremely verbose type statements that I then make the IDE hide from me! To me these are clearly different scenarios, but apparently not to most people, or these discussions would rarely occur, but we would have discussions about the characteristics of languages making them suitable for any specific task. After all, for every solution there exists a possible language where the solution for a particular problem is part of the language, trivially making it the best language for that problem. Also trivially, there exists a best language for me, personally, to solve any problem. This is the hypothetical language which encodes and compensates for my individual perceptual and cognitive bias. Now, in a large enough enterprise, the most important contracts, and hence generics, might be expressed in the outward facing interfaces, and thus making them mostly redundant in a single service. Sharing implementations becomes less important at this scale, as it creates problems on it own. Hiring and onboarding masses of juniors are commonly a problem here. Hence, except for networking/systems styled solutions, Go might also be well suited for very large organizations with endless hiring needs, and a desire to look more modern.
  • treis 7y ago
    >Essentially it works well for network/systems level code, and anything that looks like that. You can also see this in the testing story. Go is very focused on unit testing which makes sense when you are one cog in a giant machine. But if you're writing something standalone the friction to write end to end integration tests is what turned me off.
• jstimpfle 7y ago
  Copypasted code is just bad code, no?
  • robbrit 7y ago
    A lot of the time in Go you do have to copy-paste-tweak - sorting lists for example requires quite a bit of boiler plate. That doesn't mean the code above is good, just that the lack of generics sometimes makes copy-pasting in Go inevitable.
    • jstimpfle 7y ago
      Can't you just do something like qsort()?
      • robbrit 7y ago
        Technically yes, however it is not type-safe. Idiomatic Go usually tries to be at least somewhat type-safe, and so the standard library's sort package uses interfaces instead of comparison functions. This is a bit more tedious to write unfortunately.
• andrenth 7y ago
  This is particularly bad with channels. If you look at a book like "Concurrency in Go", the apparent simplicity of the language leads to patterns are far from trivial, and the lack of generics means that it's impossible to implement them correctly once and reuse them for any data types... so everyone ends up having to implement their own, which can be fun, but pretty bad for correctness.