4 ms·

It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. Golang is doomed to relearn these lessons.

codehusker 11y ago
We also have the hard-earned lessons of taking DRY to its extreme (left-pad). Where you draw the "copy a little code" line is subjective.
- danellis 11y ago
  Exactly what lesson do you think was learned? Do you think that languages that have had left-padding functionality in their standard library since forever (and there are lots of them) are going to remove it now? There was definitely a lesson to be learned there, but it wasn't the one you're implying.
  - Ericson2314 11y ago
    Yay sanity! All the anti-code reuses have taken the opportunity to come out of hiding, but they're no less wrong. The aggressive code reuse in the node ecosystem is, and remains, the quality of it I respect the most.
- danieldk 11y ago
  First of all, generics is hardly DRY to its extreme. I think that everyone agrees that copying e.g. a balancing red-black tree implementation just to specialize it for another value type is a pretty bad idea. So then you either end up with some kind of runtime polymorphism or parametric polymorphism. Some Go users argue that runtime polymorphism is enough, but you often run into cases where you have a func frobber(s []SomeInterface) ... However, you end up having a []ConcreteType where ConcreteType implements SomeInterface. However, you cannot simply pass a []ConcreteType to frobber because the memory representation is different and you have to construct a new slice with the interface type, etc. Also, I don't think left-pad is an example of extreme DRY (though it should be part of a standard library). It's not an example of extreme DRY, because I think a substantial amount of programmers wil implement it incorrectly. As long as many Java-wielding friends still believe that a single char can represent any unicode code point, I have no reason to believe that the average monolingual English-speaking Go programmer will realize that you can't simply do something like: padLen := targetLen - len(str) (BTW, Go's fmt package provides padding.)
  - madawan 11y ago
    The way I work is, I make an interface{} red-black-tree, and then when I need to store things in it I create functions around it. Suppose I'm storing Tiles in a Level: the Level struct will contain a (private) RedBlackTree and I'll define GetTile(Pos) Tile and PutTile(Pos, Tile) on Level which do the casting to and from interface{}. I still have type safety since I cannot put/get anything but Tiles in the RedBlackTree. But I didn't need generics.
    - danieldk 11y ago
      From your description, it is not completely clear what you are ordering on, but typically in an RB tree you (at the very least) want to require some interface/function that specifies ordering and equality. Of course, in some cases you can do casting on your interface boundaries. But in many other cases this is not possible, e.g. if you want the API to return an ordered set or map.
    - fauigerzigerk 11y ago
      You can only do that in places where you don't care about memory usage at all.
- prodigal_erik 11y ago
  The left-pad debacle was due to tools encouraging a badly non-hermetic build process and devs not being wise enough to resist, not DRY. Only depending on one third-party library won't save you if you "upgrade" to a broken version without testing.
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 ago
  I'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 ago
    Go does not eschew dry, it just draws the line a little further toward repitition than other languages.
    - XorNot 11y ago
      To 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.
slantedview 11y ago
> DRY is a great suggestion but shouldn't be looked at as any type of hard rule Agree that nothing should be a hard and fast rule. But the significance of DRY is that it increases quality. Not even having the option to "stay DRY" for many problems implemented in Golang will increase bugs. That's just how it is. Given the tradeoff between the supposed complexity of generics and the very real cost of bugs that will happen from maintaining duplicated code, I'm not sure there's much of a debate to be had.

codehusker 11y ago

We also have the hard-earned lessons of taking DRY to its extreme (left-pad). Where you draw the "copy a little code" line is subjective.

danellis 11y ago
Exactly what lesson do you think was learned? Do you think that languages that have had left-padding functionality in their standard library since forever (and there are lots of them) are going to remove it now? There was definitely a lesson to be learned there, but it wasn't the one you're implying.
- Ericson2314 11y ago
  Yay sanity! All the anti-code reuses have taken the opportunity to come out of hiding, but they're no less wrong. The aggressive code reuse in the node ecosystem is, and remains, the quality of it I respect the most.
danieldk 11y ago
First of all, generics is hardly DRY to its extreme. I think that everyone agrees that copying e.g. a balancing red-black tree implementation just to specialize it for another value type is a pretty bad idea. So then you either end up with some kind of runtime polymorphism or parametric polymorphism. Some Go users argue that runtime polymorphism is enough, but you often run into cases where you have a func frobber(s []SomeInterface) ... However, you end up having a []ConcreteType where ConcreteType implements SomeInterface. However, you cannot simply pass a []ConcreteType to frobber because the memory representation is different and you have to construct a new slice with the interface type, etc. Also, I don't think left-pad is an example of extreme DRY (though it should be part of a standard library). It's not an example of extreme DRY, because I think a substantial amount of programmers wil implement it incorrectly. As long as many Java-wielding friends still believe that a single char can represent any unicode code point, I have no reason to believe that the average monolingual English-speaking Go programmer will realize that you can't simply do something like: padLen := targetLen - len(str) (BTW, Go's fmt package provides padding.)
- madawan 11y ago
  The way I work is, I make an interface{} red-black-tree, and then when I need to store things in it I create functions around it. Suppose I'm storing Tiles in a Level: the Level struct will contain a (private) RedBlackTree and I'll define GetTile(Pos) Tile and PutTile(Pos, Tile) on Level which do the casting to and from interface{}. I still have type safety since I cannot put/get anything but Tiles in the RedBlackTree. But I didn't need generics.
  - danieldk 11y ago
    From your description, it is not completely clear what you are ordering on, but typically in an RB tree you (at the very least) want to require some interface/function that specifies ordering and equality. Of course, in some cases you can do casting on your interface boundaries. But in many other cases this is not possible, e.g. if you want the API to return an ordered set or map.
  - fauigerzigerk 11y ago
    You can only do that in places where you don't care about memory usage at all.
prodigal_erik 11y ago
The left-pad debacle was due to tools encouraging a badly non-hermetic build process and devs not being wise enough to resist, not DRY. Only depending on one third-party library won't save you if you "upgrade" to a broken version without testing.

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 ago
I'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 ago
  Go does not eschew dry, it just draws the line a little further toward repitition than other languages.
  - XorNot 11y ago
    To 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.

slantedview 11y ago

> DRY is a great suggestion but shouldn't be looked at as any type of hard rule Agree that nothing should be a hard and fast rule. But the significance of DRY is that it increases quality. Not even having the option to "stay DRY" for many problems implemented in Golang will increase bugs. That's just how it is. Given the tradeoff between the supposed complexity of generics and the very real cost of bugs that will happen from maintaining duplicated code, I'm not sure there's much of a debate to be had.