3 ms·
> It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. There is nothing wrong with repeating things. I
by BinaryIdiot 11y ago
> It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself.
There is nothing wrong with repeating things. It's important to NOT repeat many things but everything? No way. DRY is a great suggestion but shouldn't be looked at as any type of hard rule.
For instance I've been on projects where DRY was taken to such an extreme that even the function decorators (plus their COMMENTS) were abstracted away because a few words or, at least, a single line could be duplicated. This would require looking through multiple files and figuring out the abstraction code just so I would know where the REST endpoints where.
So I'm not the biggest fan of GO but I see zero reason why it's going to be relearning this specific lesson.
- lomnakkus 11y agoI'm not seeing where the parent poster suggested taking DRY to such extremes. The fact that a feature can be abused doesn't mean that it's a worthless feature. If that were the case there'd be no progress in programming languages because basically every feature can be abused. What matters is the balance between how easy it is to abuse (accidentally or not) vs. how useful it is when not abused (such as added expressivity/safety/DRYness/etc.).
- grey-area 11y agoGo does not eschew dry, it just draws the line a little further toward repitition than other languages.
- XorNot 11y agoTo it's credit, most of the times I feel like I'm repeating myself in Go I usually later find I'm needing to specialize anyway. Go tends to help you avoid premature optimizations which you'll "totally fix later" - i.e. handle your errors now, not then.